19 ms·

All developers know code quality is important for long-term productivity and efficiency. But from a management perspective the problems are: - There is no way

by goto11 5y ago

All developers know code quality is important for long-term productivity and efficiency. But from a management perspective the problems are: - There is no way to measure code quality - There is no way to measure developer productivity - Code quality is quite subjective and the field is driven by opinions and fads. I have seen many examples where developers thought they were improving code quality by implementing some pattern or architecture but actually made it worse. So for non-technical leadership, it is hard to know if "extra time" spent on code quality actually improves anything or is a waste of time and money.

nradov 5y ago
There are static analysis tools like SonarQube which can measure code quality to an extent by looking for patterns that typically represent defects, or at least maintainability problems. But they usually can't detect deeper design flaws.
- goto11 5y ago
  Such tools don't measure any objective code quality, they just measure to what extend the code conforms to some criteria defined by the people configuring the tools. Do these criteria correspond to proven long term maintainability benefits, or are they just unfounded opinions?
  - nradov 5y ago
    The tools will catch issues like excessively long methods or use of "magic numbers" instead of named constants. Most programmers would agree that those are maintainability issues, although I don't know if it's ever been proven. You can disable any rules you don't want.
    - goto11 5y ago
      Yeah but such rules are still just unfounded opinions which have been codified and human judgement have been removed. What is an "excessively long" method, for example? If a method conforms to good design principles like separation of concerns and low coupling high cohesion, no particular length is too long. If a tool force you to split a cohesive method into multiple methods, then you have increased accidental complexity. So the tool will tell you you have improved some arbitrary "code quality" metric, but actually you have decreased maintainability.
WalterBright 5y ago
> developers thought they were improving code quality by implementing some pattern or architecture but actually made it worse. https://www.pri.org/stories/2012-08-25/amateur-restoration-botches-jesus-painting-spain https://www.pri.org/stories/2012-08-25/amateur-restoration-b...
pjmlp 5y ago
Consulting and offshoring is specifically hard. From management and customer point of view, "it works" is the only quality measure. No one cares about opening the box and the less one knows about how the sausage is made the better.
ToJans 5y ago
IME code quality only matters in the parts that require a lot of change. If you keep your mess contained and easy to replace, the inside doesn't matter in 90% of the cases. You do need to care about code quality in areas where code changes a lot, but you most likely do not know what these areas are upfront. I consider focus on code quality everywhere a form of premature optimization. Only focus on quality where it hurts... But if it hurts (f.e. you had to change it 3 times and it got messier each time), be very disciplined about refactoring to a better model: whiteboard, brainstorm etc and don't start refactoring until you found a better model.
- afarrell 5y ago
  Code quality also matters in the parts that a new joiner needs to read to make sense of the application and do their job.
- soco 5y ago
  If you have a problem somewhere in a mess, it will definitely hurt. What will you do then? Nevertheless, if the programmer know what they're doing I trust that the mess won't be extreme messy in the first place so maybe our argument is purely academic.
  - ToJans 5y ago
    I have parts of code that are extremely messy, but I don't spend time on refactoring, because once it works it doesn't need any changes... The moment it starts requiring frequent updates I'll take the time to sit down and do a proper revision or rewrite. I do tend to be very careful with my API interface FWIW...
- Verdex 5y ago
  I have a similar philosophy. If you can solve it once and the seal it away in a box and never look at it again ... then who cares. Write some tests or better yet hit it with a property test and then move on with your life. I'm more worried about low quality code that takes the form of an api or object that everyone in the entire codebase has to use. Something where if it has a bug or if it needs to change, it will impact huge swaths of code. Meanwhile, the code that takes a double and returns a double ... yeah it can be full of spiders and work by literal earth magic and as long as the unit tests are stable, I'm not losing any sleep. If you have to change it just rewrite it from scratch and reseal away the evil.
otabdeveloper4 5y ago
> So for non-technical leadership, it is hard to know if "extra time" spent on code quality actually improves anything or is a waste of time and money. No, it's much harder for technical leadership. Technical leadership operates on opinions, fads, cargo-cult, etc., like you said. Non-technical leadership can always fall back on business fundamentals.
- Aeolun 5y ago
  > Non-technical leadership can always fall back on business fundamentals. You mean like opinions, fads, cargo-cult, etc? Non technical leadership is just as susceptible to this. They’re just influenced by different people.
