Fascinating! I spent the past two days at a software conference in the Barbican. (The SDD conf). The place is truly beautiful in a brutalistic way. Had lunch in the greenhouse.
Agree -- maintainable code was always important, but even more so in the age of AI. Unless we introduce proper guardrails via reliable code quality metrics, all these AI assistants will serve more as legacy code generators than genuine help.
That paper benchmarked the performance of the most popular LLMs on refactoring tasks on real-world code. The study found that the AI only delivered functionally correct refactorings in 37% of the cases.
AI-assisted coding is genuinely useful, but we (of course) need to keep skilled humans in the loop and set realistic expectations beyond any marketing hype.
There are two books which I keep coming back to learn from:
* Structure and Interpretation of Computer Programs: SICP changed the way I view programming. It's an excellent intro to the mindset of solving problems with code and how to iteratively build up a software design. You need to be comfortable with Scheme, though, in order to get the most out of the book.
* The Mythical Man-Month: Not strictly about programming but more on how to succeed with software projects. Hence, The Mythical Man-Month is more about people than code, which is why it has aged so well: people is a fairly stable construct.
I'm not John, but I'm one of the authors of the research paper. Indeed, one goal with this work is to complement DORA’s delivery metrics with similar correlations between code quality and its business impact.
Hopefully, this work can help developers when communicating with the product/business side. The sad reality is that without quantifiable metrics, short term targets will win over the long-term maintainability of the codebase. Only a minority of companies actively manage technical debt.
This is indeed something that the academic research paper (see https://arxiv.org/abs/2203.04374) identifies as Future Work. There could be a code familiarity component that explains the large risks and variations.
From the paper:
"Could it be that changes done by the main author are faster and more predictable than corresponding changes made by a minor contributor? We suspect that author experience could be a factor that impacts the predictability of changes to low quality code."
If that turns out to be the case, then it would highlight organizational dimensions of low quality code: key personnel dependencies and on-boarding challenges.
Yes, cyclomatic complexity might be a popular metric but it was never a good one. At least not for its original purpose.
That said, I occasionally find cyclomatic complexity useful: cyclomatic complexity is a pretty good estimate on the number of unit tests a piece of code needs.
I started to code 35 years ago on a Commodore 64. The beauty of those machines was that you literally had to write code to even load a game (LOAD, RUN, etc.).
As such, the barriers to start exploring programming on your own were low: the development environment was already there, you were familiar with the interface, and it booted in an instant. I haven't seen any modern day technology replicate that ease of access for beginning coders.
I always consider myself extremely lucky to have started learning tech when I did, because the devices were so simple then. I could code in Assembler on my BBC micro with no problem, because there were only 3 registers and everything was simple.
But the beauty of that was that there was nothing more complex. There are simple devices and environments around today, but they pale in comparison to the more complex environments. You can totally code a game up in a BBC emulator, for example, but it looks shit in comparison to the Unity tutorial game.
I was forced to learn Assembler because it was the only way of writing a video game on the BBC micro. And there was nothing better out there. If I was 14 again and trying to create video games to sate my urge now, I'd be learning Unity. Even though there are simpler environments available.
reply