Hacker News Reader

Comment by fjabre | Hacker News Reader

Awesome read. I couldn't agree more.

I've worked with a great many 'theorists' coders and they never get anything done. They spend too much time abstracting into nothingness. You know.. the kind of guys who remind you of your 3rd grade grammar teacher making sure you know when to use 'whom' vs 'who'...

While I think eventually one would refine their product so that it uses best practices I would say that having customers and a product should definitely be a prerequisite.

View on HN

Yes, thank you. The moral of the story is that you ship a product first, then you tweak, improve, and refactor it once you've got a reason to!

If you do that, you'll run a very considerable risk of wonder why version 2.0 of your product is taking so damn long to ship. The answer: all of the things you punted, ignored, assumed, patched over, and otherwise haphazardly threw together in version 1.0. Now all these have set your code in concrete, and you have to remove half the foundation to get them back out.

It is always, always, always better to have a delay in version 2.0 than that a delay in version 1.0.

It is often that way anyway regardless of planning. You get into it then your needs change over time. By version 2.0 a new foundation will last longer and incorporate things people have learned from the first version.

This is know as the "second system effect":

http://en.wikipedia.org/wiki/Second-system_effect

No it isn't. The Second System effect is about wanting to put in all those features into version 2 that you left out of version 1.

Yes, which is what the parent said:

"all of the things you punted, ignored, assumed, patched over, and otherwise haphazardly threw together in version 1.0"

No, sorry it isn't. Fred Brookes goes into detail when he coins the term "Second System Effect", and it definitely doesn't refer to half-arsed, half-debugged, haphazardly thrown together anything from version 1.0.

The Second System Effect is specifically about new features.

But all that refactoring will be easy because of the comprehensive unit test suit you wrote. Oh wait...

But don't you have to add/remove/edit your comprehensive unit tests after you refactor? Refactoring would have have to include this work needed to keep your unit tests comprehensive.

Reply on news.ycombinator.com