Summary

When Common Practice becomes even more commonly-practised, the economic forces on software design change in a way that both creates more opportunities and makes it harder to seize those opportunities. I suspect that means that so-called “better” design will remain up to the individuals who decide that they simply enjoy their jobs more when they get to work in more-habitable code.

As we use LLMs to generate more code, Common Practice will become even more common, which creates an amplifying feedback loop entrenching Common Practice, even when what people are commonly doing seems unwise.¹ This means that we’ll see more code with more code smells that could be improved. More opportunities.

As we rely on LLMs to generate more code, there will be mounting pressure to do more with less. Programmers tend to react to that pressure by writing more code sooner (so let the LLMs generate it) and feeling pressure to look less carefully at the results (even when they know they need to monitor what the LLM produces quite carefully), even when that’s (clearly) unwise (and they know better). This means that we’ll see more code with code smells that simply won’t be improved, even in spite of everyone’s best efforts. More people will have less time (and less energy!) to seize the obvious opportunities in front of them.

The optimist in me hopes that the companies with “better” designs² will realize the benefits that come with “better” designs and stand out even more from the crowd with their ability to adapt to changing market forces. They would pivot sooner and more easily, feeling less resistance to make difficult business decisions and to take reasonable, calculated risks.

I am worried, however, that there will merely be a bigger population of mediocre companies for the average companies to (barely) outpace. As a result, those average companies will still have designs that mire programmers in frustrating busywork, rather than allowing them to better meet the demands of (reasonably) impatient stakeholders and customers.

Where Have I Heard This Before?

Patrick Lencioni wrote that teamwork was the business world’s richest untapped competitive advantage. Even decades after he wrote this, from what I can tell, not much has changed. Not enough folks understand the power of teamwork and find themselves with the combination of influence and opportunity to demonstrate its power. I think we’ll be writing in similar terms and more intensely about “better” software design in the next ten years or so.

I only know that I enjoy my programming work more when I get to live in habitable code. Maybe that’s how it will be: we will meet each other from time to time in warm, dry places where we invest in our own comfort and joy, whether our employers like it or not, as much as we can, for as long as we can.

Same as it ever was, I think.

See you there.

In a LinkedIn post, Joshua Kerievsky pointed out the proliferation of design risks (“code smells”) in the code that LLMs were generating. He raised the example of discovering a race condition made worse by polling, where it would probably help more to introduce explicit events to handle the concurrency.↩︎
I don’t like to refer to designs as “better” or “worse”, because that glosses over the complexities of software design. Even so, we occasionally need to resort to shorthand for brevity, such as I’m doing here. When I write about “better” design, I mean organizing the source code in ways that reduce the cost of a human understanding it so that they can change it safely and accurately.↩︎