- TeMPOraL 5y ago
  > Non-technical leadership can always fall back on business fundamentals. For little good it'll do them. Any input to their calculations that references the software part of their business will still come with a big "shmaybe?" attached to it, making the results just as bad.
cheradenine_uk 5y ago
SO MUCH THIS. It's ironic to me that the "Hammer Factory Factory Factory" post was recently doing the rounds again. I have recently been working with a client whose "senior" dev swallowed some books with opinions on "quality" wholesale and uncritically. Thus in the simplest project, implementations that could literally be a lambda function (on receive message, write row into DB) are a festival of multiple tiers of objects, mappers, mediators, IoC frameworks, wrappers, Nuget packages, etc., etc. Everything is in multiple projects. Simple constants (like: API routes - '/api/foo/bar') are indirected into files containing those strings, so there's a huge cognitive overhead and much clicking around to make sense of it. God help you if you don't use an IDE. This isn't quality. It's the antithesis of quality. Devs have to understand a whole load of abstractions just to get simple things done. But the author is proud of his tower of 'best practice' - blissfully unaware that adding the simplest feature is now hundreds of lines of code, where one would suffice. This is burning through, literally, thousands of euros of dev time.
- jstimpfle 5y ago
  > thousands of euros of dev time probably you meant to say "hours"? :-)
  - simonbarker87 5y ago
    They probably didn’t, swap out euros for dollars or pounds or whatever you local currency of choice is
    - jstimpfle 5y ago
      "Thousands of euros" is peanuts. It's like a couple of days of work.
      - PeterisP 5y ago
        The market is a bit different than CA, "thousands of euros" can buy man-months of work (especially for junior devs), not a couple days.
OneTimePetes 5y ago
- 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.
adam_ellsworth 5y ago
> There is no way to measure code quality I have to disagree with you on this point (and your third point) I've seen so many examples where developers DID improve Code quality (CQ) from of the numerous automated/personal quality checks available. (Though what follows is from a Frontend dev perspective) - CI is CQ - Code Review is CQ - IDE w/ Linters is a form of CQ - `tsserver` is an real-time type CQ - Immutability is a passive CQ Idk, maybe Frontend-space is a world away from what you're working with every day, but CQ in my domain has both technological and cultural tools available before code ever reaches the end-user. > So for non-technical leadership, it is hard to know if "extra time" spent on code quality actually improves anything or is a waste of time and money. This is really interesting to me as a problem statement: how can devs unfold/make known the value of CQ as a critical function in this math? (I don't have an answer, but I think about it a lot). What are we not sharing – or, worse, what methods/language/etc. are we using that don't fully translate between teams? I feel it's the job of the org to be able to identify this kind of bottleneck. What position within an org is responsible for explicating the properties of this kind of issue? (Again, I don't know)
- goto11 5y ago
  But how do you know these things actually improves code maintainability long-term? How do you quantify the effect? Code reviews and linting is just applying some opinions to code. How do you show empirically these opinion are valid?
  - adam_ellsworth 5y ago
    Ah! Very good questions. Thank you for asking. > But how do you know these things actually improves code maintainability? How do you quantify it's effect? Trends. Trends in Client retention, trends in fewer user-submitted bugs. Trends in error rates garnered from logs. Trends in employee retention. Simply stated, Statistics. Imagine: you code a Minimum viable product (MVP) and get to market! Then you're inundated with user-submitted and computer monitor-submitted issues (i.e. AWS alarms) – you have a "shit show" of a product. So, how do you improve this MVP to reduce the Trends of failures? The solution is expressed in the ways I outlined above (but with vigor): CI, Tests, utilizing language linters such as TypeScript's tsserv, etc. (and so much more). > Code reviews and linting is just applying some opinions to code. How do you prove these opinion are valid? It's not an "opinions on code", it's a culture which is predetermined by the org (assuming the culture is healthy enough to understand its necessity and/or recognize its deficiency of the same). EVERY org needs to "scale". Orgs asked themselves: how do we effectively "scale" and what is "scale" org-wise? The tenets vary, but the history has painted a portrait of domains: SRE, DevOps, Data Analysts, Frontend, Backend, Product, Systems, Networking, SDET, etc. Each is not encumbered by the need for tests/CI/pre-deploy shtuff (arguable), but is released from "toil" because they recognized scale went beyond "opinions on code." Validity of code is tests and there are many, many, expressions of tests: End-to-end, Integration, Regression, Smoke tests, Unit, etc. > How do you prove empirically that immutability is not just a fad like so many others? I look back on the time before I was cognizant of the concept of Immutability and every larger FE app I wrote feels now indistinguishable from disorder and turmoil. I hope the YC community can expand on the necessity of immutability from a maths perspective (as I cannot), but it's eminently scalable (read: understandable and practicable from an FE dev perspective). (It's late and I gotta cut off here, hopefully someone can expand and/or redact everything I've said). Cheers
