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

61–70 of 78 posts

Re: Code quality only matters in context (2019)

#61

Post by andrekandre »

makk wrote: post #51
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.

> Time we generally just do not have. Am I the only one who thinks this old trope is a fallacy in most situations?

maybe it depends on how you are being managed...

if your constantly ticketed and measured on an hourly basis, there really isn't "time" available outside of what was allocated to you

on the other hand, if your workload is a collaboration, then you have the opportunity to negotiate "time" to fix issues that are slowing you down (compile times, test iteration, debugging, tooling) which will buy your more time (for features/improvements) later

Re: Code quality only matters in context (2019)

#62

Post by geocar »

robert_tweed wrote: post #30

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 fu…

> A better metric for deciding where you should focus the most effort on code quality is not frequency of modification

Frequency of modification is an excellent predictor though:

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

and efforts to get good predictions out of attestations of quality have so far have not been able to make as good predictions as that for sure.

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

I'm not convinced of this: I think the longer code lives, the easier it is to convince myself it's probably correct (or at least, correct from the business perspective). Can you explain how you get your odds?

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

I think this is predicated on whether that code needs to be changed at all: You said you think it's likely it will need to be changed, but I don't see why you think that.

Re: Code quality only matters in context (2019)

#63

Post by geocar »

greymalik wrote: post #33
twp wrote: post #27

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.

> this code sees a lot of churn because it is bad That’s one possibility. It’s also possible that it changes a lot because it’s related to business rules, which are typically more volatile than infrastructure code.

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

It's a likely possibility.

Re: Code quality only matters in context (2019)

#64

Post by solveit »

dhzhzjsbevs wrote: post #58
mbrodersen wrote: post #57

Earlier quoted context omitted.

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.

Most of the time this quantifying is impossible as you say. But sometimes half a dozen well-paid professionals do spend two hours discussing the colour of a bike shed.

Re: Code quality only matters in context (2019)

#66

Post by loziuu »

That's somewhat true. You never create big ball of mud in one go, it's a process. Process of introducing small "dirty code" changes into existing code base.

I treat writing clean code as "kata" or "habit". I feel like once I start writing dirty code more often it will translate to clean code side of things. I will continue to think of clean code as a practice, not necessity.

Also there are many small thing you would NEVER do even in dirty code like if statements that are hundred lines long, or having some unexpected side effects, etc. So if we agree that clean code is very very subjective, we must agree that "acceptable amount of dirty code" is subjective too.

Re: Code quality only matters in context (2019)

#68

Post by closeparen »

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.

The fundamental performance complaint you can make about a developer is that their PRs are bad… whether that’s too little/too late, too many problems, or too unwieldy to reasonably review.

You don’t fire someone over one incident. But if someone declines to internalize the feedback and continues to make PRs that are very far from acceptable or even reviewable, yes that is grounds for termination.

Re: Code quality only matters in context (2019)

#69

Post by nickm12 »

Something about this rubs me the wrong way. I think the argument that code quality matters less in the tail doesn't account for the fact that you are working on the code right now. By construction, the code you are writing at any point is the most recent code in the code base, so likely in an area that will be touched again soon.

I modulate my code quality a little bit, but for the most part I have one gear (write what I consider "high quality" code) and it has served me well. I find cutting corners tends to lead to bugs or other regrets the next time I have to work in the code.

At a very minimum, writing quality code helps my thought process while I'm working on it and respects the time of my code reviewers who will have to read it.

Re: Code quality only matters in context (2019)

#70

Post by mbrodersen »

dhzhzjsbevs wrote: post #58
mbrodersen wrote: post #57

Earlier quoted context omitted.

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.

Does the meeting move a revenue generating project forward or solve a customer issue? If not then it is 100% cost. BS feel good ideas like “coordination”, “alignment”, “transparency” and pretending to include people in the decision process has zero value unless it results in progress on revenue generating projects. The more people you include in a decision the slower you make progress. The sooner you make progress the sooner you get feedback and learn how to improve. The least productive and unsuccessful companies I have worked for spend most of their time on exactly the BS ideas you mentioned. The most successful companies I have ever worked for spent zero time on “coordination”, “alignment” etc. They were too busy killing the competition in the market place.
Post reply on HN