Software 265 |WHATIP ROSS DOESN'T KNOW ANYTHING ABOUT IT WOULD BE THAT DIFFICULT PROGRAMMING! HE WOULD BE || TC TYPE ON A KEYBOARD ALL USELESS AND NOTHING BUT A DAY! MY SON |S TEN AND HE BURDEN! MY PROJECT |S DOES IT Too! STATE OF THE ART AND I’m > GONNA LET NO VIGUAL BAGIC ce x Fe. vis au mee » eS 7] Tt \ i | they implement it mechanically. You see, of course, the problem. It will be riddled with bugs because they have missed the creative step of imagining the whole problem and solving it in the round. This fundamental misconception of software is common in many organizations. “Ah,” says the finance director, “I'll write a very detailed spec and then we can get someone cheap to just program it.” This does not work. If the finance director has done the creative work of taking a problem and turning it into a detailed specification for the programmer to ‘just program’ — removing any ambiguity and therefore the creative overhead -— he will have all but written software himself, albeit in a computer language of his own making. On the other hand, if the specification is a linear list of issues with no creative thought, he will not have reduced the time needed to program. He may have improved the quality by effectively getting a second pair of eyes onto the requirements gathering stage, but this does not help the programming effort itself. Ideally, you should never split up specification and coding. It is a creative process best handled by very small numbers of people working intensively on it. Of course, there is one big problem with this: some software tasks are huge. Before we look at the science of splitting up a software project, it is worth pointing out that many of the most famous projects were written by one man. I have met many of these people and they are all exceptional - Linus Torvalds, Linux; Anthony Minessale, FreeSWITCH; Daniel-Constantin Mierla, Kamailio; Eric Allman, sendMail. Before splitting a project between many people, it is worth considering wheth