In Software delivery there’s a famous saying: Good, Fast, or Cheap — pick 2.
There’s always trade-offs.
Fast and cheap can be measured easily. How much money and how much time are very simple questions to answer. You might think it’s expensive, or slow — but the objective hours and dollars are easy measurements.
It’s not the same for ‘Good’ though. How do you measure ‘Good’?
Martin Fowler breaks it down into two categories, external quality and internal quality.
External Quality is what we see on the outside. How intuitive the UI is, how performant it is, meeting all the user requirements. These things treat the code as a black-box. A messy pile of spaghetti code, can still have a beautiful UI and be amazingly performant.
But there’s also an internal quality of software, that breaks down into two questions. How simple is the code to read, and how easy will it be to modify the code beyond what was originally intended. Software projects, unlike buildings or bridges, must evolve constantly over time. The moment the evolution stops, bad things happen.
It’s not just about the software responding to new business requirements, it’s also the software responding to the ever changing world software supply chain. That thing you wrote in pre-historic Java now needs to be upgraded, and the libraries you used aren’t compatible anymore. You cleverly used an external package for encryption — but the latest version of the package has breaking changes in the API … and so on.
Unfortunately, Internal quality is a famously hard thing to measure. It usually only manifest itself after the first few years. Even terrible code bases can tolerate changes in the initial stages of development. But only software was that intentionally designed with a high internal quality will stand the test of time.
Here’s the plot-twist. Unless you have a way to measure internal quality — measuring speed and cost alone isn’t a good indicator of anything. You have to taste the steak to determine if it was worth the wait (or not!).
Which brings us finally to coding assistants.
Coding assistants can help you move faster, and for greenfield projects they’re a god-send. But there’s little value in moving fast, if it produces low quality code. Unless you understand the trade-off, measuring just speed or cost is not a good indicator of the final deliverable.
My gut-feel is that it takes good developers to make good quality code. Coding assistants can help them do that, but only if they maintain the same high-bar for the output of their assistants as they do for themselves. More importantly, a junior developer won’t be able to make this distinction. You cannot replace a senior dev with a junior dev + AI. Quality is an acquired taste, and by definition it takes experience to acquire it.
But can you replace a Junior Dev + Senior Dev with just a Senior Dev + AI?
That’s a harder question to answer. I still think the current generation of coding assistants aren’t anywhere close to replacing a full human being with a reasonable amount of coding experience (3-5 years). Who knows where this will take us though, but at least at it stands this isn’t happening now.