I’ve been a software engineer for over 25 years. Over that time, there has been a pendulum in the industry that swings between demand for developers as specialists or generalists. As new architectures, development methodologies, and organizational structures emerge, development teams need specialists. As technologies and methodologies become assimilated, developers need to adapt and incorporate new skills as generalists.
Going back to the 1990s, there was desktop software for the PC boom. In those days, businesses were hiring specialists in Windows, OS/2 and Mac. Client/server was the next revolution. Networks were getting more prevalent and faster. Companies wanted to manage data and storage centrally but make use of the great interfaces that could be built on Windows and Mac. Here again we used specialists for both the client and server.
The swing back to generalists is evident in the shift to Agile and DevOps. Back in the day it was not uncommon to have 50+ person teams building applications using the Waterfall methodology. From a technology perspective, development was kept in silos for each specialty. It was uncommon for a developer to straddle specialties such as development and quality assurance.
When the Agile methodology became prevalent, we saw the teams of 50 reduced to teams of 6-12. More and more, developers were expected to write unit tests for their software, and there was also a rise in test driven development or TDD. Quality was becoming a skill that developers needed to do their job. Quality engineers also started to code and automate some of their testing, further blurring the lines between developers and QA.
From a technology standpoint, developers started to do more work across the tiers. This was driven by two factors. The first was the reduced team size of an Agile team. Less people meant less room for specialists and less time for handoffs. The second was the need for speedy delivery of software to the customer that was part and parcel of the benefits of Agile development.
DevOps has ushered in a new trend. Teams are moving from batched releases of functionality to single-piece flow. In other words, we no longer think about collecting the work of multiple engineers over multiple sprints into a release. Our ability to bring value to the customer as soon as possible and out-innovate the competition is driven by releasing the work of a single engineer as soon as it is ready. This will typically be accomplished through a CI/CD pipeline directly from the source repository through all manner of automated testing, and finally deployment into production.
What does this mean for the individual developer? Plenty. In the next blog post in this series, I examine the major capabilities software engineers need to thrive as full spectrum engineers.