Recently, payments processing company, Stripe released a report about developer efficiency. It posited some great questions and arrived at conclusions that are useful. I, along with others, contend that they missed the mark.
Firstly, here are a couple of their starting points:
It’s not what you have, it’s how you use it.
Developer talent is hard to come by, but companies aren’t deploying their developers in the best ways.
Companies are constrained more by the existence of developer talent than capital.
Finding actual developers who are skilled and motivated enough to build good software is becoming more and more challenging.
Essentially, around the world, companies’ need for developers is only on the rise. 56% of companies around the world indicated in the last year that they had more developers than the previous year.
The report also provides assertions about how developers use their time.
'Bad code' costs companies $85 billion annually
When I saw that, the first thing I thought was why are they making this a problem in aggregate? “Cost companies” lumps together in a way that in reality does not fly. All companies creating software aren’t the same. In my mind, we should be asking, “How much does ‘bad code’ cost us?” In fact, what are we even calling “bad code”?
Going further into the survey, this question was posed:
How many hours per week do you estimate developers at your company waste on maintenance (i.e. dealing with bad code / errors, debugging, refactoring, modifying)?
The idea that the survey lumped ‘bad code’ with debugging, refactoring and (general) modifications strongly suggests to me that they don’t really understand the software development process. Those areas are very separate things. Knowing how each contributes to costs in software projects is critical. If only because addressing each requires different kinds of resources.
In fact, ‘bad code’ is such a generic label that it almosts masks true meaning. Let’s say that going forward, ‘bad code’ is code that produces clear errors in the execution of software. Errors here being exceptions or output that was clearly not specified. Thus, ‘bad code’ is not spaghetti code, or poorly architected solutions. It’s code that does not work.
How an organization deals with ‘bad code’ therefore, should be different to how it deals with other forms of software quality issues. Bad code may lead to increased software testing by developers themselves, typically automated testing. Whereas, poorly architected code, or messy code may lead to increased design activities, involving stakeholders like product owners or software architects.
"The amount of time developers at my company spend on bad code is excessive."
Following on from above, almost 60% of the respondents agreed with the statement above. Making software quality a question only of code and not of design or inputs from stakeholders and natural evolution leads to perspectives like that. It begs the question, if the time spent on ‘bad code’ is excessive, who wrote it? The same talented developers hired by the companies in this survey?
There were then a few questions on trends, like the number of developers needed and the sort of technologies expected to be a big deal over the next few years. The funniest response to all of these is the one that says companies have sufficient resources to respond to the coming trends.
I find that laughable because if companies admit that developers are currently spending time so poorly with existing technologies, why would they have time for the new stuff. And this shows in terms of AI, as an example. With AI, data scientists are now learning about CI/CD and general principles of software development. Thus, I expect in 5-10 years, the timeframe used for the trends above, we’ll be hearing about inefficiencies in the development of AI solutions, just like the complain now.
As I said at the top, Stipe et al seems to have missed the mark. Not because a company has software developers or software development taking place in it means that they have a firm grasp on what a quality software development process looks like. Thus, when developers spend time refactoring and curating code, it’s only considered wasted time if you don’t grasp that the nature of effective processes in software development is evolutionary. Some of the questions in the survey are good and we should look to answer them with greater and greater accuracy, here at Teleios, but steer clear of jumping to conclusions too quickly.