I tend to agree with this. I inherited a product which had one/two engineers supporting each client implementation. It used to take 2+months to add a new data source.

When we dug in and improved the architecture, we could support 3+ clients with one engineer and add any new data source to less than a week.

I don't attribute it only to code quality but a combination of better architecture, good development practices(proper linting, proper conventions etc) and good product road map.

Focusing only on code quality without context may not be useful. Saying that it doesn't take more than a few minutes to set the core tenets of the project even for a small one time project.

> Deadlines continuously are missed

This is a question of the quality of estimates and unrealistic deadlines. This is a separate problem from code quality. E.g. if you have really bad code but you know how bad it it, then this is factored into the time estimate.

Deadlines are missed even for equivalent tasks previously done tasks, executed by a developer who is qualified and capable. Means even reproduction of pre-existing work is hard with the code-base.

The problem is you never have "equivalent tasks". This is the blessing and curse of software development: You never have to do the same thing twice.

Software tend to get more complex over time. Even if code quality is optimal, software will get more requirements added over time - especially if it is successful. If you allocate resources rationally, you will start by solving the "low hanging fruit" in the problem domain. So you cant really compare tasks at different stages in development.

You obviously have never been blessed with a truly horrific codebase. There are C-projects out there, were people do almost the same thing - twice.

Like a endless papyrus scroll, and medieval scribes, modifying a copy and pasted atrocity for a month.Code this bad, usually never makes it to HN of course.

In any case, you can have the best code quality in the world and still miss deadlines if the deadlines are not realistic.

Well, you're arguing (and I agree) that poor code quality can be identified, but not necessarily that it can be measured. The symptoms you list are partly caused by poor code quality, but not entirely either.