Software development is a design activity
Software development is not a manufacturing activity
Despite what a lot of people believe, software development is not a manufacturing activity. That is, it is not a process that takes some inputs (money and ideas, people, time, source code, compilers) and then manufactures some outputs (software; APIs, DLLs, database schemas). We have spent too long pretending it is a manufacturing activity. This delusion has to stop since it causes problems and gives a false view of software development. Credit where credit is due: I got some of the ideas for this article from the excellent and unknown book “Agile IT Organization Design” by Sriram Narayan.
Some history: software as “engineering”
When software development became a profession in the 1960s, it defined itself as “engineering”. It used engineering principles (the dreaded “waterfall” method of software project planning came from Civil Engineering). It talked about “software engineering” and “software engineers”. Other engineering related words like “build” and “develop” and “architecture” started appearing everywhere. And you know what?
This seemed like a good idea. Software development was a nascent field, struggling to gain traction and be taken seriously. It was also previously a field dominated by women, and sadly, a new influx of men wanted to come in, take over and make it a “proper, masculine” discipline. So they pretended they were all engineers and they were all building things, like men wearing hardhats in factories in an engineering or manufacturing context.
Problem: making software is not like that
There is a big problem with this approach, though: it is completely wrong. Creating software is not a manufacturing activity, or an engineering activity, or an architecture activity, or anything like that (though it’s maybe closer to architecture than other things). It is actually a design activity.
“But software build isn’t software design!”
I know what you’re thinking. “You’ve got it all wrong – there’s some design that happens, like UX design, visual design, maybe database design, or solution architecture design. But actual programming, that’s a building thing, a manufacturing thing. I write code, then I click build, and whir-buzz-click, stuff happens, and binaries pop out! That’s making stuff, not designing!”.
No, that’s wrong, it’s still designing. I’ll explain why.
Building software is producing a design for software
Let’s take two examples: a software example, and a manufacturing example. The software example is building a web API. Let’s suppose it is consumed by web and mobile clients, and returns customer data when you send it a properly formatted and authenticated request. The manufacturing example is a bicycle. A company that produces racing bicycles has decided it is going to design and manufacture a new model of bike.
Let’s go through the bike example first. First, we need a design for a bike. That’s probably going to be a complex process with a lot of sketching, prototyping, learning, iterating. There will be a lot of creative thinking and problem solving involved. Eventually, we’ll have a good design for a bike. Then, we have the manufacturing process: a bicycle factory starts making these bikes, one after the other after the other. All are basically identical. Not actually identical, each one is technically a distinct different bike, but they are all essentially the same as each other. There are clearly two very distinct processes here: a unique design one, and a repetitive manufacturing one.
Now let’s think through the API. The developer discusses with some stakeholders or product people or business analysts to understand what exactly the API needs to do and how it should handle different scenarios. The developer spends a lot of time carefully crafting the API: defining its parameters, endpoints, security, performance, monitoring, building its routes for handling different requests and types, error handling, and so on. There is probably a bunch of iteration, learning, creative thinking, collaboration, problem-solving, and so on. Then the API goes into production, and it starts working. Request after request after request comes in, and identical (not actually identical, but basically identical) responses go out, one after the other after the other. There are also clearly two very distinct processes here: a unique design one (see what I did there?), and a repetitive manufacturing one.
The “build” phase is actually part of the design; Operation is the manufacturing part
The operation of the API is the manufacturing part of this scenario. The API (or image editing application or mobile banking app or whatever) sitting there, performing operations over and over again. That’s the manufacturing: of behaviours. Of API responses, or edited images, or bank account balances. Software development is the designing of that system that then performs those manufacturing operations. It’s sort of like coming up with a design for a bicycle. I know, software is not like bicycles. So here is a much better example: it’s a lot like UX / UI design. You start with a customer or a problem statement, you try and understand the context and the problem they are trying to solve, and you come up with a set of patterns of behaviours you would like to implement and how you might come up with a design for how those behaviours could be actualised.
But a software developer doesn’t actually perform those behaviours, just like a UX designer doesn’t actually go through the screens and use the system in place of a user. They come up with a template, a model, a design. And an information system of some kind then executes that design template, hopefully, according to the intention of its designer. Now I know what you’re thinking…
So what? Who cares?
You’re probably thinking “This is just a semantic point. It seems weird and wrong, but fine, software development isn’t really “development”, it’s design. But what’s the difference? Who cares?” You should care. A lot. And I’ll tell you why.
You should care because people use this misunderstanding to abuse your job
I think software people made a huge mistake in the 1960s in choosing to define their field in this way. They wanted to force women out of software, they wanted to be taken seriously by the military-industrial complex, and they wanted to help usher in scientific rigour to their discipline. But they have painted themselves into a corner and created decades of enormous problems for the field.
Nobody asks UX designers for story point estimates
I’m not a UX designer but I’ve worked with a lot of UX designers. I’ve worked with a lot of good ones, really good ones. A company I worked at for a while had arguably the best UX team in my country. I went to lots of meetings with lots of UX designers, and their managers, and their stakeholders, and their managers and stakeholders. And I noticed the conversations that happened around UX designers were very different to the conversations around software developers. And you know what?
Nobody ever asked them for story point estimates for their work. Nobody ever asked why they had only designed 8 screens last sprint instead of 10 the sprint before. Ever. Nobody demanded they increase their “productivity” and “outputs”. People asked about outcomes, about context, about the systems and the users and if we were really solving real problems for our customers. They did want to see the designs but they didn’t try to second guess them or micro-manage their work. They understood that UX design is a very difficult creative activity that requires top people that need to be given respect and space to work in ways that work for them. If they wanted to spend a day in a research lab, no problem. If they wanted to sit with other UX designers and brainstorm for a week instead of sitting in their cubicle, no problem.
Contrast that to the software developers: constantly being harassed for estimates, queried about productivity, forced into cubicles, and we had it pretty lucky compared to some other companies. Software people insisting that they are “engineers” and “developers” who are “building stuff” make this way, way too easy. If it’s simply manufacturing concrete things in a repetitive fashion, then “that’s great!” think the traditional managers. We can measure the outputs of people and teams, compare and contrast, look at graphs to see who is spewing out more “stuff” and who is slacking off. Blame developers if bugs are found because they “built it wrong” (a different proposition to designing something wrong).
In summary: you reap what you sow
Software developers have built this rod for their own back. Not individually, I’m not naming and shaming or blaming any particular person. This has been a big slow process, a glacier that has crept over this industry for decades and to be honest is probably far too ossified to crack or shift now. But every time someone makes a stupid software analogy starting with “when I get someone to build a house, they don’t…” and you slap your face, thinking “but building software isn’t like building a house!”, my first thought is actually “no shit Sherlock. It actually isn’t like building anything at all, because it’s not building anything at all”.
