Code quality only matters in context (2019) • Hacker News Board

Re: Code quality only matters in context (2019)

#21

Post by xupybd » Sat, May 28, 2022, 8:40 PM UTC

laserlight wrote: post #11

> Or maybe I decide to squeeze in an extra if-statement in already tricky code. And that's how the long tail becomes long tail. Nobody touches that part of the repo, because you have made it untouchable. People find working around easier than understanding and modifying existing code. Mess becomes messier. Writing clean code is not about introducing big abstractions, large refactors. It's about leaving the place bett…

Sometimes you have a root cause deep in the architecture. As long as that cause exists you will have to work around it. Each work around will have to be removed if you ever fix the root cause.

I saw this as a developer and had thought it was better to just leave the architecture alone and keep the work arounds as tidy as possible. Then I started working in manufacturing, a production line has many similarities to a running program, and saw the true cost. We fixed a root cause at the beginning of the line and all the work we put into working around the original problem was more of a mess to clean up than fixing the root cause.

I'm now a believer in trying to fix the source if possible.

That said a legacy code base with no tests is less likely to get a structural change from me.

Re: Code quality only matters in context (2019)

#22

Post by xupybd » Sat, May 28, 2022, 8:42 PM UTC

karatinversion wrote: post #17

ramesh31 wrote: post #14

Earlier quoted context omitted.

>Writing clean code is not about introducing big abstractions, large refactors. It's about leaving the place better than you found it. Writing clean code and leaving the place better than you found it requires time. Time we generally just do not have. There comes a point where things just have to work , and all of your ideas about what is "right" and "clean" have to be set aside to make that happen.

This seems a very short sighted attitude to me, like saying that there is no time for testing, there are too many bugs to fix.

If the business fails because it couldn't get to market in time who cares if the code quality was good?

Context is critical to knowing when to invest in quality.

Re: Code quality only matters in context (2019)

#23

Post by ramesh31 » Sat, May 28, 2022, 8:44 PM UTC

karatinversion wrote: post #17

ramesh31 wrote: post #14

Earlier quoted context omitted.

>Writing clean code is not about introducing big abstractions, large refactors. It's about leaving the place better than you found it. Writing clean code and leaving the place better than you found it requires time. Time we generally just do not have. There comes a point where things just have to work , and all of your ideas about what is "right" and "clean" have to be set aside to make that happen.

This seems a very short sighted attitude to me, like saying that there is no time for testing, there are too many bugs to fix.

>This seems a very short sighted attitude to me, like saying that there is no time for testing, there are too many bugs to fix.

It is. The priority for a programmer goes: make it work -> make it fast -> make it clean. And you either have time for all three of those, or you don't. Generally in reality though, when dealing with business needs and product managers, the pipeline becomes: make it work -> alright now make this work -> alright now also make this work.

Re: Code quality only matters in context (2019)

#24

Post by liotier » Sat, May 28, 2022, 9:02 PM UTC

xupybd wrote: post #22

karatinversion wrote: post #17

Earlier quoted context omitted.

This seems a very short sighted attitude to me, like saying that there is no time for testing, there are too many bugs to fix.

If the business fails because it couldn't get to market in time who cares if the code quality was good? Context is critical to knowing when to invest in quality.

At an ISP, when I was much younger, at the coffee machine I asked the Technical Director why we didn't invest in some technical cleanup. He replied that any available finances are much more profitably spent in advertising, which was directly correlated to sales, which were critical to survival. I guess that's why there are two sorts of companies: those that survived, and those with great code quality !

Re: Code quality only matters in context (2019)

#25

Post by IshKebab » Sat, May 28, 2022, 9:04 PM UTC

ramesh31 wrote: post #14

laserlight wrote: post #11

> Or maybe I decide to squeeze in an extra if-statement in already tricky code. And that's how the long tail becomes long tail. Nobody touches that part of the repo, because you have made it untouchable. People find working around easier than understanding and modifying existing code. Mess becomes messier. Writing clean code is not about introducing big abstractions, large refactors. It's about leaving the place bett…

>Writing clean code is not about introducing big abstractions, large refactors. It's about leaving the place better than you found it. Writing clean code and leaving the place better than you found it requires time. Time we generally just do not have. There comes a point where things just have to work , and all of your ideas about what is "right" and "clean" have to be set aside to make that happen.

Nonsense. You have to spend that time, either once now or 9 times later. You just need to be more firm about using it.

Re: Code quality only matters in context (2019)

#26

Post by otagekki » Sat, May 28, 2022, 9:05 PM UTC

defen wrote: post #19

gabereiser wrote: post #10

I was let go once for having too many commits in a PR. When we squash merged… I’ve come to the same conclusion about code quality. If it’s something that others interact with, make it polished. If it’s something only you interact with, make it commented.

> I was let go once for having too many commits in a PR. You were fired for having too many commits in a PR? That seems like an extreme overreaction unless there's more to the story.

There definitely has to be, on the other end of the commit count spectrum I've seen people being reprimanded for having too few commits. Looks like they had bad management anyway, he might have dodged a bullet there

Re: Code quality only matters in context (2019)

#27

Post by twp » Sat, May 28, 2022, 9:10 PM UTC

The author confused cause and effect.

Author: because this code sees a lot of churn it is important. Reality: this code sees a lot of churn because it is bad.

Re: Code quality only matters in context (2019)

#28

Post by epgui » Sat, May 28, 2022, 9:17 PM UTC

ramesh31 wrote: post #23

karatinversion wrote: post #17

Earlier quoted context omitted.

This seems a very short sighted attitude to me, like saying that there is no time for testing, there are too many bugs to fix.

>This seems a very short sighted attitude to me, like saying that there is no time for testing, there are too many bugs to fix. It is. The priority for a programmer goes: make it work -> make it fast -> make it clean. And you either have time for all three of those, or you don't. Generally in reality though, when dealing with business needs and product managers, the pipeline becomes: make it work -> alright now make…

I would argue that for most code, making it clean should be a priority over making it fast (optimizing for simplicity and readability over algorithmic performance).

It obviously depends on the application.

Re: Code quality only matters in context (2019)

#29

Post by mobjack » Sat, May 28, 2022, 9:25 PM UTC

laserlight wrote: post #11

> Or maybe I decide to squeeze in an extra if-statement in already tricky code. And that's how the long tail becomes long tail. Nobody touches that part of the repo, because you have made it untouchable. People find working around easier than understanding and modifying existing code. Mess becomes messier. Writing clean code is not about introducing big abstractions, large refactors. It's about leaving the place bett…

There comes a point where impossible to leave code in a better state without a major refactor.

The choice is between writing a few ugly if statements making the code a little worse or spending 10x the time refactoring hoping you don't introduce any regressions.

Re: Code quality only matters in context (2019)

#30

Post by robert_tweed » Sat, May 28, 2022, 9:42 PM UTC

I think the conclusion here is back-to-front.

Code that never needs to be touched is fine. Although the odds are that such code is either completely trivial or subtly wrong (or both).

Code that is touched every day is likely to be fine as well. It's should get smoothed out naturally, like a pebble in a stream. If not, you probably already have lots of alarm bells telling you it's a problem without the need for any further analysis. It's not the code quality that matters here so much as the test coverage.

The changes you really need to worry about are to code nobody has touched for 3 years and whoever wrote it no longer works for the company. Especially if that code was written with the mindset of "nobody will ever care about this code".

A better metric for deciding where you should focus the most effort on code quality is not frequency of modification, it is frequency of appearance in the runtime call-graph. Each call probably also need a multiplier for how deep in the call-stack it was, since that's where unintended consequences of a small change are likely to have the biggest blast radius.