Software truth
13/03/13 12:55 Filed in: Management
There is an old maxim in computer science:
It remains true.
Good, quick, cheap; Pick any two.
It remains true.
Developing software is a complex activity and although there is a small class that is disposable, most software can reasonably be expected to be used many times and by users other than its author. This means that it should be robust, documented and designed for maintenance.
In general good software requires understanding how and where the software is to be used - this generally requires spending effort in design and construction. Poor software can be thrown together quickly with no thought for the future or usage.
Depending on your design methodology you design or evolve your software to improve it or bring it closer to customer expectations. A process that takes time and hence is not quick.
The performance of software is usually enhanced through optimisation or supplying additional resources so if you want it to be quick you either have to spend development effort or hardware resources or compromise on performance.
To some extent development time can be reduced by providing additional coding and analysis resources but this makes the process less cheep. Brooke’s in the Mythical Man Month also contends that further resources may not always be beneficial. He goes so far as to suggest that adding more resources to a late project usually makes it later.
In general good software requires understanding how and where the software is to be used - this generally requires spending effort in design and construction. Poor software can be thrown together quickly with no thought for the future or usage.
Depending on your design methodology you design or evolve your software to improve it or bring it closer to customer expectations. A process that takes time and hence is not quick.
The performance of software is usually enhanced through optimisation or supplying additional resources so if you want it to be quick you either have to spend development effort or hardware resources or compromise on performance.
To some extent development time can be reduced by providing additional coding and analysis resources but this makes the process less cheep. Brooke’s in the Mythical Man Month also contends that further resources may not always be beneficial. He goes so far as to suggest that adding more resources to a late project usually makes it later.