makeitdouble 5y ago
> - There is no way to measure code quality Code quality is your new feature rollout average time. If it's a steep rising curve it is abysmal, if it's mostly flat you have an excellent team. If it was flat but exponentially grew after you went on a hire spree, you know where to look at.
- d0mine 5y ago
  > If it was flat but exponentially grew after you went on a hire spree, you know where to look at. Initially, one could churn out a lots of features quickly accumulating the technical debt. The increasing time can be rather more about the past, then new people you hired.
- goto11 5y ago
  This assumes all features have equal complexity.
  - makeitdouble 5y ago
    This assumes a lot of other factors, but I'd say they all converge. You won't have high code quality without a motivated and competent team for instance. Same if they can't correctly scope their features or engage in long unplannable projects, etc. I'd make a parallel with clean natural water: you can't have it in isolation, the rest of your environment needs to be functional to preserve it.
- egman_ekki 5y ago
  > If it was flat but exponentially grew after you went on a hire spree, you know where to look at. It takes time for new hires to get familiar with the code and for seniors to help them get up to speed, so I'd be surprised if a hiring spree didn't end up sharply rising curve for feature rollout time.
marginalia_nu 5y ago
Why do we need to measure code quality?
- goto11 5y ago
  Because a business need to allocate resources rationally if it wants to survive.
  - marginalia_nu 5y ago
    This seems in conflict with the fact that we, as humans, are subjects -- with no direct access to any sort of objective reality. The measurements these businesses are looking at are (by definition) disjointed from reality as experienced by their customers and employees.
    - ducharmdev 5y ago
      Given any entity that yearns for its own survival (a person, a business, an organism etc): does it matter whether it's means of observing the world are imperfect if said means are good enough to ensure it's continued survival?
      - marginalia_nu 5y ago
        Is good enough all we're striving for? Is treading water the pinnacle of human accomplishment?
        ducharmdev 5y ago
        For a lot of businesses, yes - that's exactly what they're striving for. I think what's confusing to me about this and your previous point, is you mentioned this inability to access objective reality outside our own subjective experience, but now appeal to a shared human experience (i.e., there's a general human accomplishment we should all be working towards that goes beyond our subjective experience). I can understand one or the other, but it seems there's some tension between those 2 views.
feanaro 5y ago
Sounds to me like the problem lies in the existence of non-technical "management".
- goto11 5y ago
  Unfortunately technical management have the same problem.
