selective focus photo of brown and blue hourglass on stones

Competency in software development, the hidden cost

There’s a hidden cost in the software development industry that often gets left behind by any kind of productivity metric that processes like Agile try to quantify. In fact, unless you do rigorous Agile in the sense of proper planning poker between the senior and junior developers and striving hard to have a facilitator on-board to ground the discussions and communication towards finding the balance of complexity a feature or user-story has, it will be probably impossible to pinpoint this hidden cost.

Now we all know that nobody does Agile rigorously. In fact many have “adopted” Agile to their business which basically means there’s a faux-Agile in the interest of business only hidden as a form of corrupt and evil project management. In such an environment, this hidden cost that grows can only thrive and flourish.

The hidden cost I’m talking about is that of competency. Which either I’m growing too old but it seems it’s lacking greatly these days. What got me writing about competency is a recent project handed-over to me, through my architect, a few weeks before deadline which is a little on the side of absurd.

In the current team that I’m in there are two flows, one analytical of transforming some binary data to Parquet (which I’m handling) and one real-time that gets to a database used to power the UIs. Nothing fancy, just your regular fast and slow data. Our team is somehow divided this way also but to the extent that we’re pretty much capable of jumping ship anytime needed to understand the other system and maintain or work on it.

A few months ago, our architect presented a new project. It got assigned to the other team. The project pretty much just applies a computation over the last N days of data so it was a better fit for a batch approach to processing. The project also had, let’s assume or say, around 4 weeks of development.

All fine and dandy … for the past 3 weeks however, the output of a senior colleague has been not much and not less than 600 lines of code, mostly boilerplate Java and Spark that upon inspecting, in about 3 minutes, we could’ve identified it was a pattern (an union job basically) that could be made agnostic and configurable.

Here’s the competency cost:

  • there are 40 working hours per week x 3 weeks means 120 hours;
  • 600 lines divided by 120 hours of work means the amazing speed of 5 lines of code per hour;
  • the company paid 3/4 of a salary for the development speed of a snail;
  • the code is rubbish after first inspection and a pattern oriented mind gauged that it could be refactored, at first view, in under 3 minutes;
  • the architect asks I take over the orchestration of those jobs;
  • our common co-worker gets to relax while I still have only 1 week to do the work, under time pressure and without enjoying it. I am so pissed at this I’m thinking of rage-quitting in revolt;

I’m not advocating for lines-of-code/h or any other metric. For sure that is no metric of productivity. But there’s a cost associated to the lost time, to the delays that will be introduced by me (I may do it faster and better, but I ain’t no Superman) and the time pressure, probably unpaid overtime that I’ll put just to “take one for the team” and make the team look OK and the projects on-schedule.

Now if I were back in my 20s such a situation would look like: “Yeaaah! A challenge!”. But I’m in my 30s and more and after many years of politics play and “taking ones for the team” … one grows a sensibility and awareness for such situations, which starts triggering alarms.

The genius or the art here is how well our common colleague has played both the architect and me … with the architect following the delivery of the feature and thus selecting me to join the project so as to speed things up and me for being a fool and trying to be helpful in that situation.

The “art” here is how our common colleague played the fool, constantly complaining about help, got away with writing 5 lines of code/hour, got the project delivered for implementation to someone else, which, if it happens to fail delivery because of the wasted 3/4 of time, he won’t get blamed for it.

Because while we do advocate a “blameless culture” we still try to identify scapegoats, cause it’s just human nature to avoid consequences and have someone else take the hit …

So yes, the cost of competence is hidden and manifests itself as regular interactions and hand-offs (if we can call it that in this particular case). But it creates friction, unpleasant pressure in otherwise enjoyable work, only to lead to turnover and with that reduced speed (of the team) by having the more competent or capable leave out of anger of being set-up to fail …