The Artima Developer Community
Sponsored Link

Java Buzz Forum
Master the unpredictable

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
gregor riegler

Posts: 32
Nickname: nautic
Registered: Mar, 2013

gregor riegler is a passionate developer and techlead for fluidtime data services gmbh
Master the unpredictable Posted: May 9, 2013 10:48 AM
Reply to this message Reply

This post originated from an RSS feed registered with Java Buzz by gregor riegler.
Original Post: Master the unpredictable
Feed Title: Be a better Developer
Feed URL: http://www.beabetterdeveloper.com/feeds/posts/default
Feed Description: This Blog Provides Information and Guides for "Clean Programming" and "Best Practices" in Software Development with a focus on Java
Latest Java Buzz Posts
Latest Java Buzz Posts by gregor riegler
Latest Posts From Be a better Developer

Advertisement
Have you ever come to work on a Project that you cant quite overlook? Are Requirements not yet clear or changing fast? Here are some tips to get along.

Use Tracer Bullets

Don't specify your software to death. Just grab your best idea, and give it a shot. Tracer Bullets are similar to Prototypes with one very important difference.
Prototypes are built to proove something, and then be thrown away. They are not intended for real production. Even some drawing on a paper could be a prototype.
A Tracer Bullet might get thrown away, but it is not intended to in the first place. It is developed as stable, clean and complete as needed, to use it for real production. A Tracer Bullet that hits its target, becomes a trunk.

Develop Leaves first

What do i mean with a leaf? Leaves are small exchangable software components or modules, that can be written independently, tested in isolation, and sometimes even run autonomous. They only perform a very specific task, not more. Find the leaves in your Project, and start developing the leaf with the highest risk.

Dont Reinvent the Wheel

99% of the problems that you face in your project have already been solved. Solving these by yourself can easily become a waste of time. Even the most trivial seeming problems are not trivial at all. Underestimating those is the issue in the first place, nevertheless it happens all the time. Well, its just logical to understimate the unsolved as you cannot know all the details until you solved it yourself. Analysing the problemdomain, concepting and realizing a solution can be a great way to learn, but is not very beneficial. Its in fact a risk, since it can lead to misconception or become a timeconsuming task that exceed your resources. You might even have to throw away your first attempts. Also, your outcome would be buggy, whereas established opensource software is usually stable thanks to its brave communities.
"Make or Buy" was a common phrase. I think it should be "Make or Find" by now, since opensource got really big. Rather invest your time into research opensource, and stay skeptical with what you find. When you compare 3rd party software, consider
  • Stability: Is it still beta, or did it have some stable releases yet? Who is the organization behind? Is the code clean and tested?
  • Activity: Can you find out how many developers this software has? When was the last commit? How frequently do they release a new build?
  • Support: Does it offer a good documentation? How about examples? Is there a public Issue Tracker? How many issues have been submitted yet and how many have been solved? Is there a Forum, literature, and a big community? Are there any big names that use this software?
  • Critisism: Is there anything bad that you should know in the first place? Search for reliable critiques and comparisons.

    Estimation is a waste of time

    Every hour that you invest in estimation, could also be invested in producing real outcome. Your estimation will be inaccurate anyway. When requirements change, you even have to change your estimations. If you have to estimate, because the business needs it, try to split your Project into smaller independent Parts first, and multiply your estimation with a Risk factor (times two for example). In the end you`ll need it.

    Plan only the nearest Future

    Its not worth planning more, because it will change anyways. Existing Tasks will explode, go away or change. New unforseen Tasks will appear.

    Read: Master the unpredictable

    Topic: Java EE CDI Disposer methods example Previous Topic   Next Topic Topic: Hibernate 3 with Spring


    Sponsored Links



    Google
      Web Artima.com   

    Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us