The other, slightly less common1, is “engineering”. Don’t know why “engineering” it is a less used one; it is my personal favorite.
There are, however, environments (I’m looking at you, enterprises) where “manufacturing” might be better suited.
Yes, we manufacture the software much like a factory manufactures electronic devices. The orders (user stories) are placed on a Kanban board, from which they are pulled by the team into the production (development) pipeline. Part of the team builds (develops) the order (story), but it takes some time (story points). The other part of the team tests (validates) the product (software implementation of the story), sometimes sending it back to fix flaws (bugs).
Finalized product (software) needs to go through quality assurance (QA), the packaging team (DevOps) needs to package the product (software) and send it to a warehouse, where the logistics team (release engineers) ship it to the customer.
Software houses are in fact software factories.
The larger the software project (or the more software components it involves), the more creating the project feels like a factory. And to be clear: I’m not talking about software developers or engineers having to work shifts, constantly struggling to meet the production time norms (although deadlines sometimes are like that), while mindlessly typing in lines after lines of code (that is, in fact, the negative aspect of treating the software creation process like a factory, leading to burnt out workers and horribly performing products).
Manufacturing tangible goods requires processes2. A well defined and maintained manufacturing process is what keeps the quality high, lowers the costs, and enables delivery of consistent products. Quality, process, and test engineers work to maintain and evolve The Process, as there are always some improvements to be had.
Creating software – especially large, complex projects – also involves processes: development branching and merging strategies, continuous integration and delivery, compliance process, validation process… However, as opposed to a factory, software development processes can get out of hand, quickly. If only there was someone who would be the owner of it all, working continuously to improve them. Someone like…. a Process Engineer!
Seriously though, while you can find job postings for a Software Developer, Software Engineer, Software Quality Engineer, Software Configuration Management Engineer, Release Engineer, I’ve yet to see a posting for a Software Process Engineer3. Maybe I haven’t look hard enough.
Software Process Engineer should be the one to determine how the software is made. Define branching strategy for 6 sub-modules and 8 simultaneous releases? Yes. Recommend the best coding standards and review practices? Definitely. Closely monitor code metrics from the static code analysis and other sources? Absolutely. Periodically review the processes to identify inefficient or straight up absurd activities? Of course.
This is not a role about just looking at a dashboard (or seven), and making a sad face when something is not colored in green (fun fact: I once saw a quality dashboard where metrics that were OK were marked with red. Almost gave the project managers a heart attack). It’s about closely looking into everything that is involved in software manufacturing, seeking constant improvement.
That way, we can engineer not only the software itself, but also how we create it.