Recently, I had to go over yet another piece of software. As seems to be the general case, it was full of features. The development team was very proud of all the features that they managed to add into the product in the time frame allocated. The only problem is that a set of features is NOT design. Design is NOT class diagrams. Design is NOT a UML model of the interaction between a bunch of abstractions (classes, methods, modules, packages ....).
The problem is it is much easier to explain design by negation (what it is not) ... rather than say what it exactly is. If anything a well designed software system would consider aspects like: Interaction with users/systems, Flow, Entropy (Will this software system age well? Will it resist decay? Can it be maintained? Can we support it?), Can the user learn it incrementally? Are features even visible to the user?, Conceptual integrity, Domain Vocabulary and alignment with the domain etc...
To produce a reasonable design a number of aspects need to be considered before writing the first line of code, the more the better .. and yes, they need to be incrementally refined as we construct the system.
Sadly, we get to pick only two aspects from the ultimate list -- "Good, Cheap, Fast".
Leave a comment if you have you own set of non-designed software experience.....
