Hacker News Reader

Comment by mgkimsal | Hacker News Reader

"They’ll see the code, and if the code is shit, then you may be in trouble"

Has anyone EVER gotten "in trouble" for shit code? It's about 80-90% of everything I've ever come across in the last 15 years. And frankly, probably 50-60% of what I've produced in that time also falls in that camp as well. It's only been in the last 5-10 years that attention to code quality has really been on my radar, prompted in part because I've had to provide support on stuff I wrote 10-15 years ago and ... it really opened my eyes as to where I cut corners and the huge impact it can have.

View on HN

That reminds me, years ago I was on the corporate buyer end of a sizable project, and everything was rolling smoothly toward closing, until a fellow engineer and I went on-site to see the code. It was as if it had been run through a human obfuscator. The entire C codebase was a single main() function in one file, all "subroutines" copy/pasted over and over, cryptic variable names, no comments, no indentation. The "programmers" had to convince us this wasn't a prank before we walked out in shock.

If an organization or an individual were to be firm on two rules, shit would reduce drastically:

  1. Effort of maintenance post-release not to exceed X times of development effort.  Otherwise the current system warrants to be relooked at.
  2. When in doubt, refer to rule #1.

In the real world, shit-producing daemons are ubiquitous.

This sounds like "half of the code I see is below average".

Good code is rare because goodness of code is a relative measure against other code.

doesn't have to be. it can be measured against defined standards - documentation, tests, clear naming, complexity metrics, etc. it's not just a case of "half of everything is above average".

I used to compare my code to my previous code and other code I saw, and most of the time it was 'good'. When I started comparing my code to more external measures, most of my own code would now be 'poor', because of the external things it didn't measure up to. Now, often, there were valid reasons for cutting corners, but... that doesn't make the code itself better, it just justified the poor quality.

I agree with everything you've said in your reply but it does not contradict what I said.

To be more specific, the "defined standards" (docs, tests etc) are measures of what makes something better or worse. They aren't a measure of what is good. What is good is if those docs, tests etc are superior to the docs, tests etc of other code.

And we are right where back to the relative measure problem.

One could come up with an objective measure of "good" which would require a threshold for these measures. Such a measure would require us to say that a project is good if the docs are of such and such standard, the test coverage >60%, the names can be understood by most people and so forth.

However, I think that standard would still be informed by what most people do.

To put it another way, if we waved a magical wand and everyone started documenting and testing starting tomorrow, then "good" code would require something else.

Good code often doesn't add value to the business or generate revenues. Getting a feature done does. (Doesn't mean I advocate writing below average code though!)

Reply on news.ycombinator.com