Hacker News Reader

Comment by dgb23 | Hacker News Reader

It depends entirely on how you define perfectionism. The article unfortunately doesn't explain well what they meant.

Assuming it is following, paradigms, design patterns and making the code "cleaner", then I would agree with the article 100%.

However if it was about actual engineering concerns like better error handling, performance, test coverage, nailing down invariants/validation/parsing, etc. Then I would say that we should probably be more diligent rather than less.

The issue is that the former gets too much attention and the latter too little.

View on HN

In my experience, the people who are best at error handling, performance, test coverage, nailing down invariants/validation/parsing, etc, are also the people pushing for those nebulous perfections like "cleaner" code. Getting all those things right requires the code to be pretty darn clean.

I'm not arguing against decomposition, modularisation, clarity or abstractions.

Just don't do them for their own sake.

How do you decide when it’s ’for it’s own sake’ and when it’s not?

That's a very good question that I need to think about way more.

To be cynical and uncharitable, in my experience non-engineering leadership tends to be receptive to the idea that engineers are by their nature wasteful and self indulgent, and saying “just don’t do that stuff for it’s own sake” reinforces said leadership’s prejudices and will ingratiate you with them. I’ve most often heard such arguments from people shitting on me for advocating for tests.

But the bulk of my experience is with small startups where the stakes are high; tensions around productivity are natural, and working through them is essential.

Personally, the "Rule of Three of Software Engineering" has been a good enough practice for most cases, as usual with any rule of thumb there are exceptions but most of the time I can apply it.

I've been using it for many, many years and it has saved me a countless hours by postponing abstractions, modularisation, etc. to the point where it actually emerges as a pattern in the software I'm working with. Let the code repeat itself, copy and paste, and only after some pattern repeat itself for the 3rd time I start to think on how to abstract, or modularise it.

It's always so much easier to rework repeated code/patterns into abstractions than fixing misguided abstractions done too early.

if we're being frank: When you care about the company and feel the company cares about the tech. Both of those aligning are rare. Broken windows and all that.

Now for a proper engineering answer, there's a few (but not limited to) factors to consider when determining software rigidity:

- Halo effect: How much code does this module affect? The more things that can break when the module fails, the more need to get proper testing/architecture.

- Frequency (in both ways): How often are you changing the code (is it cutting edge, or bog standard 50+ year old algorithms?) as well as how often the application calls the code. The more times its called or changed, the more you may appreciate ways to test new implementations with minimal impact to the current iteration.

- Understanding: pretty straightforward. The less you or the team understands the code, the more need to validate that code through tests. This often falls into frequency, because inevitable the less you understand the more you will need to tinker, possibly for unknown unknowns.

It's still subjective at the end of the day, but there are metrics you can use to make your case.

My experience is different.

Given the choice between fixing a quality issue that can be easily measured/detected and one that cannot, a lot of people will prefer the measurable, easy-to-detect one.

So the folks on the 'code quality' committee end up introducing tools that make it impossible to merge if your markdown file has two consecutive blank lines - rather than spending the time on performance or security which are much harder to keep on top of with automated tooling.

I like that word: diligent.

Jordan seemed to be talking about it: prioritizing; helping, rather than burdening others. Gregor seemed to be describing a lack of diligence: not fleshing out learning, fretting over less relevant details.

In my mind arguing for dilegence is a better here. It implies that the product matters, even if it is imperfect. Arguing against perfectionism is bad. To some it will imply that the product does not matter, that sloppy work is okay if you can somehow justify it (getting the job done, doing more, etc.).

IMHO article defines perfectionism doing both things you have mentioned too early. E.g. you do prototype and instead of showing that to stakeholders you clean it up, cover with tests and etc.

>design patterns and code cleanliness aren’t “actual engineering concerns”

sigh

Clean code leads to more testable code leads to more tests leads to better products. Don't be so quick to dismiss "clean code" as some BS.

I've seen first hand how someone writing a 500 line function struggles to test it. But splitting it up into more manageable chunks of functionality makes it easier to write a test.

Imo perfectionism is chasing that last 5% performance.

Clean code, design patterns etc are just good engineering practices... Not perfectionism ....

Absolutely. Breaking a design down into verifiable, testable chunks is, imo, the major delineator between a school project and a professional product.

Le me clarify: good modularization and abstractions emerge from engineering concerns (like the ones listed above) and not the other way around.

The reason I wrote the above comment is because I've seen this being flipped on its head too often by myself and others.

> Clean code, design patterns etc are just good engineering practices... Not perfectionism ....

This is what I don’t like about software engineering. The dogmatism. The absolutism. The more I work in the field, the less I talk about “clean code”, “ddd”, “good practices”. I find myself saying more and more “it depends”, and more often than not what the business requires is not 5 layers of code in which the concerns are separated among dozens of files and following good design patterns, but a damn single file that get things done.

There’s place for what you call good practices and clean code, but many times those things don’t lead to good products.

I really liked how jmac03 put things, and I don’t see the dogma you’re seeing — consider that it’s “struggles to test” not “impossible”. I don’t see any advocacy for ”dozens of files”, just breaking functionality down into “manageable chunks” to facilitate testing. In fact, “dozens of files” are arguably not “manageable“, and I don’t see an argument for that, any more than you’re arguing that every function needs to be 500 lines.

Every single startup I’ve worked for has eventually come to terms with needing some best practices. In my view, there actually is a baseline: CI, partial coverage unit tests for the most easily testable code, and modularization/loose-coupling so that unwinding tech debt has linear rather than exponential cost. But even that is driven by my opinions about ROI, not theory in isolation.

>There’s place for what you call good practices and clean code, but many times those things don’t lead to good products.

Clean code for a bad product won't turn it into a good product. That's the core issue. These are engineering principles but you are looking at them through business logic.

The best metphor here is to compare clean code to insurance. You don't want to insure this? Okay, you can take that risk and maybe save if nothing happens. But if/when something happens it'll be more expensive than if you paid the insurance up front.

Meanwhile, Clean code from a good product will make it resiliant to becoming a bad product. I'm sure if you played any modern video games that you've had at least a few games that you loved but had horrible technical hiccups. Unoptimized, untested logic, crashing. The issue is some of these games still sell, so maybe the business logic prevailed over properly engineered code. But they are entertainment at the end of the day, not Crowdstrike.

Reply on news.ycombinator.com