I had a code interview the other day that I failed. I tried to adapt a solution from a similar problem that I had in my head, but about 25 minutes into the 40 minutes allocated to coding, I realized the problem was just that little bit too different from the solution I was trying to adapt, but I didn’t have time to pivot. In reflecting on this, I realized there are some parallels with the experience of working in the Agile paradigm as it is most frequently manifested.

Agile, much like an interview, is, at root, all about time boxing. Systems and their components are designed so their implementations can be neatly chunked up and stuffed into predictable boxes. This isn’t really surprising, when you think about it; Agile comes from industrial manufacturing, and this is exactly how you efficiently manufacture things. You get a stamping machine, you get a couple different dies, and you run that machine until it breaks. The incentives are for risk mitigation, not innovation; how do I turn as many profitable problems into things I can stamp in the time it takes to stamp a thing.

The thing is, no where in this incentive structure is quality or innovation rewarded. We end up with systems that are jumbles of stamped parts rather than optimized or even really designed solutions to problems. People are promoted to senior and lead for being faster at stamping parts or more familiar with the quirks of more dies. People are promoted to manager and staff+ for being good at keeping the stampers on schedule or for being good at jerry rigging stamped parts to address narrow business problems. All the while, no one is really thinking about the problem being solved, and whether the stamped parts are the best, or even a good solution to them.

I would argue that much of our tech debt, and much of the velocity killing technical bureaucracy and inefficiency we deal with, comes from this parts stamping approach. To mix metaphors for a moment, we can’t see the forest for the trees, and we build ourselves into corners because of it. We’re so focused on efficiently lining up and cutting down trees, we don’t notice that we’ve driven 5 miles from the access road straight into a swamp, and the sawmill stopped accepting logs 2 days ago anyway.

Software development is, at least in part, a creative pursuit. Creativity requires experimentation to achieve anything worth achieving, and experimentation can only exist with risk. Sometimes, a good solution only comes out when you don’t know for sure where you’ll end up going in, and if you go in not knowing where you’ll come out, sometimes, you just don’t come out at all. As an industry, we’ve focused so hard on risk mitigation through process that we’ve almost entirely eliminated experimentation and creativity, at least for anyone below manager/staff levels. The thing is, having been eliminated below those levels, people making it to those levels have never really developed the skillset, so now we’ve largely eliminated it entirely. I think we need to change that.