4 ms·

- There is no way to measure code quality Actually there is: Tech debt materializes in all measurable metrics of the project. Project Deadlines continuously ar

- There is no way to measure code quality Actually there is: Tech debt materializes in all measurable metrics of the project. Project Deadlines continuously are missed and the time at which they overshoot increases. A project needs "exponential" people. The quit rate among the developers constantly increases, with experienced devs quitting first. All these signals should allow actually easily to create a metric for code-quality. Its a signal that bounces from the code through the system to you. We have ways of computating the original value after it has bounced through the develop teams system. https://en.wikipedia.org/wiki/Convolution https://en.wikipedia.org/wiki/Convolution The problem is rather- nobody wants to know how much debt they own, or to speak bluntly, whether the situation one is in, is actually a tech-debt bankruptcy.

ganti_r 5y ago
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.
goto11 5y ago
> 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.
- OneTimePetes 5y ago
  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.
  - goto11 5y ago
    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.
    - OneTimePetes 5y ago
      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.
      - goto11 5y ago
        In any case, you can have the best code quality in the world and still miss deadlines if the deadlines are not realistic.
commandlinefan 5y ago
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.

ganti_r 5y ago

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.

goto11 5y ago

> 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.

OneTimePetes 5y ago
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.
- goto11 5y ago
  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.
  - OneTimePetes 5y ago
    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.
    - goto11 5y ago
      In any case, you can have the best code quality in the world and still miss deadlines if the deadlines are not realistic.

commandlinefan 5y ago

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.