marsven_422 5y ago
You are being to nice. Management DO NOT UNDERSTAND code quality. Management DO NOT UNDERSTAND how to measure developer productivity. In my 16years of doing "this" no manger has ever had the background nessesary to understand software. And "technical managers" seem to bee made up entirety of mechanical engineers that can not comprehend anything but waterfall.
ozim 5y ago
Add to that it is a lot easier to write new code than understand existing code base. People nag about previous code base not because it is bad but that they don't want to spend time learning it. More often than not I see "code quality" as an excuse for being lazy or generic blanket argument that you cannot refute because "code quality".
kodah 5y ago
Personally, I think "measuring code quality" means looking for things you absolutely shouldn't or probably shouldn't be doing.
stinos 5y ago
There is no way to measure code quality While it's indeed hard to get objective measurements looking at the codebase alone, telling a manager things like "look, this is going to take 5x the amount of time it should because the current code is a complete mess so I have to be extra careful not to break things and it takes way longer than it should to figure out where I have to put the new feature in order to mimimize the amount of extra chaos created" or "I cannot do anything sensibly without refactoring this first but it will pay off in the next couple of months and years to follow" should make it pretty clear the quality isn't where it should be. If management doesn't grasp that, or doesn't want to hear it, then management quality is probably at the same level as the code's. I know I'm in a position not every developer is, but when needed I ask and get extra time for things like this. Because I've seen what happens when you try to build a trainwreck on top of existing ones: that stuff is exponential, at least.
- goto11 5y ago
  Sure you can say such things. My point is just there is no way to determine if you are right. Unless you make an A/B test where you both refactor and keep the old version around, and measure how much time it takes for the same developers to implement same change on both code bases. But nobody ever does such a test since it would be prohibitively expensive.
  - deleted 5y ago
    [deleted]
  - ken47 5y ago
    The example assertions he was making were non falsifiable. However, if the claims were slightly tweaked to say something along the lines of: "historically, a code modification like the one you've requested has taken 5n units of time. After refactoring, such a change will take n units of time." You wouldn't perform an A/B test to prove your claim. The managers would simply have to trust you for the reputable engineer that you are, and hopefully observe substantially increased velocity after the refactoring.
    - 5y ago
sdevonoes 5y ago
> I have seen many examples where developers thought they were improving code quality by implementing some pattern or architecture but actually made it worse. > - Code quality is quite subjective and the field is driven by opinions and fads. Agree. In almost every team I have been part of, when discussing code quality there was almost never consensus regarding what's good and bad. Besides, in almost every company I have worked for, modules (or products) were usually refactored after 3 years or so (as in: the code that deals with retrieving data from the DB remains almost intact, but everything else is moved out to its own repository: the frontend as microfrontend and a new in-between layer (call it a proxy or "backend for frontend"))... so there was never a huge motivation to write quality code, just to write "good enough" code.
- deleted 5y ago
  [deleted]
- goostavos 5y ago
  >when discussing code quality there was almost never consensus regarding what's good and bad. FWIW, I've found that the best way to approach dragging a team in a new direction is to not focus on what "quality" is at all, but see if everyone can agree on what the problems are. I think if you can get people aligned on the problems -- specifically high level 'above the code' ones like "X keeps breaking" or "X is really hard to change" -- you can sneak quality into the discussion without it being an attack on any individual developer's code. "why is X hard to change" can become a conversation about loose coupling, cohesion, state, etc..
jandrewrogers 5y ago
I would make the distinction that architectural quality has a larger and more concrete impact on long-term efficiency and productivity for developers than code quality. You can incrementally fix code quality when there is value in doing so or time but architecture tends to live forever. I've seen code bases with excellent and diligent code quality but poor architecture, which rendered many nominal productivity gains from the very high code quality moot. From a business perspective, investing in architecture quality buys a lot more optionality than investing in code quality, and so prioritizing the former is almost always the right decision.
ken47 5y ago
I disagree with the idea that there is no way to measure code quality. As long as one is willing to sacrifice a lot of precision, it is certainly measurable. Just come up with adequately broad, discrete buckets.
eikenberry 5y ago
> - Code quality is quite subjective and the field is driven by opinions and fads. I think a big part of this is the tech industries failure to grasp the value of experience. Experience teaches you to pick out the fads from the fashions and the values of various opinions. It helps develop your code smell and your ability to discern the quality of a work. All other trades value experience and trust it to help measure these things. If you wanted to judge the quality of work done by a junior plumber you'd bring in a master plumber to evaluate it.
a_c 5y ago
Agreed. I think this is why a tech-enabled startups need a technical co-founder/leadership. Someone need to be the final arbiter/advocate for code quality. There are many things cannot be measured directly or conveniently, e.g. aesthetics (visual quality), culture, interview quality, bureaucracy, etc. All of them indirectly impact bottom line and top line. Big org need measurements for all teams, that's the only way to scale. And that's why in my opinion small business will always find a way to survive, or even thrive, by providing better quality. The quality setup in small team will become the baseline for you to up the game into big org. But once you want to scale, all those none measurable stuff become irrelevant. All boil down to, does it bring in revenue/profit

