(can also be read on Medium)

Software Development is involved in almost any transformation, strategy implementation or move forward for any business or organization.

More than ever before the bad decisions of software developers can stifle the best laid plans, strategies or initiatives.

The (new) role of software development

As IT has become less of a differentiating factor and more of a precondition or fact of life, the demand of IT is usually not to leap-frog ahead of the competition with advanced software or software capabilities. Rather the demand of IT is to be able to meet changing business demands and strategies at a quick pace and with a low failure rate.

This, I contest, goes a bit counter to the view held by many software developers and software development organizations today.

Much of the hype we hear and the behaviors we are pushed to emulate, have to do with “market conquering and monopolizing” technical leapfrogging, not the month-to-month, year-to-year IT facilitation and support of the business og organisation. The latter being the bread and butter for most software development.
It is worth noting here that the technological leapfrogging is most often a mirage, and more often than not, the market conquering/monopoly actually was a result of a combination of the business model, execution and pure chance. Not the underlying IT solution or landscape.

You do not need *SuperCars* to compete in the taxi business. You do not need *SuperTrucks* to compete in the container truck-logistics business. You want cars or trucks that are fit for purpose, low cost and stable. This acts as a precondition for all the other avenues that can be pursued to “win in the marketplace”.

The same has become the case of software. We do not (typically) deliver the silver-bullet-software that singlehandedly makes our business or organization succeed and dominate in the marketplace. We deliver a platform, system or application that provide capabilities to the business so it can seize opportunities.

What this “new” requirement to and expectation of the software development teams means, is that it is extremely important to identify the “stripped down” solution, the shortcuts and the essential core of the solution, and the smallest increments toward the goal. Not go all in with knee jerk architecture platitudes like clean onion architecture with domain driven design decoupled by messaging.

Building the solution with all those horns and whistles, may improve our speed a few years down the line. If we knew what to build. And how it should be built. Segregated. Tweaked. And so on.

But we don’t.

And even if we did, the short-term gains, insights and early-to-market, may be worth the complete rewrite down the line. That was the case for most, if not all, of the FANGS (Facebook, Amazon, Netflix, Google, Spotify). And needing to rewrite, scale and handle growth or success, is a nice problem to solve. When you have succeeded.

What do we want?

What we want is quick feedback and learning. Quick iterations and small, safe increments. Fail fast (i.e. cheap). Continuous course corrections. And full flow feedback.

And to get the quick feedback — we need to create a solution very quickly. And the solution needs to be “relevant”.

To create such a solution quickly and get the ball rolling, we need to identify what is not essential.

Where Mozart said about (I assume great) music that “it is not in the notes, but in the silence between”, great (and good enough) software is not about all the components, connections, details, patterns or tech but the absence of unwarranted complexity. That is what produces not only great software, but also simplicity which is a prerequisite of (continued) delivery speed and value creation.

We depend on the psychological safety, culture of and discourse to call out inappropriately dressed emperors when we see them.

This requires people very confident in their abilities and craftsmanship. It means that when a person calls out something as unwarranted complexity or hype-buzz TAP (Technology, Architecture or Paradigm) and is met with:

you are just old/stupid/retrogressive and don’t understand all this new awesome stuff

, they stand their ground.

Then both parties together must meticulously and constructively go through the underlying reasons why the complexity or introduction of hype-buzz TAP is warranted and necessary. Or, more often, unwarranted and unnecessary.

It is extremely important that they weigh the value assumed and projected in the discussion, and that this is used to guide the decisions.
It is furthermore important to flesh out, what simpler or quicker solution(s) could be chosen instead. This mitigates two problems. It mitigates the very real danger and risk from non-essential TAPs.
It furthermore has the chance of introducing a simpler approach or alternative, reducing the software development friction, complexity and overhead down the line.

The old grumpy dev

In my experience, there are few out there in the real world doing this by default. Typically, it is one or a few quite senior, very battle-scarred, no-bullshit and a bit grumpy developers. Or at least, they can come off as the latter. These developers create great value by reducing risk and mistakes in projects. If we allow them to speak. And listen. And discuss. With appropriate discourse, rules and culture. I.e. value based.

In some development environments the old grumpy dev is stifled by taboos about “being against the bleeding edge” or fear of being behind. Or demotivating people, by not letting them try out the newest TAPs. (But failing because of a TAP is much more demotivating… and seeing something succeed much more uplifting. Trust me…)

The scarcity and impact of these people is further exacerbated by the battle-scarred devs moving up the ranks on the management side or spending most, if not all, their time in the stratogysphere.

I think a lot could be gained by allowing some of these well-versed, battle-scarred, conservative (old and grumpy) devs, continuously spar and coach individual developers and teams.

(Obligatory reservation)

(Of course, there are also organizations where the old grumpy dev is too conservative and standing too firm. It is, as with everything else, a balancing act. But currently I see it as tilted way too much towards the TAP-rollercoasters — with way too little insights into what our role as developers is.)

The (new) roles of software developers and the old grumpy dev

We (software developers) should ensure that the organization or business are enabled to deliver on their targets, strategies and plans in a sustainable fashion.

We are not the stars of the show anymore. We are the backup singers and we should make the lead singer sound good and remember that a big part of that, is done by keeping in the background and with appropriately timed and well executed absence and invisibility.

I believe the old grumpy dev plays a huge part in this, through sparring, coaching and inducing the right discourse and culture.

Not as a full-time member of the teams, but as an on/off ad hoc advisory role.

Pushing the old grumpy dev into management, a single team or an ivory tower, lessens the value they create and the impact they induce.

(It is important to note here, that I see it as an essential competence that the OGD understands and encourages value based technical decision and discourse. Otherwise the rest below does not apply:-))

The old grumpy dev is in short supply. And their insights in high demand.

The old grumpy dev can produce most value, by being spread a bit thin over several teams, organisations or business. It lessens risk. It avoids unnecessary work. And keeps the developers focused on delivering actual value.

In other words, let them be 10X dev by proxy.