Slashdot Mirror
When Rewriting an App Actually Makes Sense
vlangber writes "Joel Spolsky wrote a famous blog post back in 2000 called 'Things You Should Never Do, Part I,' where he wrote the following: '[T]he single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.' Here is a story about a software company that decided to rewrite their application from scratch, and their experiences from that process."
But Apple did rebuild their GUI shell, application APIs, etc. from scratch. Sure the underlying OS is based on legacy code stretching back into, really, the 1960s (BSD itself was, after all, based on AT&T's Unix), but the GUI and application APIs were totally new.
That is totally and completely false. "Cocoa is one of Apple Inc.'s native object-oriented application program environments for the Mac OS X operating system. It is one of five major APIs available for Mac OS X; the others are Carbon, POSIX (for the BSD environment), X11 and Java. [...] Cocoa is the continuation of several frameworks (primarily the App Kit and Foundation Kit) from the NeXTSTEP and OPENSTEP programming environments developed by NeXT in the 1980s and 1990s." "Carbon descends from the Toolbox, and as such, is composed of "Managers". Each Manager is a functionally-related API, defining sets of data structures and functions to manipulate them. Managers are often interdependent or layered.
Newer parts of Carbon tend to be much more object-oriented in their conception, most of them based on Core Foundation. Some Managers, such as the HIView Manager (a superset of the Control Manager), are implemented in C++, but Carbon remains a C API." And I should HARDLY need to touch on POSIX, X11, or Java, the former two of which were already functions of NeXTStep, and the latter of which was not invented at Apple.
There is NOTHING in OSX which can reasonably be believed to have been invented (in any sense of the word) for OSX! Period, the end. ALL portions of OSX contain legacy code, from the microkernel to the presentation layer. They didn't go from Display Postscript to Display PDF because it was easy, they did it because they couldn't just throw over Display Postscript and be able to utilize existing GUI code. They didn't throw out the GUI and replace it, they replaced the engine under it, then made it work on that engine. The appearance of the GUI is still customizable, as it was under NeXTStep, by mangling the images it's made of.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
This is why I am currently rewriting everything from scratch in .NET at my company.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
Regarding regexes, I've gone both ways: I've had my developers remove regexes where they were trying to use them, and I've had them add regexes where they were trying too hard to avoid them. Regexes aren't the answer, they're a single tool. You need to use them right. And the /x modifier in Perl helps a lot, allowing you to put useful whitespace and comments in the code (and a regex is code as much as any other language).
As for "as few lines as possible" - you need to do it right. When you span your code over 3 pages, that's not readable anymore. I harp on this with my developers all the time: SCOPE. Scope applies to variables, comments, and functions. The less I need to look at to understand what you're doing, the more likely it is I'm going to understand it. A huge 3-page if-elseif-elseif-else is going to be something I'm not going to understand, as I'll have forgotten all the conditionals by the time I get to the end to know really what scenarios are left - sequential access. A concise regex, on the other hand, is something that I can skim over just by moving my eyes - random access. These concerns aren't just valid for storage media (tape vs DVD/HD). Of course, 40 characters of regex special characters with no whitespace (either horizontal or vertical, preferably both) is generally going to overwhelm most readers, and is going stupid in the other direction.
Yes, readability trumps length of code. But sometimes that means to use a regex (or two or three - why make one big cryptic one when multiple simpler regexes can do the job?). And sometimes, that means avoiding them when what you really want to do is better done by another piece of code.
My favourite new-to-regex example recently has been someone trying to pull apart colon-delimited text with a regex. Woops - there are better language constructs for tokenisation, whether that's strtok in C or it's split in Perl (or better, Text::CSV_XS). Got rid of that regex in a hurry.
Look. Spolsky runs a dinky little software development firm that sells a little project management program. And it's still a dinky little software development firm after a decade. It's not like this guy runs a company that does anything critical, like avionics software, or anything really big and tightly integrated like Facebook, or financially significant like Chase's banking system, or leading-edge robotics like Boston Dynamics, or cutting-edge manufacturing like HyperMill. No, they just do Windows and Mac desktop apps. That's trailing edge technology at this point.
Some of the better shops don't hesitate to rewrite. Some have systems which intercommunicate by message passing and are designed to be rewritten in sections. (Facebook, works that way internally.) The bigger shops may have one team on the new version and a maintenance team on the old one; a small firm may not be staffed for that.
You should think about investing in learning tools. Regex is a well documented, well understood, capable feature of all modern languages. How many weeks will you spend debugging / refining your thousands of if/then/else when you could trust years of testing that has been done on regex engines? Your statement reminds me of novices who avoid ?: in favor of if/else because it's 'cryptic'.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
If they can, they really should disable the generation of that. It's a useless artifact of the broken ASP.NET WebForms approach, which isn't really even necessary for a blog like theirs.
Are you suggesting a rewrite?
"His name was James Damore."