Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Code quality only matters in context (2019)

adamtornhill.com

Post reply on HN
Print view View original

51–60 of 78 posts

Re: Code quality only matters in context (2019)

#51

Post by makk »

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.

> Time we generally just do not have.

Am I the only one who thinks this old trope is a fallacy in most situations?

Re: Code quality only matters in context (2019)

#52

Post by MiddleMan5 »

Tade0 wrote: post #48

At some point I started referring to code as expensive/inexpensive instead of good/bad, the metric being "how much money did it cost to first implement and then maintain this feature?". It makes business people pay attention. I've found that it takes roughly the same time to write expensive and inexpensive code - additional expenses in the former case pile up later on in the form of time spent debugging and/or infras…

I like this, I've been looking for alternative language to express this to other developers on my team! I've noticed people tend to shut down when you say their code is "bad"

Re: Code quality only matters in context (2019)

#53

Post by Silhouette »

mobjack wrote: post #29
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.

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.

Those few ugly if statements might make the code only a little worse and take 1/10 of the time to do the job properly if the code was previously good. However the trouble with technical debt is the interest can compound rapidly. Your random set of if statements combined with three other developers' random sets of if statements from previous hacky changes (two of them in other parts of the code that the part you're modifying now implicitly and surprisingly depends on as a result) could be a story with a very different ending.

Re: Code quality only matters in context (2019)

#54

Post by Silhouette »

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.

It's distressing how often I see this argument. I've been a proponent of keeping code tidy and tech debt under control for my whole career and all I've ever seen from other developers who do the same is much faster sustained development and far fewer bugs that waste time later. It's the teams who have let tech debt spiral out of control and jump from one quick change to another that I see drifting towards constant firefighting and never having time to do things properly. The argument made in defence of their abysmal performance when that happens is always some vague claim about needing to ship for business reasons at some important moment in the past and yet never considers that there will probably be many more important moments in the future (at least if the business is going to survive and prosper). I'm still waiting to see a startup fail because its developers wrote good code in the early stages.

Re: Code quality only matters in context (2019)

#55

Post by Silhouette »

j7ake wrote: post #8

This mindset is also true for many researchers who code. Professional programmers make fun of research code but actually the dirty way is desirable considering that research is about prototyping, tweaking, and in small groups.

Professional programmers make fun of research code but actually the dirty way is desirable considering that research is about prototyping, tweaking, and in small groups.

Until say a once-in-a-lifetime global pandemic comes along and facing the prospect of literally millions of people dying governments turn to those researchers for advice. Then suddenly some program that is thousands of lines long in a single file and reads like an entry to the IOCCC that has evolved over many years with no real peer review or test strategy or anything resembling formal verification to implement the researcher's calculations becomes the foundation for major public policy decisions that can profoundly affect the way of life of entire societies for years. At least we all know that hacky code written by non-expert programmers without any tests, review or other verification never has bugs that could cause it to output incorrect results.

Code written by academics in "research" style is fine when the results are only of academic interest but it's insanely dangerous to apply the same low standards if the results are going to be used for something that actually matters.

Re: Code quality only matters in context (2019)

#56

Post by xupybd »

salawat wrote: post #42
xupybd wrote: post #22

Earlier quoted context omitted.

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.

There are two types of programmer. There is a programmer that reads, absorbs the system as a whole and deals with it as it is. Then there is the programmer who just wants shit written that can get them most of the way there and he'll fix the other shit to do as he wants eventually. The software industry is generally run by the latter. The former are those that see the most value in high quality code, because quality…

So you've introduced the context of large scale mission critical software. Not all software is large scale and not all software is mission critical.

Sometimes a crappy script that saves an administrator 2 hours a day can be a Huge win.

Sometimes lives are on the line and bugs are not acceptable. Other times the cost of a bug is some internal user has to deal with a little frustration.

All investments are about weighing the cost with the potential benefits. Developing software is an investment.

Re: Code quality only matters in context (2019)

#57

Post by mbrodersen »

Tade0 wrote: post #48

At some point I started referring to code as expensive/inexpensive instead of good/bad, the metric being "how much money did it cost to first implement and then maintain this feature?". It makes business people pay attention. I've found that it takes roughly the same time to write expensive and inexpensive code - additional expenses in the former case pile up later on in the form of time spent debugging and/or infras…

Agree. Do the same with meetings. How expensive is this meeting? If the meeting takes an hour then the cost of the meeting is the sum of the hour rate of the people participating. Then ask if the meeting will generate enough additional revenue to pay for itself?

Re: Code quality only matters in context (2019)

#58

Post by dhzhzjsbevs »

mbrodersen wrote: post #57
Tade0 wrote: post #48

At some point I started referring to code as expensive/inexpensive instead of good/bad, the metric being "how much money did it cost to first implement and then maintain this feature?". It makes business people pay attention. I've found that it takes roughly the same time to write expensive and inexpensive code - additional expenses in the former case pile up later on in the form of time spent debugging and/or infras…

Agree. Do the same with meetings. How expensive is this meeting? If the meeting takes an hour then the cost of the meeting is the sum of the hour rate of the people participating. Then ask if the meeting will generate enough additional revenue to pay for itself?

How do you quantify the revenue generated from coordination, alignment, transparency and any intrinsic motivation gained by including people in the decision making process?

I agree a lot of meetings are pointless and not everyone present needs wants or maybe even should be there but I'm struggling to understand the quantifying you're supposedly able to do.

Re: Code quality only matters in context (2019)

#59

Post by [deleted] »

Silhouette wrote: post #54
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.

It's distressing how often I see this argument. I've been a proponent of keeping code tidy and tech debt under control for my whole career and all I've ever seen from other developers who do the same is much faster sustained development and far fewer bugs that waste time later. It's the teams who have let tech debt spiral out of control and jump from one quick change to another that I see drifting towards constant fi…

[deleted]

Re: Code quality only matters in context (2019)

#60

Post by geocar »

bumby wrote: post #13
abnry wrote: post #9

I wonder if you can formalize this a bit more. Let W(init,DC) be the initial cost (hours/effort) of writing Dirty Code (DC). Let's assume that the code works for the intended purpose and doesn't have any bugs. Let W(init,CC) be the initial cost of writing Clean Code (CC). You'd expect it to be related to W(init,DC) by some proportion: W(init,CC) = (1+alpha)*W(init,DC). Then there is a probability p that you will want…

I would also include a probability of an bug being introduced while extending the code. Code quality tends to be harder to track as the number of system interfaces expands. Particularly when it coordinates efforts between physical systems, even "clean code" can cause coordination failures because the context has changed by the extension. The example my mind always goes to is the Ariane V failure; it was a failure of…

> I would also include a probability of an bug being introduced while extending the code.

The number of sprints you spend changing a bit of code might also be a metric worth tracking as well:

https://www.microsoft.com/en-us/research/wp-content/uploads/...

Post reply on HN