in reply to The Boy Scout Rule
Well, Joel is an experienced writer who knows how to address his audience. You are, of course, sailing on a yacht, not a dinghy, and you are intended to identify most-specifically with his “old salt.” But the point of view of the rest of the yacht’s crew, and of the millionaire owner, and of every customer that the yacht exists to serve, must also be taken into account, too. The fact that you are placed into a well-supported bubble also means that your point-of-view is not the only one that must be counted. And, this is where a lot of the friction arises.
These days, I am mostly a consultant, mostly dealing with existing projects that were written in a variety of languages, including but not limited to Perl. These projects now have “gray-hair problems,” yet for the most part they are also still earning revenue from still-satisfied clients. The developers (who are still left), however, always want to “refactor” the code ... to make it, somehow, “–er.” They insist that it must be done; that their careers are eroding before their eyes without it. But that’s not the business’s proper point-of-view, and this they do not see. They count the business owners as being both uninformed and clueless, and often leave perfectly-good jobs for what is no good reason.
bookings.com, for example, exists for two purposes: to help travelers make bookings, and to help travel professionals receive the benefit of those bookings.” The company has been financially successful, but not because of Perl and not in spite of it. Every day, it sails into waters surrounded by hungry sharks and enemy submarines. If Bookings makes the slightest mis-step, or shows the slightest sign of weakness, they will pounce. There will be no second chance.
So, a primary testing-concern for Bookings is to be able to ensure that the software does not degrade, as seen by either of its two sets of paying customers. The number-one concern is not whether the crusty-old code remains crusty (it will ...), but that it continues to earn revenue without incurring returns or loss of goodwill. “Refactoring” is merely a euphemism for “[partial or total] rewriting.” The business risk of doing any such thing is enormous, but any change whatever to software that is in service carries similarly disastrous risks. The one and only way to counter that risk is through effective present-state and future-state Testing. Testing which may or may not exist, and which, if it does exist, might not be adequate to avoid ... regression. (And it is not being hyperbolic to say that, “well, the Titanic ‘regressed.’”) There is no room for error, because the potential business risk is infinite. Those sharks and submarines won’t leave any flotsam behind.
Therefore, it is most-important to be certain that each change which is introduced into the (now-legacy) code base is clearly understood, correctly installed and then deployed, and that it is known in advance (by objective testing) that regression will not occur ... so that it never does ... so that the torpedoes always miss and the sharks remain hungry. These are procedural things, and IMHO “software testing” is especially about that procedure. Testing is the minesweepers and anti-submarine craft which always sail in front of the fleet, and you can be quite sure they’re not just sitting on the foredeck, looking out at the surface of the water and saying self-confidently, “I don’t see anything.”