The Unwritten Rules Of Software Development
To misquote Churchill: why so many bugs have been created in so many applications by so few
I have a shameful confession: in one way or another I’ve spent the last 30+ years of my life being involved with software development, from complex enterprise-scale applications handling hundreds of transactions per second to smartphone apps developed for multi-million-user market segments. I’ve helped major corporations remediate poor implementations of well-known ERP systems and I’ve consulted to organizations to help them create the basic ground rules essential for reliable, scalable, and robust application development.
During all this time I’ve discovered there are some eternal verities when it comes to the wild and wonderful world of software engineering, and with your indulgence I’ll now share a few of these truths with you.
Verity Number One: senior executives and users alike think a brief demo is the same as a fully-functioning complex system, and can’t understand why the development team needs more than a week to implement what is obviously trivial and simple to deliver. Now that we’ve all supposedly adopted some flavor of Agile, it’s obvious that all executives have to do is specify the required features, when these will be delivered, and how many hours of development time it will take. Because Agile means Miracle in any language spoken by people who have large annual bonuses and their own reserved parking spaces, so it must be true.
Verity Number Two: no software engineer alive will ever believe they should document their code by commenting, no matter how complex their code may be. This is because their code is elegant and transparent and absolutely anyone could glance at it and immediately understand its flow end-to-end, even if in between the first statement and the last there are tens of thousands of lines calling all manner of obscure undocumented sub-modules.
Verity Number Three: no software engineer alive will ever look at someone else’s code without asking in a loud and annoyed voice why that lazy good-for-nothing developer didn’t comment their code sufficiently to make its intent clear.
Verity Number Four: project sponsors and the business folk who will use the system are not unlike small children: they want sweeties and sparkly things but have no interest in how those sweeties and sparkly things are made. Additionally, they aren’t entirely sure what it is that they want but they’ll know it when they see it. Or, to be more accurate, when they see it they’ll know it’s not what they wanted even though they asked for it mere weeks ago.
Verity Number Five: no one wants to test anything until just before delivery, at which point some reluctant testing will be done and this will reveal so much is defective that delivery will have to be postponed. Even though the project manager will have been shouting about the need for testing since the very beginning and will have been consistently over-ruled by the business sponsor who “doesn’t want to waste time” on testing, this disastrous situation will of course now be entirely the project manager’s fault. Responsibility without authority is the project manager’s job description, which is why so many project managers either cease to care about their work or, conversely, commit suicide in the corporate broom closet on Thursday evening before the big go-live meeting on Friday morning when all the senior executives will come in expecting their sweeties and sparkly toys to be ready for them on the table.
Verity Number Six: no one learns from previous generations. Regardless of how new and shiny the tools may be, and how clever and sparkly the applications are, there are some basic rules to software development that when ignored always result in unnecessary problems. Fortunately for people with a wry sense of humor, these basic rules are automatically forgotten with each new generation of programmers. Even simple things like verifying a transaction get lost in the mists of time — until the consequences of failing to verify transactions become painfully apparent, at which point the idea of two phase commit is rediscovered like some lost wisdom from the Library of Alexandria.
Verity Number Seven: security is for losers. No developer needs to worry about security these days and besides, everyone wants more and more features and security isn’t a feature so screw it. This approach works wonderfully until 140 million social security numbers or bank account records suddenly appear for sale on the dark web, at which point it turns out (to everyone’s amazement) that maybe security is sometimes important after all.
Verity Number Eight: by the time a person has amassed half a lifetime’s experience and learned from uncountable mistakes both witnessed and personally committed, it’s pretty much time to retire, thus ensuring that all this accumulated knowledge will vanish from the community, leaving whoever’s left to learn everything all over again.
