Unnecessary limitations with a history
Most software teams today underperform since they can not fully leverage the technological advantages we have gained over the last decades.
That is a bold statement and it comes from recognising three different levels of limitations to our productivity.
The hard limitation in the technical tools
In 1956 the cost of 30 hours of console time was the same as for a full year of a software engineer. That has shaped our entire industry since then. In Production of large computer programs Benington describes one of the first software projects big enough to need a team. At this time the limitations in hardware defined how we wrote our software.
Some methods presented are very modern at their core. Benington describes both predefined tests for small units of code, parameter tests — today unit tests, and tests for the entire system, assembly tests — today system tests. To automate them and run them for every change of the code was financially impossible. Instead every test is clearly documented, not only to enable retesting but also to improve test design. The parameter tests were defined for every combination of inputs and outputs before starting to code.
In other words, a programmer must prove that he satisfied his specifications, not that his program will perform as coded.
(Actually, test specifications for one subprogram can be prepared in parallel with the coding.)– Benington in Production of large computer programs
You could stretch it so far as calling it Test Driven Development in spirit. Benington also describes the seed of our modern Integrated Development Environments (IDEs). The paper states about their development tools that its present size 40,000 machine instructions is indicative of the importance attached to its role. It really hit me how limiting it was to not have access to processing power when developing software in 1956. They knew what they needed, but the hard limitation in the technical tools made them take compensatory actions instead, like having designated teams for testing and operations.
The limitations originating in our old compensatory actions
In his Theory of Constraints Goldratt explains that we can not gain advantage from a technical advancement before we get rid of the compensatory actions we took to manage without it. I illustrate it with a story about a Sunday steak and a pot. The steak got its end cut off before it was put in the pot, since the recipe originated from an ancestor with a pot so small that no steak would fit without trimming it first. This waste was discovered first as one of the children asked the grandmother the magic word “why?” and the origin was uncovered. The limitations originating in our old compensatory actions can be tricky. How do we know what things that used to enable us, actually hinder us today? We need to find and discard them before we can benefit from new and better ways of working.
The limitations from outdated skills
When we rid ourselves of old ways of working, no longer needed with new tools, how do we gain proficiency in the new technology? Not everything has such an intuitive interface as a slightly larger pot. I use IDEs that the developers in 1956 could only dream of, but they are only useful if you learn what they can do. Modern version control systems create an opportunity for collaboration that turns silos into networks and enable us to explore and experiment in a way not possible before, if we know how to. Test driving software for evolutionary design is a skill needed, now that developers can be trusted with using a computer. So is continuous delivery a capability required as software changes faster for longer, now that updates are no longer delivered with a person traveling to install it for you.
What to do
Developers need to utilise the technical advances we have made since 1956. For a long time we have stuck with the practises Benington and others developed to survive in an era where computing was extremely expensive. Instead of holding on to processes they adapted out of necessity, I want us to look at the dream that shines through the lines in that paper. There I see test driven development, continuous delivery, static code checking, code in high level languages that is easy to read and then optimised by compilers, powerful IDEs and a lot more that we have today. This generation has the tools to get all the smart people working together on hard problems, while letting the computers do the boring repetitive stuff. But the DORA’s devops report shows that far from everyone make use of the technical advancements. I believe that all the listed limitations have a hand in that. The world needs better software, and I somehow feel that I owe it to those who walked before me to use the tools I have, but they only dreamed of.
To recap, look around you and see if you spot the same limitations as I do:
- The hard limitation in the technical tools, remember why you do it, make a note in the recipe on the reason for trimming the edges of the steak.
- The limitations originating in our old compensatory actions, embrace asking “why?” to weed out things no longer needed.
- The limitations from outdated skills, read the DORA DevOps report and find the support needed to become an elite performing software team.
Next time your are frustrated over your working environment consider where we are and how we got here. There is a lot of prestige related to proficiency in the software industry. We can’t keep the old limitations just to avoid admitting our need to learn new skills. Instead, take an action to change it for the better. Remove something compensatory that is not longer needed, or learn a new skill to leverage the tools available. No individual developer is to blame that it ended up like this. We need support each other to get out of it.
A version of this text was previously published on LinkedIn.
Comment on the blog!
Create a comment by emailing me.
Open an email to start writing.I will then add the comment to the post.