Yes, Software Development is an Assembly Line, but not Like That

I grew up in a manufacturing town. Nearly everyone worked for (or previously worked for) the local textile factory. My father was no exception. He had a few jobs but eventually landed a management job at the factory and started working closely with the engineers and other plant operators. At the time, I was in high school and about to start my education in software development. At the time, I felt–maybe hoped–that my world and the world my father was steeped in were vastly different. I was working on cutting-edge technology in the software space while he was helping design and run decades-old manufacturing facilities. It took years to learn that wasn’t the case.

Agile Software Development

I was lucky to be able to learn about software engineering while also hearing my father learn about lean manufacturing at the same time. In the beginning, I failed to see the connection between them, but as I learned and read more about this relatively new “agile” thing, I started to see the big picture. It should come as no surprise to folks that agile software development grew out of manufacturing systems developed for exactly the same reasons–to build things more efficiently.

That same desire to deliver value faster at a lower cost drives much of the innovation and growth in every business, including software companies. It’s not surprising that key leaders in the industry found those impressive innovations in industrial engineering and began adapting them to software. We know that waterfall and agile were adopted from industrial engineering, and the next big software development innovation will likely be as well.

Improve Business Efficiency

We can see many of the agile processes directly map back to either lean philosophy or even older industrial processes. Just-in-time manufacturing, or the idea that you keep an extremely limited number of raw or intermediate materials, is a philosophy that focuses on narrowing your manufacturing process to the essentials. Most agile practitioners argue similarly that your stories and shipped features should be as small as possible to deliver only the value required by the user. Both systems aim to improve business efficiency and agility by reducing potential waste (material breakage, for one, and over-engineering for the other).

All of these parallels make perfect sense to me. However, there was one component that never really clicked. A ticket and a widget are incredibly different things. Let’s explore this difference in two ways.

Traditional manufactured goods are usually tangible things. Tangible things often provide value for a fixed amount of time to a single user. For example, a delicious baked snack I pick up on a road trip provides maybe 30 seconds of value when I get back in the car; however, that car may provide 30 years’ worth of value to multiple users. Features in a software platform similarly provide value to users that vary in scale and duration. Here’s where we find an interesting divergence. A good provides a set amount of value and is often produced in bulk; a feature in a SaaS platform is often produced once and can provide an unbounded amount of value.

Compare and Contrast

Another way to see the contrast between the types of products is to look at the differences between engineers in each discipline. In a traditional manufacturing environment, the engineers are not the people actually operating the machines to produce the widgets. The engineers design the manufacturing lines and the products that will be produced on them. In software engineering, the engineers are the ones producing the features. Curious. 

However, if we look closely at the two roles, we see that they are actually producing similar things. Manufacturing engineers produce assembly lines and manufacturing processes that can produce those units of value. Software engineers are largely the same, also producing systems and processes that deliver units of value. The manufactured widget of software is actually the discrete user interactions with those features and pieces of software, not the features themselves. The assembly line in software engineering isn’t, as many think, the engineers producing features. Rather, it’s software producing value-creating experiences for users.

While this is interesting, how does it help us? I’ll propose two key ways.

Manufacturing processes are extremely adaptable to managing the technology and platform. Systems like Total Quality Management, which are focused on driving a cultural mindset of continuous improvement and an entire company focused on providing very low defect rates, easily translate to customer satisfaction in software organizations. Just to pick on TQM a bit, if we were to adapt it to software, we would focus on the number of times users are impacted by a defect more than the number of open bugs. Instead of tracking the number of defects and searching for more, we would be tracking the number of users who either failed to receive the promised value from the product or had severely diminished value. That would drive investment not only at the engineering level but would create buy-in from the whole company. Everyone in the company is interested in a conversation about how many users aren’t able to gain value from a feature, but many fewer are interested in how we go from 20 open bugs to 10 open bugs.

Secondly, this mindset shift can help bridge the expectation gap between engineering and the business. I’ve been a part of many conversations where engineering has discovered a potentially serious flaw, and the whole team is in agreement that this is potentially one of the most serious bugs we’ve found in a while. However, when they bring this issue to the business side, that passion gets quickly overruled if engineering can’t show that that bug is “impacting customers.” Those debates often fall into conversations of projected odds better left to the sportsbook room in Las Vegas. While there are obvious exceptions for security exploits, compliance issues, and other business risk-driven defects, the business is justified in not investing in fixing a defect that users aren’t impacted by.

Reporting Performance Issues

Conversely, this line of thinking can help engineering convince the business that something is a critical problem and needs to be addressed. While previously, I would have reported performance issues in terms of p99 times or average load times, that doesn’t describe performance in terms of our unit of value. If our unit of value is a customer using our app or a feature, then each negative interaction is a broken widget. As an example, I’ve since taken to reporting performance issues in terms of the number of sessions with a frustratingly long load time and the number of clients and users that are experiencing those.

Manufacturing is perhaps the most varied industry in existence, adapting itself to produce nearly everything from food to raw materials to consumer electronics to clothing. That long history, many contributions from a massive number of brilliant engineers, and significant innovation have led to dozens of amazing systems for delivering value. While I proposed two examples of how we should give these processes a second look as engineering and business leaders, it’s worth dusting off some manufacturing engineering books and giving them a read yourself. You may find the key to outpacing your competitors was drawn up by an industrialist decades ago.

My first college internship was at one of the factories my father worked at in the engineering department. I was able to see firsthand how deeply some of today’s engineers think about these types of production processes. They really know how to ship stuff, and software engineers may have a lot to gain by learning from them.

Now, go build great things!

Thanks to DevOps.com for featuring this article on their site!