Software Factories

I am uncomfortable with the factory model of a software development shop.

I heard it from a seasoned tech exec decades ago. Effectively, the dev shop is a factory that takes in requirements and produces releases. Basically, it’s a bunch of software assembly lines.

The obvious problem is that it indirectly implies that programming is similar to blue-collar work. That you get a bunch of programmers together, tell them what to do, they do it, and then the results get shipped. It is sort of treating it as if it were all physical, not intellectual.

While that offends the idealist in me, it is pretty much the case now that most software development is routine. Libraries and frameworks deal with the hard parts, most coding is just gluing it all together to meet a specific goal. If you read the tutorials and basic documentation, any sort of missing answers can be found on sites like StackOverflow. You can learn the basic skills fairly quickly, and in most cases just keep applying them over and over again.

There is still a ‘rapid comprehension’ issue. That is, you might have found the answers, but you still need to understand them quickly. Active programmers are usually continuously learning stuff. It’s like being in school, and it is almost never-ending. Maybe if you stayed on the same codebase for over a decade there isn’t much left to learn, but for most coding positions, there is a vast unknown.

One of the tweaks to the factory model is that analysis is inside the factory, not outside of it. The requirements come in the front door, but the analysts venture out from the factory to investigate and flesh out the issues. They could be specialized roles like Business Analysts, but often they include all people heavily involved in the design like architects and development leads as well. You can’t really build a good solution if you don’t understand the problem.

The other major issue with the model is scaling. Big companies with lots of IT needs, tend to behave like a lot of little independent factories. This means they are each redoing the same fundamental work, over and over again. Besides being highly inefficient, it also leads to severe quality issues. The organization never gets competent at producing software, even if a few of its factories do. But they tend to disperse, taking all of that knowledge with them.

It would also be better to have some reliable horizontal factories at different levels that support the vertical factories for business needs. That is, you get groups of developers that write backend technical stuff, that is mandated to be used by the other developers. Obviously, enforcement is a huge problem, in that the quality of work for the lower-level developers has to be extremely high, or it negates the usefulness of the effort.

One of the good things about the factory model is that it clearly delineates the boundaries of development. That is, the factory produces updates and versions and stuff, but it is isolated from the act of ‘operating’ this stuff. It sort of implies that a well-run dev shop is rather quiet and focused on its work, even if the business itself is rambunctious and full of stress. Obviously, that would be far better for quality. You can’t code very well if you are constantly being interrupted. You don’t need perfect code, but the side effects of running bad code can be hugely expensive.

And that split between development and operations is super important. They are different mindsets, so pushing the devs heavily into operations issues just tends to just burn them out. They should be focused on engineering things to work correctly, and while they should obviously get a lot of feedback to ensure everything works as expected, they don’t need to be front and center in the ongoing operational issues. Rather they should complete their work, then ship it to others who will put it into production, monitor it, and deal with any unexpected behaviors.

So, while the factory model bothers me at times, there are aspects of it that I wish more people understood and paid attention to. You often see these development shops where everything is hopelessly blurred, people are stressed and confused, and the work is going very badly. We need to find better ways to structure the work so that it doesn’t cost so much and take a crazy amount of time to get done. We seemed to be getting worse at building software, not better.