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. It comes from recognising three different levels of limitations to our productivity.
In 1956 the cost of one software engineer for a full year was the same as 30 hours of console time. In Production of large computer programs Benington describes one of the first software projects so big that it required a team. At this time the limitations in hardware defined how we wrote our software, so the challenges had to be met accordingly. Bennington 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, but 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 its 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. *You could even stretch it so far as calling it Test Driven Development in spirit. Bennington 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. To me, it stood out 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.
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. My favourite story illustrating this is one 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 to thrive, with current technology, actually hinder us today? Before we find them we can not benefit from new and better ways of solving our old problems. In a team, the role of the questioning child can be played by a consultant or a newly hired.
Lastly there is the limitations based on lacking the skills needed to take advantage of current technology. When we rid ourselves of our old ways that are no longer needed with our new tools, how do we gain the proficiency needed in using 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 using and I doubt that I know half of its features, judged by the rate that I discover new ones. Other technical gains create even more disruptive changes to the optimal way of working. 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. Test driving software is a skill and the old way of structuring code might not support it, so learning more about architecture might also be necessary.
This can be truly frustrating. Developers needs to utilise the technical advances we have had 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 this I want us to look at the dream that shines through the lines in that paper. In that dream 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. We just do not make use of them everywhere, as DORA’s devops report shows The world needs better software, and I somehow feel that I owe it to those who walked before me to use the tools that I now have been given.
To recap, look around you and see if you spot the same limitations as I do:
- The hard limitation in the technical tools, 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?”
- The limitations based on lacking the skills needed to take advantage of current technology, 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 accept where we are and how we got here. There is a lot of prestige related to proficiency in the software industry. We can not let the old limitations be just to avoid admitting that we 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 and 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.