Dev Silver Bullets Still Don't Exist

It's a losing proposition to think one can make the final, best decision for all development going forward.

To centralize all dev decisions in time and space is folly. 3 main factors are too variable: devs, time and products.

Different Devs

The quip is that if you ask 2 devs a question, you'll get 2 different answers. It's reliably true.

We have opinions, like most humans, and maybe more of them. There are unreasonable cases, sure. But let's put those aside for the moment. You wouldn't hire someone with years of experience, with hard-won perspectives and preferences and then discount them. So, you actually like these opinions.

It would sure be nice if there weren't so many opinions, though. And, indeed, perhaps there don't need to be. But a creator should have taste. And we create in a very malleable medium. And in a fairly new craft, that's only been around for 80 years or so.

You, Over Time

And then there's the dimension of time. Even you, yourself, you change. You never start the same project twice. You develop wisdom and taste. You learn lessons from your recent folly. You continue reading. You continue honing your craft. The industry zeitgeist evolves.

You can also regress and forget once-held wisdom that you're now going to ignore, perhaps because you simply forgot it.

Specific Problems

What you're solving might belong to a class of problem, so there are patterns and practices to draw upon. But the specifics of the situation will vary wildly. In fact, in combination, they'll be unique: the people you have to communicate with; the needs of the company; the pressures of the moment; the creative constraints; your teammates; the available timeline; and the actual problem to be solved.

If you're making bespoke solutions, your product impelementation will be one of a kind.

Temporary Success

Let's say that you felt you could tame the variability. You started a greenfield project. It felt like, "Now, we can make the right decision. We'll right the ship, and this is how we'll do software dev here from now on. This is a pattern for the future."

Yes, it'll probably work for a while. But it'll never settle down, not until you step away from the keyboard (and that's not how SaaS companies work today). So, at a point, sooner than you might admit, your successor will be looking for the time and space to right the ship, do a rewrite and lay down the real new pattern for the future.

The Allure of Frameworks

We want good patterns to follow, because real creation is very hard -- even magical when it happens. We look for a batteries-included framework, someone who's blazed the trail before us.

But even framework creators, by this time, have realized that they won't solve for every problem. Escape hatches are needed for real, unique problems. Moreso, what boxed software hasn't needed to be unboxed (patched, wrapped, or with a plugin) when we try to use it for some real-world problem?

The Constant is Change

Your green field will one day be a brown field.

Your project template will always need updated.

Your devs will always fight against a centralized framework.

Your teams will always have a hard time staying consistent to project norms.

Your current design choices will always be disliked by the next generation.

In other words, no software choice lives forever. It'll probably last less time than you'd be proud of or comfortable with, if you knew the future, now.

Manage Change

So, if we have constant change to manage, and we avoid fooling ourselves otherwise, how can we help ourselves?

Yes, make clear decisions based on tradeoffs. Then limit their span of influence. Couple the minimum amount needed to that destiny. Recognize the real limitation of control (and curb your desire for it overall).

Write less into software. Make smaller, focused solutions. Avoid modeling the world in software. Attempt to solve a real problem, not create a software-driven utopia.

Not all problems are best solved with software. You have a programming hammer. Not everything is a nail.

Allow experimentation. There are operational efficiencies to be had by consolidating technology, and deep knowledge investment is valuable. But don't block avenues to newness. Devs may need their enthusiasm for the shiney things tempered, but good devs keep their options open and sense when to examine new solutions.

Ship some software, then let it alone. It's good enough. If it's simple enough to be reliable, it could survive for some time, if no one tips it over trying to make it better. Move your product manager on to something else. You have some self-sustaining software, now run the business on it.

Plan to retire your software. The rewrite will happen. Yes, it's a bad word, and yes, can be difficult to avoid. Last year's weeds will be ploughed into the garden of a new Spring. Considering this future reality might encourage you to make the present less expensive.

All software is accidental complexity. The problem domain had its inherent complexity. What you add to it to solve the problem is all net new. Otherwise, you wouldn't need all those software developers. Simplify.