Why is it that most software developers have such a miserable track record when it comes to finishing projects on time and on budget? During my software career I met some of the smartest people around and still most of them were not able to finish projects by the date that they set.
I have a hunch about this problem. One of the reasons why developers can't seem to make the date is because they never bother to separate the things they know how to build from the things that they don't know how to build. I believe that if one starts paying attention to this little [say enormous] detail then the ratio of successfully finished projects can be dramatically improved.
Read on, and see if you agree...
I suggest that you group the components on a project into three major groups:
- Components that you know how to do.
- Components that nobody knows how to do.
- Components that you don't know how to do, but somebody has done something similar before and you can find out how to do it.
Let's look at all three in more detail to see why should you care about these three classes of components.
1. Components that you know how to do. This is easy. You have done it before and you can do it again. You might even do it better than you did it the last time. It should give you no trouble at all. If you collected any data when you did this the last time, then this time you should be able to estimate the job pretty accurately. You might even be able to reuse one of the versions you already have.
2. Components that nobody knows how to do. These are the patentable ideas. There just aren't quite that many patentable ideas on any given project. What I mean, is that for most software applications, the part that is patentable is at best around 10% or less of the overall project. This truly innovative approach is part of the user interface, or an algorithm that makes your program stand out in the marketplace.
This part constitutes the highest risk on your project. If you can't come up with the innovation or invention then the whole project might not be worth doing. I suggest that you focus on this part early, and create a backup plan for just in case that great idea never comes. Figure out if there is any way that you can still solve that hard problem without the patentable idea.
3. Components that you don't know how to do, but somebody has done something similar and you can find out how to do it. It is easy to confuse #2 and #3: if you don't want to take the time to find out who has done something like this before then you will go ahead assuming that it has not been done. Alternatively, you can easily feel it must've not been done satisfactorily and you will certainly do a better job then those coming before you.
Surprisingly, I think that it is with #3. that most projects get into trouble. Most developers don't want to reuse stuff that other's wrote. Occasionally, they don't want to reuse what they wrote either. When I asked people why is this?, an interesting response surfaced: lack of trust. Most developers don't trust other people's code. Some don't trust their own either, that's why they want to rewrite it time and time again.
How do you decide if a component belongs to #1, #2, or #3? It does take some experience to put a component into the right bucket. The most important thing you can do is to ask the question: Which bucket should I put this component in? If you see that too many of them go into #2, I would encourage you to recheck them again. It might be the case that the components you have there are still too big and you need to break them down further to properly place them. Then you might discover that they actually fit into #1.
What do you think?