Maximizing Developer Effectiveness

Are you serious? The "right" infrastructure? Are you limiting your view to a single service, running on a big cluster? Because even then there are permanent conflicts in the persistence layer and resource conflicts express themselves in huge infrastructure bills.

But things get really messy when your software is distributed in heterogeneous environments. Say you ship a database yourselves. Or a multi-platform app, or a game, or the control software for medical devices, or...

Software development is not just running the next SaaS product.

I think there is this duality in SW development that some people tend to believe in, that there are two types of work, one highly creative, like product or architecture design, and then the mundane one, like coding and testing. (I actually realized this reading a recent HN post: https://news.ycombinator.com/item?id=25775872)

I don't subscribe to this, I think the work is ultimately very similar in creativity (just different skill set), both on high and low level. If something seems mundane, it is either a sign that there is lots of hidden entropy that you failed to capture (and thus risk that the high level understanding is wildly incorrect), or it means that we are doing things conceptually wrong (with more effort than required), but we don't know how (and so there is potential for innovation).

And from that duality is derived the idea, that if only we can perfectly specify the mundane work (for instance through "acceptance criteria"), it's just a matter of getting enough bodies to do it according to some grander plan. From this misconception derives the history of software development methodologies.

So originally, people thought, this duality is the same as in building a house, you have an architect, he does the design, and workers (coders) will build it. So the waterfall was born, where the emphasis was on the plan, and it was also the weak point, because in the real world of SW development, it turns out, the actual implementation influences the plan (so the architect cannot just throw it over the wall, as they say).

Then, from the disappointments, Agile movement was born, pretty much out of the idea that all development work is creative, and it cannot be easily formulated/predicted, so we basically need to iterate quickly and hope for the best. Just treat everything like research.

But, as it happens, people promptly misunderstood this (where are my metrics now??). Instead of understanding that the belief in the duality itself is the problem (a kind of wicked problem, really, because it can manifests in many ways), they looked at superficial recommendations of "Agile practices" - Scrum rituals, "embracing change" and foregoing proper planning, etc. (For me, good summary of this discussion is http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile... and https://simpixelated.com/two-year-work-retrospective)

One can draw an analogy to this duality in other industries, it's a problem older than software. It seems that with technological and process automation, other industries are actually becoming more like SW development (aka "software eats the world"). So elsewhere, this belief in duality gave rise to Taylorism (https://en.wikipedia.org/wiki/Scientific_management), and the rejection of the duality gave rise to Demming's philosophy (https://en.wikipedia.org/wiki/W._Edwards_Deming) and the related management methods (which were, again, misunderstood, I am sure). There the fundamental notion coming from the duality is that it's the management (or anybody else not doing the actual production job), not the workers themselves, to decide how to effectively organize it.

And still, to this day, some people intuitively cling to this duality, and try to apply Taylorism instead of something like Kaizen or Kanban to SW development (and certainly not only that). So you have JIRA tickets and people beancounting story points..

I'm torn about this article, I love the part about feedback loops and optimizing the parts of your day where you are in a tight loop for a long time; but for most of the article it seems he is _almost_ saying something profound, but there is too much clutter and buzzwords around it. I know these abstract consultancies have a use, but they seem to target what managers and executives _want_ to hear instead of the truth.

e.g.: "The promises that were made to executive leadership about the latest technology are not coming to fruition quickly enough."

It feels like he then proceeds to talk about how management can get the developers "organized" to make sure they get the job done. Having a developer doing support for the day kinda sorta seems like a nice idea until you realize that "Isn't that what the manager is supposed to do? Understand his team and get what they need/negotiate with other teams so that they can just get their work done?" It's kinda like he's telling managers how to outsource their work to someone else. Pass the buck and live in a fairyland.

I know people who idolize Thought Works, Martin Fowler, Uncle Bob, and others in the "consulting set"-- but it seems like they fill a particular niche, and it isn't the phenomenal tech experts, it is more of the "how management views tech from an academic level and how we can get these interchangeable programmer cogs to get our project done w/ the least amount of effort". They rarely give hard advice, it is more of soft exposure to "new tech" and "here's something that works for some people, you might be that person". "We'd love to sell you on new tech that will be a silver bullet for all your problems"

In any case, I learned some interesting stuff from the article, and I do think it is a valuable read.

In my current team (and my previous one from another company) we have what we call "goalie" duties. Each week one engineer from the team is responsible for answering inquiries, not necessarily they have to know the answer but they are the ones to be interrupted and handle accordingly.

It works pretty well, our devs are capable of assessing urgency to either bring it up on Slack, wait for the next stand-up or call to arms if it's something critical.

It improves rapport with stakeholders and other teams; it improves morale, it's predictable who will be interrupted during the week, alleviating that from the rest of the engineers. And as a side-effect it helps to force knowledge sharing over time.