Hacker News Reader

Comment by dustingetz | Hacker News Reader

I've never seen a java team that actually bothered to write something three times. You do it once, it sucks, you shrug because of your deadline, a ball of mud gets wrapped around it, development pace slows way down, and oh shit, it's too late to change. IMO get it as right as you can, the first time. (i work for a small, competent, enterprise java shop)

View on HN

I don't believe OP is saying right the same thing three times. He's saying that quite often, one has to write something that is almost the same as this other thing, and later yet another thing that is almost the same.

The first time you write it, just make it work. It works or it doesn't work. Chances are, yes, there's only going to be one of it. So making it "as right as you can" I assume means "it works". "Its reusable" however, is not necessary.

As soon as a "ball of mud" is being created, that is your moment to refactor. If you aren't doing that, then that is your choice. It is not possible to argue that taking an action which causes "development pace to slow way down" is a situation where refactoring would cause a deadline to be missed. Not refactoring will cause the deadline, and many more, to be missed.

I'm in agreement with OP and nupark on the rule of 3.

If you're not going to re-use something, then why are you writing it to be re-usable?

the "big ball of mud" that gets wrapped around factoring-1 IS the re-use. its not like a team writes one component, then says "OK we're done!" and writes the next. you write your infrastructure hand-in-hand with the code that uses it. but as you understand your infrastructure problems, you don't fix them, because "we'll just write a few more things around it for this milestone". for the next five milestones. software human process doesn't happen in nice, discrete chunks which are easy to understand, talk about, and justify.

Because something designed to be reusable was probably designed with an eye towards reading the code a lot and may also (incidentally?) be more well factored?

Which circles back around to the point above; until you have a few examples, trying to make something reusable will probably cause you more pain in the long run. That's not justification for bad code, just an argument against premature factorization.

Like recommendations against premature optimization, it's just a good rule of thumb.

Reply on news.ycombinator.com