I was rummaging through my book collection looking to see what I could take to the charity shop when I came across an old favourite: ‘Rapid Development – Taming Wild Software Schedules’ by Steve McConnell. With a sense of nostalgia (it was published in 1996) I picked it up and started to flick through thinking that it would be out of date and a top candidate for creating space on my shelf. On the contrary, I found most of the insights as relevant now as they have ever been and it’s not just me saying that. The book is still available on Amazon with 86% 5-star ratings and reviews saying the same.
Included in the book is a fascinating list of 36 ‘Classic Mistakes’ in software development. Coincidentally, it’s been 36 years since I wrote my first line of code in Fortran on a college computer. So not surprisingly, as I read down the list, all but a couple made me nod and say, ‘yup – seen that. Oops – did that!’.
I would say that two ‘mistakes’ in the list – ‘lack of automated source-code control’ and ‘premature or overly frequent convergence’ are now much less of an issue due to advances in configuration management tools and the evolution of continuous development tools and techniques. However, not everyone has moved with the times and may still be experiencing issues in these areas.
As I reflected on some recent engagements I could see that many of the ‘mistakes’ were still being regularly made despite all the advances in methodology, tooling and collective industry experience.
In part I think this is due to the complexity and security challenges of enterprise and web-facing solutions. User-expectations are also higher due to the massive use of a few very very good software products such as Facebook, Google, Office 365, Twitter and the like. In the corporate enterprise, the same old things play out since they are method and technology agnostic. People and behaviours don’t change.
Here are a three mistakes in Mr McConnell’s list that have definitely not gone away:
Inadequate design. Regardless of the development methodology, estimating technique or sourcing arrangement, inadequate design can be hugely damaging. The need for sound design is also greater than ever. If you’ve got off on the wrong foot with your architecture then sooner or later you will probably be forced to start again. The ‘dive-in’ and sort out the solution as you go approach is full of risk. Why does this still happen? It is usually business or budget pressure that encourages delivery teams to scrimp on design. Agile methods can also be misappropriated to short-cut the required design focus. Developers are encouraged to just get on with it.
Developer gold plating. There’s nothing a developer likes doing more than including extra features that they think will help improve the product. It’s a natural instinct. We want to be creative and be praised for doing great things. This behaviour can be exacerbated by the one-thing-at-time approach that helps Agile teams optimise their velocity. The problem is that if a developer gets ahead of schedule, rather than pulling the next thing off the backlog, they are more inclined to titivate the thing that they are working on. They might even up the story points during estimating to give themselves head-room to add a superfluous feature. Scrum masters need to watch out for this and keep things flowing through the production line.
Requirements gold plating. I like this one. And ironically it often rears its head on platform migrations and replacements. A platform that has evolved over many years develops all sorts of ‘nice-to-have’ features which then get established as ‘must-haves’ when the new solution is being designed. Business users, take a long hard look at yourselves ;-)
Well you get the idea. I need to get on with some mistake prevention management now but will continue to work though the list and tweet my insights.
If you have any insights and experiences to add for why we keep on making the same mistakes, please get in touch. I’d love to swap notes. Now where is that Fortran coding manual…