Hacker News Reader

Comment by ajross | Hacker News Reader

Exactly. The point bengl3rt was making, I assume, is that cavalier avoidance of process is a bad thing because it allows mistakes to happen that would be caught. That much is true.

But the assumption that's wrong is that all processes avoid mistakes. Clearly they don't.

And some of the examples here are just plain cargo cult misapplications of good ideas. The point behind code review is to catch design flaws in new code. You never want to demand refactoring of existing code in order to patch features, that hurts, it doesn't help.

View on HN

This quote is appropriate here:

Skilled people without a process will always find a way to get things done. Skill begets process. But process doesn’t beget skill. Following a recipe won’t make you a great chef – it just means you can make a competent bolognese. Great chefs don’t need cookery books. They know their medium and their ingredients so well that they can find excellent combinations as they go. The recipe becomes a natural by-product of their work.

From http://the-pastry-box-project.net/cennydd-bowles/2012-march-...

Er... great chefs do need cookery books. They may not refer to them as often, but you won't find many chefs out there without a collection of cookery books. They still use recipes for things they're not familiar with.

Besides, skill may beget product, but it doesn't necessarily beget process.

>> Besides, skill may beget product, but it doesn't necessarily beget process.

Oh boy, talk about not seeing the forest for the trees. For skill to beget a successful product, you must follow a process to get from nothing to product. So in the course of creating a successful product you have automatically created a process -- the process to build the product. That process may be used one time, or multiple times -- but it's still a process.

Not seeing the forest for the trees? Hell, if we're going to use that loose a definition, everything is a process, regardless of skill level. Even if you end up without a product, to get the steaming pile of crap you abandoned, you went through a process.

Demand, no, but often it is the best idea.

Having just (as in hours ago) been through the wringer of adding new features to a mass of spaghetti that had not been touched in 10 years, the only way I could maintain my sanity (and have some assurance beyond regression testing) that I wasn't breaking something, was to refactor the existing code and then insert my changes.

Sure. That's the point behind refactoring, it makes changes to existing code flow more smoothly. But the case here doesn't fit that at all: the change as described was a change in configuration (that just happened to be stored in a code variable), yet it was being reviewed as if it were a new feature being added through development. That's the "cargo cult" part -- refactoring in the course of development is good. Rules demanding refactoring are bad, because they hit false positives (in this case, a high priority configuration change).

Reply on news.ycombinator.com