by goto11 5y ago

nradov 5y ago

There are static analysis tools like SonarQube which can measure code quality to an extent by looking for patterns that typically represent defects, or at least maintainability problems. But they usually can't detect deeper design flaws.

goto11 5y ago
Such tools don't measure any objective code quality, they just measure to what extend the code conforms to some criteria defined by the people configuring the tools. Do these criteria correspond to proven long term maintainability benefits, or are they just unfounded opinions?
- nradov 5y ago
  The tools will catch issues like excessively long methods or use of "magic numbers" instead of named constants. Most programmers would agree that those are maintainability issues, although I don't know if it's ever been proven. You can disable any rules you don't want.
  - goto11 5y ago
    Yeah but such rules are still just unfounded opinions which have been codified and human judgement have been removed. What is an "excessively long" method, for example? If a method conforms to good design principles like separation of concerns and low coupling high cohesion, no particular length is too long. If a tool force you to split a cohesive method into multiple methods, then you have increased accidental complexity. So the tool will tell you you have improved some arbitrary "code quality" metric, but actually you have decreased maintainability.

WalterBright 5y ago

> developers thought they were improving code quality by implementing some pattern or architecture but actually made it worse. https://www.pri.org/stories/2012-08-25/amateur-restoration-botches-jesus-painting-spain https://www.pri.org/stories/2012-08-25/amateur-restoration-b...

pjmlp 5y ago

Consulting and offshoring is specifically hard. From management and customer point of view, "it works" is the only quality measure. No one cares about opening the box and the less one knows about how the sausage is made the better.

ToJans 5y ago

IME code quality only matters in the parts that require a lot of change. If you keep your mess contained and easy to replace, the inside doesn't matter in 90% of the cases. You do need to care about code quality in areas where code changes a lot, but you most likely do not know what these areas are upfront. I consider focus on code quality everywhere a form of premature optimization. Only focus on quality where it hurts... But if it hurts (f.e. you had to change it 3 times and it got messier each time), be very disciplined about refactoring to a better model: whiteboard, brainstorm etc and don't start refactoring until you found a better model.

afarrell 5y ago
Code quality also matters in the parts that a new joiner needs to read to make sense of the application and do their job.
soco 5y ago
If you have a problem somewhere in a mess, it will definitely hurt. What will you do then? Nevertheless, if the programmer know what they're doing I trust that the mess won't be extreme messy in the first place so maybe our argument is purely academic.
- ToJans 5y ago
  I have parts of code that are extremely messy, but I don't spend time on refactoring, because once it works it doesn't need any changes... The moment it starts requiring frequent updates I'll take the time to sit down and do a proper revision or rewrite. I do tend to be very careful with my API interface FWIW...
Verdex 5y ago
I have a similar philosophy. If you can solve it once and the seal it away in a box and never look at it again ... then who cares. Write some tests or better yet hit it with a property test and then move on with your life. I'm more worried about low quality code that takes the form of an api or object that everyone in the entire codebase has to use. Something where if it has a bug or if it needs to change, it will impact huge swaths of code. Meanwhile, the code that takes a double and returns a double ... yeah it can be full of spiders and work by literal earth magic and as long as the unit tests are stable, I'm not losing any sleep. If you have to change it just rewrite it from scratch and reseal away the evil.

otabdeveloper4 5y ago

> So for non-technical leadership, it is hard to know if "extra time" spent on code quality actually improves anything or is a waste of time and money. No, it's much harder for technical leadership. Technical leadership operates on opinions, fads, cargo-cult, etc., like you said. Non-technical leadership can always fall back on business fundamentals.

