Hacker News Reader

Comment by edw519 | Hacker News Reader

This whole issue is a sore spot for me. Seems like I've always had someone who missed their deadlines but "cleaned up" something that didn't need cleaning up. I've even done it myself. It's an easy trap to fall into, after all, we tend to be optimizers, maximizers, and perfectionists.

The best approach to this I've ever found is the solicit agreement to a few simple rules and standards. Things like:

- Don't fix it unless it's broken.

- Don't delete any code. Ever. (Did I say ever.)

- Don't bypass tools we've agreed to use.

- Don't violate standards we've agreed to follow.

- Quick and dirty isn't quick. It's only dirty.

Often the violator doesn't even realize what he's done until you point it out. OP was obviously a caricature, but you still gotta stay on top of it.

View on HN

Why not delete code? Old/stale/unused code gets only in the way and doesn't serve any purpose. And if you really happen to need it later, it is readily available in your version control system.

I fully agree with your rule about quick and dirty. I'm currently rewriting a module that was "designed" with the "I just want to get it done" approach to software engineering.

What's the old saying? A few weeks of coding can easily save you 5 minutes of design?

We're also missing a deadline. But what is the point of meeting the deadline if we have to throw out the code afterwards and start over anyway? It is better to do it right the first time. A solid system a few days late beats a crappy system on time.

In my opinion, if the code is so complex and messy that you can't see whether individual pieces are correct, then it must be considered broken, even if it compiles and does something.

"And if you really happen to need it later, it is readily available in your version control system."

Of course. I was referring to code deleted from everything, including the version control system. By the time someone noticed, it wasn't findable even on backups. Believe it or not, in some shops it does happen.

The "don't fix it until it's broken" is an interesting discussion. From what you've said, customers and developers can have a very different definition of what "broken" means, and the customer's definition trumps the developer's. I don't imagine you'd throw out all the refactoring and "cleaning up" jobs though. There'd have to be some consensus case-by-case on what is really broken and what isn't. Managers can overlook some serious code rot just because the front end seems okay. I'm guilty of being the perfectionist though, and it'd be wise of me to keep my pragmatic hat on more often.

I'm a little wary of code standards. I've found that they can be a bag full of cargo-culted banalities like "never use break statements", "never have more than one return statement", "the tertiary operator is the spawn of the Devil", "if you use a one-liner if-statement you will hang", or "duplicate all of the version control history by hand at the top of every file". I'd feel much more comfortable if I worked in a small team and we all got together and agreed on some important and useful standards rather than have them dictated by a manager who used to code back in the 90s.

Maybe the rule should be "don't fix it unless you're capable." Then you could have some guidelines for when someone is capable. Some of that might have to do with skill/experience but even with my own code I don't like to make fixes unless it's related to a feature I'm in the middle of. Otherwise I'm at risk for making subtle functional changes that I don't have any capacity for understanding or predicting.

On the topic of code standards. PEP 8.

And more importantly. Every standard is meant to be broken. It's just supposed to make you think about why you're breaking the standard. Cost-benefit and all that jazz.

Reply on news.ycombinator.com