Software Bureau

I don’t like the concept of a “software factory”. I don’t think it’s the future of software engineering. At least it’s not at the center of software engineering. A factory assumes we mass produce copies of the same product over and over. In reality most enterprise software consists of complex dynamic systems that constantly evolve while being actively used. This implies constantly changing design - definitely not something that can be built on a conveyor. I think we need a better analogy for software engineering. My favorite right now is the software bureau.

I imagine a software bureau being similar to an architectural bureau. It’s staffed by specialized designers and engineers, not easily replaceable conveyor workers. All of them work together on understanding the requirements and restrictions. The products of the bureau are designs and blueprints (models and specifications). These artifacts are then passed to “contractors” who follow instructions strictly to shape the system.

Looking at the amount of effort people invest right now in “software factories” and building pipelines, I don’t think we will see a lot of new “software bureaus” soon. My hope is in people who haven’t absorbed all the legacy of software engineering. Perhaps those same juniors who companies don’t want to hire anymore, who are interested in building complex systems but haven’t been taught the “old way”. They will see real problems and will figure out better solutions.

But it doesn’t mean you can’t start doing this right now. The same thing that started the current wave of the “software factory” craze - large language models - might actually help you create your own little “software bureau”.