Aeolun 5y ago
> Non-technical leadership can always fall back on business fundamentals. You mean like opinions, fads, cargo-cult, etc? Non technical leadership is just as susceptible to this. They’re just influenced by different people.
TeMPOraL 5y ago
> Non-technical leadership can always fall back on business fundamentals. For little good it'll do them. Any input to their calculations that references the software part of their business will still come with a big "shmaybe?" attached to it, making the results just as bad.

cheradenine_uk 5y ago

SO MUCH THIS. It's ironic to me that the "Hammer Factory Factory Factory" post was recently doing the rounds again. I have recently been working with a client whose "senior" dev swallowed some books with opinions on "quality" wholesale and uncritically. Thus in the simplest project, implementations that could literally be a lambda function (on receive message, write row into DB) are a festival of multiple tiers of objects, mappers, mediators, IoC frameworks, wrappers, Nuget packages, etc., etc. Everything is in multiple projects. Simple constants (like: API routes - '/api/foo/bar') are indirected into files containing those strings, so there's a huge cognitive overhead and much clicking around to make sense of it. God help you if you don't use an IDE. This isn't quality. It's the antithesis of quality. Devs have to understand a whole load of abstractions just to get simple things done. But the author is proud of his tower of 'best practice' - blissfully unaware that adding the simplest feature is now hundreds of lines of code, where one would suffice. This is burning through, literally, thousands of euros of dev time.

jstimpfle 5y ago
> thousands of euros of dev time probably you meant to say "hours"? :-)
- simonbarker87 5y ago
  They probably didn’t, swap out euros for dollars or pounds or whatever you local currency of choice is
  - jstimpfle 5y ago
    "Thousands of euros" is peanuts. It's like a couple of days of work.
    - PeterisP 5y ago
      The market is a bit different than CA, "thousands of euros" can buy man-months of work (especially for junior devs), not a couple days.

OneTimePetes 5y ago

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

adam_ellsworth 5y ago

> There is no way to measure code quality I have to disagree with you on this point (and your third point) I've seen so many examples where developers DID improve Code quality (CQ) from of the numerous automated/personal quality checks available. (Though what follows is from a Frontend dev perspective) - CI is CQ - Code Review is CQ - IDE w/ Linters is a form of CQ - `tsserver` is an real-time type CQ - Immutability is a passive CQ Idk, maybe Frontend-space is a world away from what you're working with every day, but CQ in my domain has both technological and cultural tools available before code ever reaches the end-user. > So for non-technical leadership, it is hard to know if "extra time" spent on code quality actually improves anything or is a waste of time and money. This is really interesting to me as a problem statement: how can devs unfold/make known the value of CQ as a critical function in this math? (I don't have an answer, but I think about it a lot). What are we not sharing – or, worse, what methods/language/etc. are we using that don't fully translate between teams? I feel it's the job of the org to be able to identify this kind of bottleneck. What position within an org is responsible for explicating the properties of this kind of issue? (Again, I don't know)

goto11 5y ago
But how do you know these things actually improves code maintainability long-term? How do you quantify the effect? Code reviews and linting is just applying some opinions to code. How do you show empirically these opinion are valid?
- adam_ellsworth 5y ago
  Ah! Very good questions. Thank you for asking. > But how do you know these things actually improves code maintainability? How do you quantify it's effect? Trends. Trends in Client retention, trends in fewer user-submitted bugs. Trends in error rates garnered from logs. Trends in employee retention. Simply stated, Statistics. Imagine: you code a Minimum viable product (MVP) and get to market! Then you're inundated with user-submitted and computer monitor-submitted issues (i.e. AWS alarms) – you have a "shit show" of a product. So, how do you improve this MVP to reduce the Trends of failures? The solution is expressed in the ways I outlined above (but with vigor): CI, Tests, utilizing language linters such as TypeScript's tsserv, etc. (and so much more). > Code reviews and linting is just applying some opinions to code. How do you prove these opinion are valid? It's not an "opinions on code", it's a culture which is predetermined by the org (assuming the culture is healthy enough to understand its necessity and/or recognize its deficiency of the same). EVERY org needs to "scale". Orgs asked themselves: how do we effectively "scale" and what is "scale" org-wise? The tenets vary, but the history has painted a portrait of domains: SRE, DevOps, Data Analysts, Frontend, Backend, Product, Systems, Networking, SDET, etc. Each is not encumbered by the need for tests/CI/pre-deploy shtuff (arguable), but is released from "toil" because they recognized scale went beyond "opinions on code." Validity of code is tests and there are many, many, expressions of tests: End-to-end, Integration, Regression, Smoke tests, Unit, etc. > How do you prove empirically that immutability is not just a fad like so many others? I look back on the time before I was cognizant of the concept of Immutability and every larger FE app I wrote feels now indistinguishable from disorder and turmoil. I hope the YC community can expand on the necessity of immutability from a maths perspective (as I cannot), but it's eminently scalable (read: understandable and practicable from an FE dev perspective). (It's late and I gotta cut off here, hopefully someone can expand and/or redact everything I've said). Cheers

