An interesting article on text-book vrs real-world programming

In article <CAMTenCEaFSd2-5A-2tgj3meO9BRaVxeLqGUAoQR1tshoyz=E4g at mail.gmail.com>, Liam Proven <lproven at gmail.com> writes: Contrast with: <http://www.joelonsoftware.com/articles/fog0000000069.html> This was an interesting read, thanks. I always wondered why Netscape 4 was such a POS and now I know. I had heard stories from contractors who worked at netscape on how horrible the code was and at this time I don't know if they were referring to either the "duct tape code" or the rewrite code, but either way it sounds like the code was pretty shitty. I'm with Joel on rewrite vs. refactor (which is to say: don't rewrite, but do refactor incrementally with automated tests). This is also touched on by Brian Foote in his google tech talk "Big Ball of Mud" which I linked to earlier on this thread. Ugly code that has been debugged, tested and is working in the field is to be favored over new, pretty code that has not been debugged, tested and survived in the field. However, we should not delude ourself that the choice is only between ugly time-tested code and pretty untested code. The one can be transformed into the other by judicious application of automated regression tests (so you know that changes are indeed improvements and not making things worse or introducing bugs) and guided refactoring. Over the past 10 years, I have done this many times and the single biggest weapon in combatting shitty code is automated regression tests. Otherwise, you really don't know if you're making things better or not. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>