Simplicity, Agility, and Agency

Development doesn't have to be this complicated

I was one of the people who helped create the Manifesto for Agile Software Development. I’m proud of what we did, and I still believe that the four values are as important today as they were 25 years ago. I had hoped that it might improve the lives of developers, and for a while it did. No longer. What people now call Agile has become the kind of overbearing set of practices that we were rebelling against when we drafted those values.

For the values of the manifesto to work, we have to change the world. And the world has other things on its mind at the moment.

But I’d still like to find ways to improve the developer’s lot.

Take Two

We can’t control our world, or how our company runs. But I’m startinging to think we don’t have to. We still control and incredibly potent assets: ourselves.

We developers tend to forget just how much control we have over our daily lives. Sure, we have structure imposed on us, but that’s typically at the per-day, per-week, and per-sprint/release level.

So let’s stop trying to change the world, and instead focus on changing our world.

Acknowledging that we can do that is step one. Step two is setting some goals.

To my mind, there is no bigger goal right now than reducing the insane levels of complexity we work with.

Some folks may be thinking that the incursion of AI into our working lives is the number one threat. I disagree. AI is a powerful tool, but a lot of its power comes from the fact that it relishes complexity; when you see programs of a whole, as a mesh of parts that interact, you have no need to be limited by human design principles. Who needs DRY when you can immediately see and change every use of a function or some data?

But that’s a tactical view. There comes a point where you cannot afford to ignore the structure of what is being built. If interactions in your system grow exponentially with the number of parts, there’s a point at which no technology can manage it. And by that point, it is too late.

One of the reasons AI often produces bloated code is that it merely extrapolates from the code it has consumed during training; it is the ultimate but we’ve always done it that way engine. This is just cargo-culting.

The sad thing is that human developers do that, too. We look for answers from people who seem to know what they are doing, adopting their designs, tool choices, and often their code to create complex patchworks of code, code that is hard to change, and code that is vulnerable to the inevitable changes in the tools and libraries on which it is built.

So I come back to the idea of reducing complexity being the most important thing we, as individuals, can do if we want to reclaim control over our daily lives.

I believe this so strongly that I spent four years writing three books about it. The first two I threw away; I discovered you cannot tell people how to simplify what they do—simplicity is always contextual. The third book took a different (and, for me, uncomfortable) tack. Rather than tell folks what to do, I give 29 examples of ways I have found, in my particular world, to make what I do simpler. The idea is not to copy me: that wouldn’t work. Instead, I hope the examples illustrate the thinking behind these simplifications, the feedback loops I used to notice that something was getting complicated and then to monitor my progress as I experimented with simplifying it.

Is this article just a lame-ass attempt to market my new book?

Sure.

But it’s an article I would have written anyway, book or no book. In many ways, we developers are our own worst enemies. We follow fads, join cults, and adopt practices. We sometimes do this because it looks interesting. More commonly we do it because we hope that one day we’ll find the silver bullet that puts to rest our fear of failing.

Ironically, every time we do that, we add complexity and stress to what we do, which in turn just accelerates the cycle.

So, buy the book if you want. But, regardless, think about how you, personally, can reduce the complexity in your (professional) life. Think about the things you take as a given (exhaustive testing, stand-up meetings, the framework du jour) and ask how you could test to see if they aere actually making things better. How you do things can be refactored in the same way as the things you produce, and the same rules apply: you need an objective, a timebox, and feedback.

It is difficult to make things simple. It takes a conscious process, applied over time.

It’s worth it.

\(\huge {simplicity: now\ available\ in\ epub,\ PDF,\ and\ print}\)

---

---