Why the name you give to your software-builders matters
“So, what do you do?”
A simple question, but the name given to software builders has changed several times over the years, with each change subtly affecting how the role is perceived.
If your job is to build software and you’re asked at a party what you do for a living, what would you say? If you want to leave the enquirer satisfied that they understand your answer, you might say ‘computer programmer’. A term they are likely to be familiar with and (age depending) will be able to relate it to their own experiences driving a Turtle with Logo or building a game in Scratch.
But, like most labels, ‘programmer’ can be a pejorative term. It harks back to the earliest days of programmable computers where a ‘programmer’ might be a technician translating a specification into punch cards — implicitly a semi-skilled, non-creative role. The term ‘software developer’, or just ‘developer’ gradually replaced ‘programmer’ as the most common name for the role of a software-builder. Because ‘developer’ suggests a person who has a hand in taking an idea, forming it and making it real.
However, with its emphasis on creativity and the hint that a ‘developer’ has no ongoing responsibility once the software has been built, this label also has its detractors. And so some people prefer the term ‘software engineer’.
Software engineering has long been used to describe the complete process of taking an idea or requirement as an input and having ‘finished’ software as an output. When software projects became sufficiently complex that large numbers of people were involved, ways of organising those projects and the people on them needed to be found and engineering — specifically civil engineering — provided a convenient metaphor and set of existing processes.
The appeal of ‘engineering’
This metaphor is now deeply ingrained — computer science degrees are often provided by a university’s school of engineering — but it is increasingly misleading now that the industry has moved from the linear processes a civil engineer would recognise to the dominant iterative model. ‘Software engineer’ is still popular with managers and software-builders alike, but I believe for very different reasons.
To a manager, the attraction of considering the process of building software as ‘engineering’ is one of control and expectation. Civil engineering is a process that is outcome-driven and has clear concepts of ownership and hierarchy (the role of ‘architect’ is also borrowed from this metaphor). An ‘engineer’ is a role with fixed expectations and the flow of ideas is strictly one way — the only creativity required or expected of them is to find engineering solutions to technical problems. To the software-builder, referring to themselves as an ‘engineer’ is a statement of self-worth. They are saying they are a professional whose training, knowledge and experience must be valued and respected — on par with the chartered civil engineer.
Those two definitions are not mutually exclusive, but in reality there is often a significant tension between them centred on the concept of creativity. Many software builders consider theirs to be a creative calling and even while insisting on being called ‘engineers’ they choose to ignore one of the fundamental precepts of civil engineering — do not waste time on solving a problem that has already been solved.
The expectations of an ‘engineer’
The manager who chooses to think of their software-builders as engineers is making a strong statement — you are here for your skills in turning specifications into code, solving any problems you encounter in the most time- and cost-efficient way possible. Like the civil engineer, it is the software engineer’s duty to make themselves aware of existing techniques and solutions and apply them wherever possible. There is nothing wrong with this position, as long as your software-builders are made fully aware of such expectations before they join your company. In fact there are many software-builders who prefer working in this way.
Where this model falls down is when a company’s recruitment policy fails to match the reality of how the CTO or CEO expects the engineering team to function. If you work to this model then choose to hire ‘Rockstar/10X/Auteur’ software-builders — whose perceived super-productivity hinges on them having freedom and control — you should not be surprised when they become dissatisfied and disruptive. You will find that estimates start to go up and suddenly there is a pressing ‘need’ to adopt new technologies as your ‘engineers’ try to keep themselves interested.
Equally, you must understand that by applying this model, you are locking away the product and business ideas of what is often the most highly educated and highly paid group of individuals in your company. Token efforts to unlock this pool of ideas (such as internal product forums or engineer representation in planning meetings) are generally unsatisfactory for all concerned, as they only offer a very limited opportunity for your software builders to help shape your product and business.
The expectations of a ‘developer’
In contrast to an ‘engineer’, a ‘developer’ expects to work in a more fluid process with a bi-directional flow of ideas between themselves and product owners. Under the ‘developer’ model, the relationship between product owner and development team is crucial and requires a great deal of mutual trust. For reasons of harmony, ‘product’ and ‘development’ teams often share a reporting line or are fully merged in those companies that do not follow the ‘engineering’ model. Developers generally prefer to work to abstract requirements or business needs rather than specifications, and expect considerable freedom in how those requirements should be implemented.
When working correctly, the benefits to a company of this model are:
- Having business ideas critiqued (often bluntly) by a smart group of people outside of the product/marketing/executive ‘bubble’;
- Having an engaged technology team with a strong sense of ownership, because they feel they have contributed to the product’s direction; and
- Having a team who feel they are allowed to express their creativity in the way requirements are implemented.
But, without careful management this model can also become dysfunctional, leading to:
- Tension and distrust between developers and product owners;
- Punitive ‘estimates’ used to derail ideas developers do not agree with;
- Time wasted implementing (or re-implementing) solutions with new technologies or techniques.
What do you need?
So, do you want an engineering team full of engineers or a development team of developers? The answer, like all the big decisions you have to make, depends on your product, desired culture, time and funding, but be aware that it is likely to change over time.
A command-and-control management structure combined with an ‘engineering’ model of software-creation is deeply unfashionable, but for small teams with the right personalities, it can be extremely productive. Similarly, for larger organisations with multiple teams and mature products in a competitive market, you will need all the independence and cross-team creativity that the ‘developer’ model provides when working correctly.
Your job is to make sure that you are using the right model at the right time and that if change is required that you make sure that everyone understands why and whether or not they have a place in the new world.
Ben Halstead is a consultant CTO and writing as a contributor for CTO Craft.
If you, or your CTO / technology lead would benefit from any of the services offered by the CTO Craft community, visit: www.ctocraft.com or contact us via email at: info@ctocraft.com