Hacker News Reader

Comment by ryandrake | Hacker News Reader

One of the things I've learned the hard way is you're never going to attain aspirational software purity in a corporate, commercial software environment. I used to say naive things like "Software should compile cleanly with every warning enabled, produce no lint warnings, have zero memory leaks, and zero crashes." But the only place that is true is in my own personal hobby projects that I am under no pressure to release and therefore have years to sand and polish with love and care. I moved out of software dev (into more product/projecty roles) largely because I just couldn't bear to release software into the wild that I knew was flawed, just because of the stupid deadline. Ironically, now I help make/enforce the deadlines so there's the whole duality of man thing...

View on HN

I've had a similar experience, but I keep on producing less than perfect code even for my hobby projects. What we think of as "high quality code" usually boils down to maintainability. We like code that is easy to understand because it is easy to maintain and evolve further.

But maintainability is not an end in itself. The software also has to do what it is intended to do. That is way more important than how the code looks, in my (current) view. Therefore I write some pretty sloppy code. The reason not to write "perfect code" is also that lot of code gets thrown away at some point. Then all the effort that went into polishing it was wasted.

I've seen more sloppy code being kept and built upon, than any code being thrown away.

Once it is sloppy, it does not get easier to make code unsloppy as time goes by. Of course, "not sloppy" does not mean perfect; but it does mean understandable, testable, maintainable and extensible.

I agree on the importance of always striving to write not sloppy code. It is especially critical if you are building a system which must scale and must be maintained over a long time. Trying to avoid sloppy code is one of the things that can make programming a rewarding if challenging experience.

> understandable, testable, maintainable and extensible.

Those are all adjectives, just like "sloppy" is. So we must each make the decision as to how much effort we will invest in making code MORE understandable, MORE testable, MORE maintainable and MORE extensible.

If the value of any of those properties is 0, then the code is definitely sloppy.

In a corporate environment I insist on treating warnings as errors. They are warnings for a reason and it will lead to hard to debug errors in a sufficiently large codebase/team. Enabling it after the fact is a chore, but once it working its not much extra work.

Linting I only use for adding/correcting a file header, order or methods or other things that it can fix automatically.

> you're never going to attain aspirational software purity in a corporate, commercial software environment

Fun problem a few days ago: a slight design flaw allows a class of bug that a typechecker can't currently catch. Fixing the design flaw involves updating 25,000 lines across a few thousand files. Only 6 of the 25,000 lines demonstrated the bug (~1 in 4,000).

If we wait two months we can build a tool to catch the errors (and many others like it) without updating the code. The design flaw stays, but its impact is nullified.

Reply on news.ycombinator.com