4 ms·

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 g

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)

nupark2 15y ago
If you're not going to re-use something, then why are you writing it to be re-usable?
- calebmpeterson 15y ago
  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?
  - nupark2 15y ago
    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.
- dustingetz 15y ago
  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.
buff-a 15y ago
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.

nupark2 15y ago

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

calebmpeterson 15y ago
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?
- nupark2 15y ago
  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.
dustingetz 15y ago
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.

buff-a 15y ago

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.