I had the luck of attending Devopsdays last week and saw Mirco Hering give the keynote speech. I decided to check out his book, DevOps for the Modern Enterprise. It provides a roadmap to engineering managers in enterprises of how to uplift their organisation’s DevOps practices.
In the introduction he makes a point that, “manufacturing principles don’t apply easily to IT delivery.”
Mirco’s idea of manufacturing is a factory of highly specialised workers repeatedly building the same widget in an assembly line. The result is a mass produced product, each identical to the other with no customisation.
I like this analogy and have decided to overthink it below.
A software engineer is like a craftsman arriving at their desk to build something completely different every day. It is like a carpenter asked to build a table, then a chair, a birdhouse, a potato canon on wheels, a foldable 3-wheel bike, each job different from the last.
The idea of programming as a craft, no least in Bob Martin’s Clean Code or Pragmatic Programmer.
What does this mean for the working engineer?
Estimates
“How long will that take?” The catchphrase of the project manager. At least the widget maker knows that the next one should take just as long as the previous.
There are some remedies for this.
Scrum practices limit the size of any task to what can be completed in a sprint. It is easier to predict small tasks.
With experience we build a catalogue of completed tasks. We can compare these to guess at how this next will go.
We use test-driven development to keep effort linear instead of exponential. A big legacy codebase means new features also require not breaking existing code. All changes become more difficult as we build on what came before. One way out is an automated test suite that lets us focus on only the new features.
The craftsman’s toolbox
Although no problem is the same we do have a toolbox that we can apply. An engineer acquaints themselves with their tools over time. As with any type of craftsman a step towards mastery includes mastery over their tools.
These tools might be design patterns, programming languages, log parsing and analytics tools, alerting tools; anything that you use to help you with your work. The more tools and the more proficient that you are with them the wider the scope of problems that can be solved.
Continuous upskilling
A professional should be continually developing their skills. The IT industry is always in flux. The tools that we use are changing and the types of problems that we are asked to solve are different.
The DevOps journey is always be evolving. The software developer’s should be the same.
One complication: there are an infinite number of frameworks, tools, data structures and algorithms. Where to focus? I have always either gone with either what was interesting or where I wanted work in the near future. If you have a better suggestion send your feedback!
Highly optimised solutions
An advantage in the factory is that when every task is identical it is possible to become highly efficient at solving that task, in fact it is also economically sound.
The software engineer needs to decide where to stop. A job will have requirements: functionality, NFRs. Should this be a quick solution for this one case or a framework for future changes?
The answer to this is that we often do not know.
Steve Jobs reminds us that, “great artists ship,” so we know that we have to draw a line somewhere.
Our agile ways of working and professional software engineering practices let us get away with making this decision as late as possible.
By minimising the time to develop and deploy code, developing an automated test suite, writing testable code that manages complexity, we can expand from the specific to the general solution.