Hacker News Reader

Comment by rbranson | Hacker News Reader

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!

View on HN

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 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.

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

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.

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.

Reply on news.ycombinator.com