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.
I don't exactly think that estimation or planning should be dismissed. We just need to get better at planning for change and estimating tasks based on past experience and putting in the appropriate buffering for when things go wrong. We have a formula for estimation which is optimistic + 4 * realistic + pessimistic / 6 and this typically works out well.
ReplyDeleteBut how do you plan change? Maybe there is change that you can predict if you are very experienced. But there is also change that cannot be foreseen, that change everything. It'd immediately make your plan obsolete, wouldn't it?
DeleteNot at all. Estimation is key. You need to make sure your estimates come with a context. Don't just say "12 days". Say "12 days, which includes x, assumes y and excludes z". Record that context in the estimate so when you come back to it 2-3 months later when the project starts, you will know why you estimated that much.
DeleteAlso, always plan for change. Change Requests are magical tools. You start by planning what you know. Then, as things change, don't just ignore it and try to conform, execute change management processes. Then you AND your customer know what to expect from each change.