The Conduit Problem in Software Engineering
There's a label that gets thrown around in engineering teams like a mild insult: overengineer. A manager once told me I was doing it — spending too much time thinking beyond the immediate problem. Designing for questions nobody had asked yet.
The work in question was figuring out how many machines should train a model. The big idea is that we can right-size the software. Tweak a parameter just right so the training uses less machine for the same result, thus banking extra revenue. That's easy enough. Maybe reduce the memory, increase the CPU. We can tailor a tweak for one model, count the dollar gain, and that's a compelling item on the next promotion cycle.
What I found, however, is that everyone had that same idea. The work of one team improving the model would be erased by the next team with the same idea. As everyone competes for impact, they step on each other's toes.
It became clear that the problem to solve was not just what value to set the knob to, but also how to federate everyone's desire for adjusting the knob into a single framework that behaves well with each other.
My boss thought it was overengineered. Why would we help the other team doing the same work? And why would we spend time on a framework that wasn't needed right now?
The name for this is YAGNI, which stands for You Ain't Gonna Need It. Do not build for what is not immediately necessary. We don't know if we will need it. If we don't, then we have wasted time.
The house with no conduit
There is a parallel for this in home construction: the electrical conduit. When a builder makes a house, they can install eletric cables along the wall, either by just stapling them to the studs, or by installing conduits — metal pipes to hold the cables, and guide future cables should we add more.
When the house is built, we don't need conduit. We just need the outlets we add now. The installation with conduits, though, is superior because it gives room for the unforeseen. What if we need stronger electric cables for a car charger? What if we want to network the house with ethernet cables? What if ethernet is old technology and now everything needs to be optical fiber? The conduit lets us do that. If we applied YAGNI when building the house, we would have to tear down the walls to make those upgrades. Penny-wise, pound foolish.
Software conduits
In software, we can do the same as placing conduits in a house. We can prepare interfaces to express concepts. For instance, a TuningOptimizer, which given a model and available machines will determine how many to use. Maybe today it only has a constant implementation; maybe tomorrow a team will want to implement a TuningOptimizer that uses machine learning to determine its results. It's not needed today. It might never be needed, but the door is open.
Why build conduits?
The conduit is not about the EV charger or the ML optimizers. It's about acknowledging that we don't know what the future will be. We know, however, that if we prepare now, we can tackle the future needs more cheaply, and faster. Importantly, the conduit is not about placing the future cables yet. It is about recognizing that if we needed to place them, there is work better done today to make it easier. That's not overengineering. That's just seeing further down the road.
When big companies like Meta, Google want to be able to keep innovating quickly, then they need to put conduit in their software. It is what will make it possible to add new features in weeks instead of months. It sometimes frustrates me when they don't recognize that, and instead make a bet that they will not need to solve anything more than the problem in front of them. They will not need to refactor, rebuild. That tomorrow's problems are not worth the investment today. It is almost never a good bet.
What frustrates me isn't the disagreement over how much planning for the future is needed, though. It is reasonable to discuss how much is good planning and how much is gold-plating a system that doesn't need it. What frustrate me is the systemic misidentification of shortcuts as virtue.
Tech debt accumulates, and every decision to do the minimum adds a little bit to the bill that will eventually need to be paid. The shortcuts are not born from laziness: they are incentivized by performance systems that reward what is fast and visible, and discount what is foundational. The best engineers I have worked with were the ones who could see past that. Who placed the conduit before anyone thought to ask for it.