I listened to a very inspiring talk by DHH on why you should ‘unlearn your MBA’. One of the things that he touches on briefly is the idea that software is not created like mass-produced manufacturing. It doesn’t follow the same rules, and doesn’t even really live inside the same universe.

In manufacturing, if you add more workers or more parallel assembly lines you can make more widgets. If I spend 2 more hours a day working, I should be able to make 2X more things. This is not the case with software. When I approach software, I try not to approach it with a brute force mentality. There are booms and busts to how effective I am when I program. Sometimes it’s during the mornings working 8 hours straight, sometimes it’s in the evenings taking frequent breaks. It’s not a linear pattern.

One great way to see where this linear pattern breaks down is in team size. From a common sense perspective, you would think that adding more members to a project team would help that project to get done faster right? Common sense doesn’t win in this scenario. When we’re dealing with large complicated creative entities, how can adding more people really work? We have to think of software as more like a piece of art. Have you ever tried to write a book/article/paper with many people? It’s really really hard. You get a mish-mash of voices, styles and opinions. Think about trying to paint a painting with 40 people: it would be a nightmare.

Now you might be saying to yourself, “But Blake! We could paint a painting with 40 people if we had a set of rules and protocols that we agreed upon up-front.” and you might be onto something there. If we had to paint a large wall mural and we agreed upon protocol and practices ahead of time we could make it work. Unlike a painting, when we’re dealing with large software projects it takes time, concentration and critical thinking to understand the dynamics of all the moving parts. You’ve got thousands of lines of code to read through, and from that you need to see the big picture. Seeing the big picture in software is a lot different than painting. You can’t just look at a wall, you have to really understand everything that’s going on.

So many software projects are still run with these damaging patterns. We have too many managers, with too much hierarchy and too much cruft to get anything done. Like others who believe in agile, I believe that a small tight-knit group of talented and self-motivated developers can achieve leaps and bounds more than a project with 5 times as many developers. It can move faster, communicate easier, and get through red tape with little to no resistance. No meetings. No big hierarchy. Just talented people doing what they love to do, not more bodies to fill an org-chart and make people feel more important.

The model of software as a manufacturing operation is a horrible mental model. When software development was a new thing, these were the only tools we had. We tried to superimpose what we knew about manufacturing and put it on software but it just doesn’t work. They’re not the same at all. Today we have tools like agile and extreme programming that represent a much better attempt at fitting software into a concise model. Never forget that philosophies like agile and extreme are still models. They’re a way for us to encapsulate what we think we know about how software is made and create a new set of standards and processes that help us understand how to build better software.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.