makeitdouble 5y ago

> - There is no way to measure code quality Code quality is your new feature rollout average time. If it's a steep rising curve it is abysmal, if it's mostly flat you have an excellent team. If it was flat but exponentially grew after you went on a hire spree, you know where to look at.

d0mine 5y ago
> If it was flat but exponentially grew after you went on a hire spree, you know where to look at. Initially, one could churn out a lots of features quickly accumulating the technical debt. The increasing time can be rather more about the past, then new people you hired.
goto11 5y ago
This assumes all features have equal complexity.
- makeitdouble 5y ago
  This assumes a lot of other factors, but I'd say they all converge. You won't have high code quality without a motivated and competent team for instance. Same if they can't correctly scope their features or engage in long unplannable projects, etc. I'd make a parallel with clean natural water: you can't have it in isolation, the rest of your environment needs to be functional to preserve it.
egman_ekki 5y ago
> If it was flat but exponentially grew after you went on a hire spree, you know where to look at. It takes time for new hires to get familiar with the code and for seniors to help them get up to speed, so I'd be surprised if a hiring spree didn't end up sharply rising curve for feature rollout time.

marginalia_nu 5y ago

Why do we need to measure code quality?

goto11 5y ago
Because a business need to allocate resources rationally if it wants to survive.
- marginalia_nu 5y ago
  This seems in conflict with the fact that we, as humans, are subjects -- with no direct access to any sort of objective reality. The measurements these businesses are looking at are (by definition) disjointed from reality as experienced by their customers and employees.
  - ducharmdev 5y ago
    Given any entity that yearns for its own survival (a person, a business, an organism etc): does it matter whether it's means of observing the world are imperfect if said means are good enough to ensure it's continued survival?
    - marginalia_nu 5y ago
      Is good enough all we're striving for? Is treading water the pinnacle of human accomplishment?
      - ducharmdev 5y ago
        For a lot of businesses, yes - that's exactly what they're striving for. I think what's confusing to me about this and your previous point, is you mentioned this inability to access objective reality outside our own subjective experience, but now appeal to a shared human experience (i.e., there's a general human accomplishment we should all be working towards that goes beyond our subjective experience). I can understand one or the other, but it seems there's some tension between those 2 views.

feanaro 5y ago

Sounds to me like the problem lies in the existence of non-technical "management".

goto11 5y ago
Unfortunately technical management have the same problem.

marsven_422 5y ago

You are being to nice. Management DO NOT UNDERSTAND code quality. Management DO NOT UNDERSTAND how to measure developer productivity. In my 16years of doing "this" no manger has ever had the background nessesary to understand software. And "technical managers" seem to bee made up entirety of mechanical engineers that can not comprehend anything but waterfall.

ozim 5y ago

Add to that it is a lot easier to write new code than understand existing code base. People nag about previous code base not because it is bad but that they don't want to spend time learning it. More often than not I see "code quality" as an excuse for being lazy or generic blanket argument that you cannot refute because "code quality".

kodah 5y ago

Personally, I think "measuring code quality" means looking for things you absolutely shouldn't or probably shouldn't be doing.

stinos 5y ago

