It was Tuesday when I figured it out. Midsummer. A mildly hot day. I had a meeting that dragged for too long. I was aggravated but at the same time some useful thoughts had started to creep in. That’s when I realised that if you have a business, a single product you see a dark factory in a totally different way than if you’re an agency. Or serving hundreds of products.
This got confirmed later when I had a really insightful discussion with Patrick Debois on how they do dark factories at Tessl. We talked about a spectrum. Not a specific solution.
No Category
The dark factory can’t be a category. It’s too early for that and businesses rarely need a cookie-cutter solution.
It’s too early because we’re still figuring out what the concept really means. And whether it’s feasible at all. By the manufacturing definition of the term, a dark factory means no human supervision. So if you want to truly categorise it you should have a system that builds software without any humans involved. You just install it somewhere, put it in motion and it works. Forever. But that shouldn’t be a goal in itself. The business might get a lot out of it – after all it won’t need to pay the humans. But it might either be too expensive or you might get a good enough result by just being at some other point of the spectrum.
Businesses also rarely need a one-size-fits-all solution. It all depends on how much return will a given solution bring to them. For some businesses it might be enough to just automate a tiny bit of the process. For others, it might be reasonable to automate all of it. A third type of business might want to automate the delivery of a specific product. And a fourth might want to automate the delivery of a multitude of products.
The Automation Spectrum
On the top right you have full automation for all products that your company would ever ship. You bake in your design system, vision, processes, internal quality standards. And then you replicate them in a fully automated manner across all of your products. The dark factory is a separate system, maybe a platform that a separate team owns and configures. They’re responsible for making sure your quality is production-grade all across your products. The product teams hardly have engineers. They just use the dark factory and it’s guardrails to ship the software. This might be the most complex thing to pull of on the spectrum and it might be reserved for the most ambitious and technology-mature businesses.
On the top left you have full automation for a specific product. This is what a SaaS company might do. Or a company that has a few bespoke offerings. The dark factory is embedded into the product. The same team that maintains the dark factory maintains and evolves the product as well. Or there’s a separate dark factory team but still the factory is weaved into the product. All features come through it. Engineers are focused on soliciting specifications from the business, describing them well and delegating the implementation to the factory itself. The engineering organisation still has to be quite mature but not as much as when trying to satisfy a myriad of products.
On the bottom left you have no/little automation for a specific product. This might be either traditional teams that have decided not to use any AI in their process. Or teams that use AI but still keep the engineer in complete control of the process. An engineer gets some work, they implement it in their editor or agent, and then ship it to production. They can either review the code or rely on a good enough CI to remove the need for reviews. At one point such teams might evolve into setting up their own dark factory. But the product might be so complex that it might not be worth it or it might be too risky to do so.
At the bottom right we have the final part of the spectrum. No or little automation for a variety of products. This spectrum might have a different level of automation for products. There might be emerging some local dark factories covering some products. It’s a mixed bag of choices depending on teams, technical maturity, product complexity and human preferences.
At the end you have these four quadrants which you can use to figure out your place in terms of automation. Keep in mind that this isn’t a maturity spectrum. Or in any way suggesting a direction where you should be. Each square is a valid place for a company and whether you’d like to shift to another square or not is dependent on a lot of circumstances and aspects.
The Maturity Spectrum
There’s a third dimension to that. And that is the technical maturity spectrum. It’s easy for engineering organisations that are producing high internal quality to roll out automation. Automation will just be an extension of the current processes they have. Here we are talking about several foundational aspects.
- Modular architecture
- Reliable test harness
- Collaboration instead of silos
Modular architecture keeps changes isolated, safe and easy to reason about. This is important for AI in the same way it’s important for humans. In a fully automated software delivery process this will help AI focus on the relevant system components. This will save you context and thus tokens. And prevent AI from hallucinating solutions that aren’t adequate for the system. It’ll also greatly limit the blast radius of issues once they happen.
Reliable test harnesses prevent the regressions. Those are needed to give you confidence that no or a small amount of bugs will be shipped as you go. A reliable test harness is also decoupled from implementation so it makes changes to the system easy without requiring multi-hour sessions where you can’t merge other work into the trunk. Another aspect is that such a harness can serve as a specification about the system in a business language. On top of that you should add Expectation Driven Development to make sure the system delivers what you actually need end-to-end without human intervention.
Lastly, a human aspect. Collaboration is the key to a mature engineering organisation. People should be willing and given the time to exchange ideas, thoughts and work together on solving the challenges of the business. This will never translate to the machinery of the dark factory but is wildly important for its success. Otherwise, a dark factory would be as good as the understanding you feed into it.
Engineering organisation maturity let’s you move from the bottom left quadrant to the top right. Only if you decide you need to do it. It’s an enabler and it’ll give enormous benefits even if you decide to stay in a given quadrant because that makes the most sense for your business.
The Fourth Dimension
Lastly, we can add a fourth dimension into the mix. And that is whether you’re going to use bespoke vs. generic dark factories. Bespoke means that you’re going to build the solution yourself using your engineering knowledge.
If you go the bespoke way you have to pick the best engineers for this solution. The best ones should know what it takes to ship high quality software for the long run. Those are not the ones who constantly firefight and ship but their systems are ridden with issues. On the contrary the best engineers are the ones you rarely hear about because the systems they’ve created are stable and generating profit for your organisation at the same time.
If you go generic, you should be really careful. There are a ton of solutions out there. Some good, some bad. But the field is so new that you can hardly trust any provider to help you integrate a system that will work out of the box reliably. If you can’t build a bespoke solution it might be better to skip building a factory at all than relying on a generic provider.
Conclusion
Those are just some ways to start reasoning about what a dark factory is. And disambiguate this term in our software industry. We have a spectrum that’s about automation vs. how many products the factory spans. This spectrum is not in any way prescriptive and evolution in its context doesn’t mean better. On top of it we have engineering maturity. Which is an enabler for both going to the top right of the spectrum and shipping better products regardless where you are. Lastly, we have the choice of whether to get a bespoke solution or a generic one or anything in between.
