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
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.
Previous Topic