There is no way to measure code quality While it's indeed hard to get objective measurements looking at the codebase alone, telling a manager things like "look, this is going to take 5x the amount of time it should because the current code is a complete mess so I have to be extra careful not to break things and it takes way longer than it should to figure out where I have to put the new feature in order to mimimize the amount of extra chaos created" or "I cannot do anything sensibly without refactoring this first but it will pay off in the next couple of months and years to follow" should make it pretty clear the quality isn't where it should be. If management doesn't grasp that, or doesn't want to hear it, then management quality is probably at the same level as the code's. I know I'm in a position not every developer is, but when needed I ask and get extra time for things like this. Because I've seen what happens when you try to build a trainwreck on top of existing ones: that stuff is exponential, at least.

goto11 5y ago
Sure you can say such things. My point is just there is no way to determine if you are right. Unless you make an A/B test where you both refactor and keep the old version around, and measure how much time it takes for the same developers to implement same change on both code bases. But nobody ever does such a test since it would be prohibitively expensive.
- deleted 5y ago
  [deleted]
- ken47 5y ago
  The example assertions he was making were non falsifiable. However, if the claims were slightly tweaked to say something along the lines of: "historically, a code modification like the one you've requested has taken 5n units of time. After refactoring, such a change will take n units of time." You wouldn't perform an A/B test to prove your claim. The managers would simply have to trust you for the reputable engineer that you are, and hopefully observe substantially increased velocity after the refactoring.
  - 5y ago

sdevonoes 5y ago

> I have seen many examples where developers thought they were improving code quality by implementing some pattern or architecture but actually made it worse. > - Code quality is quite subjective and the field is driven by opinions and fads. Agree. In almost every team I have been part of, when discussing code quality there was almost never consensus regarding what's good and bad. Besides, in almost every company I have worked for, modules (or products) were usually refactored after 3 years or so (as in: the code that deals with retrieving data from the DB remains almost intact, but everything else is moved out to its own repository: the frontend as microfrontend and a new in-between layer (call it a proxy or "backend for frontend"))... so there was never a huge motivation to write quality code, just to write "good enough" code.

deleted 5y ago
[deleted]
goostavos 5y ago
>when discussing code quality there was almost never consensus regarding what's good and bad. FWIW, I've found that the best way to approach dragging a team in a new direction is to not focus on what "quality" is at all, but see if everyone can agree on what the problems are. I think if you can get people aligned on the problems -- specifically high level 'above the code' ones like "X keeps breaking" or "X is really hard to change" -- you can sneak quality into the discussion without it being an attack on any individual developer's code. "why is X hard to change" can become a conversation about loose coupling, cohesion, state, etc..

jandrewrogers 5y ago

I would make the distinction that architectural quality has a larger and more concrete impact on long-term efficiency and productivity for developers than code quality. You can incrementally fix code quality when there is value in doing so or time but architecture tends to live forever. I've seen code bases with excellent and diligent code quality but poor architecture, which rendered many nominal productivity gains from the very high code quality moot. From a business perspective, investing in architecture quality buys a lot more optionality than investing in code quality, and so prioritizing the former is almost always the right decision.

ken47 5y ago

I disagree with the idea that there is no way to measure code quality. As long as one is willing to sacrifice a lot of precision, it is certainly measurable. Just come up with adequately broad, discrete buckets.

eikenberry 5y ago

> - Code quality is quite subjective and the field is driven by opinions and fads. I think a big part of this is the tech industries failure to grasp the value of experience. Experience teaches you to pick out the fads from the fashions and the values of various opinions. It helps develop your code smell and your ability to discern the quality of a work. All other trades value experience and trust it to help measure these things. If you wanted to judge the quality of work done by a junior plumber you'd bring in a master plumber to evaluate it.

a_c 5y ago

Agreed. I think this is why a tech-enabled startups need a technical co-founder/leadership. Someone need to be the final arbiter/advocate for code quality. There are many things cannot be measured directly or conveniently, e.g. aesthetics (visual quality), culture, interview quality, bureaucracy, etc. All of them indirectly impact bottom line and top line. Big org need measurements for all teams, that's the only way to scale. And that's why in my opinion small business will always find a way to survive, or even thrive, by providing better quality. The quality setup in small team will become the baseline for you to up the game into big org. But once you want to scale, all those none measurable stuff become irrelevant. All boil down to, does it bring in revenue/profit