On 12/30/2007 3:29 PM, Francis Hwang wrote: > On Dec 30, 2007, at 1:52 PM, Jay Levitt wrote: > >> On 12/29/2007 5:46 PM, Francis Hwang wrote: >> >>> - How quickly the business needs change. Designs for medical imaging >>> software are likely to change less quickly than those of a consumer- >>> facing website, which means you might have more or less time to tease >>> out the forces that would lead you to an optimal design. >> A few weeks ago, I ran across the following comment, explaining >> away 200 >> lines of copied-and-pasted internal structures in lieu of >> encapsulation, >> in what was once the world's largest consumer-facing web site: >> >> /* Yes, normally this would be */ >> /* incredibly dangerous – but MainLoop is */ >> /* very unlikely to change now (spring '00) */ >> >> Careful about those assumptions. > > Yeah, well, there's a difference between chaotic code and foolish > code. Regardless of what company I was working at, pretty much any > code that would probably break a few years out would be a problem. > > Of course, you can't predict with 100% accuracy which parts of the > code are likely to change and which are likely to go untouched for > years. I think you can make educated guesses, though.
You can, and we did... turns out they weren't. (OK, I'm exaggerating. Most of them were, and the only guesses I'm finding now are the wrong guesses, by definition. And the world's changed a lot, and we know more and can do more.) > Incidentally, how well-tested was that code base? 200 lines of copy- > and-paste smells like untested code to me. 15-20 years ago, unit tests were not a widespread industry practice :) This code's in a procedural language that really, really doesn't do unit tests well. I've been trying, too. Almost wrote a pre-processor, till I thought about the maintenance nightmare that'd cause. Jay Levitt _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
