“Examinations of typical programming projects will show that, over the duration of the project, programmers spend over 50% of their working hours looking for and correcting their mistakes. The usual 'solution' for this is remarkable.....
We try to solve the problem by rushing through the design process so that enough time is left at the end of the project to uncover the errors that were made because we rushed through the design process”
Glenford J Myers 1978
I've had the good fortune to look at lots of software in a variety of languages in my career and it is endlessly fascinating, and when I talk about design to some perpetrators of bad code a common response is that oh! design is not black and white, there is a grey area. This got me thinking.....
In quite an angry moment I drew up this representation of what I have experienced, I think design is various shades of brown, a small grey area and an even smaller white area. The brown area is various shades of awful.
The time graph can also be viewed as a cost graph and it is the cost throughout the lifecycle of the application. Disclaimer:This is based on my experience and not research.
So looking at a brown project.......
It's a classic code and fix job, tight coupling makes the code brittle, inflexible and hard to change. Lack of cohesive modules and poor abstraction makes the code hard to understand. So 95% of the project time is used up and 95% of the code is written. The last 5% of code will not take 5% sadly, you'll be adding functionality to code that will be resisting you. Bugs are hard and expensive to find, tight coupling means changes made will ripple outwards causing unpredictable results in related modules. Simply put, it takes a lot of time, effort and cost.
Compare with a grey project.......
It's had a bit of modular design applied to it, this design work gives the architecture flexibility. Changes can be made simply and easily at the end, when most customer input is usually given. The design work makes the code easy to understand, therefore bugs are easier to detect. Loose coupling ensures that changes and additions to a particular module does affect other modules.
But what about Exceptional?
One of the challenges for a designer is knowing when to stop.
So are you a designer or a syntax jockey?
A designer will be spending their time thinking about the problem that they need to solve, a syntax jockey is likely to be thinking about what new tool or technique they can apply.
Software Facts of Life
As grown-ups I think we can face the truth.
Badly designed software exacerbates these problems.
Steve
Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.