In today’s business of software development, “experienced” means that one has been around for more than 5 years. I have. More like 25 actually. When I started my professional career, we used IBM PC XT machines with dual 5¼ inch floppy disks, or if lucky, an AT with a 20 MB (yes Mega, not Giga) hard disk. I’d like to think I’ve learned at least something during this period.
When one is young, eager and open minded; perhaps even naive, one tends to accept every new trend as revolutionary. All new things are good, all old things are bad. For many years, I was more or less in constant search of new techniques, methods and technology that would improve the result of our software development projects.
However, as experience grows, one realizes that there is no such thing as a single, universal, method that will make software development projects succeed every time. On the contrary, it is well-known within the software industry that hardly any software projects are completed on time, or budget. The infamous π-factor applies: Cost and time are (at least) three times as high as calculated.
Even worse, it’s almost mandatory that the final product does not meet the requirements of the end user. At best, the functionality is acceptable, but by no means what the user originally desired.
Occasionally though, one runs into projects that are slightly less disastrous. Over the years, I have noted that these projects are characterized by certain common factors. One might even be tempted to call them “factors of success”. The term “success” in this context is relative, meaning something like “project is still overdue and budget is blown, but the customer seems fairly pleased”.
First and foremost, the single most important factor of success is Domain Knowledge. Domain Knowledge means true and deep understanding of how the end user will actually use the system. Note that this is very different from a formalized requirement specification, which is often used as the main input to the software development process.
Domain Knowledge is obtained by looking at the system from the perspective of the end user, i.e. as if one really would be an end user. In practice, this often means interviewing users of the existing system, spending time at the customer site to learn the terms and procedures of the customer operations, or even to engage a customer representative to participate in the development.
This process results in far more knowledge and information than can ever be caught in a formalized list of requirements. Not all individuals of the development team need complete Domain Knowledge, but it must be clearly present within the group at all times.
The second most important factor is the composition of the project team. A very experienced project manager once said to me: “Projects are not time critical, but resource critical”. I believe this is very true. The project team must be composed of the “right” kind of people. A certain amount of experienced developers is absolutely necessary. Moreover, the project team has to function as a social unit. Team members need to get along at least fairly well, and strive to reach the same goal.
Getting a project team up and running is no easy task. It requires an enormous amount of effort, similar to making a heavy freight train move. Once the train.., sorry, team, is rolling, one should be very, very, restrictive in changing the composition.
The third factor is adequate tool support. Regardless of the method or process applied, modern, professional and effective tools must be available to support the work. Any manual procedure will fail inevitably as work load grows, without effective tool support. This factor may be of slightly less weight, compared to the first two, but is by no means insignificant.
First ”Domain Knowledge”, then “Team Composition”, then nothing, then “Adequate Tools”, then nothing, then nothing, then nothing, then remaining factors.
The bottom line is this: The method you follow, the maturity level your process is at, the quality standards you apply etc. doesn’t matter, as long as you are not building a system that the customer can actually use to accomplish his task.