When Rewriting an App Actually Makes Sense 289
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."
Re:And why? (Score:3, Informative)
I am about half way through the article in the second link, and it is really interesting, and informative. :>
Maybe not news, but it is worth your time (or at least mine).
Re:Missing the point (Score:5, Informative)
Actually, from what I got from the article it seems they also felt that the basic design of the original version of application just wasn't good enough, that it was in fact seriously lacking and that a gradual rewrite would take longer and not accomplish what they wanted (to clean up and future-proof their application).
Re:And why? (Score:2, Informative)
I'm the author of the blog post. The Joel article is 10 years old, but not the one I wrote(the the second link).
Vidar Langberget
6 KB wasted on fucking VIEWSTATE data. (Score:2, Informative)
I just looked at their article, and 6 KB of the page was near-useless VIEWSTATE data. 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.
Seriously, with a typical Slashdot posting resulting in 80,000 unique hits for the target site, they're going to waste over 480 MB of bandwidth serving up just that useless VIEWSTATE data.
Re:6 KB wasted on fucking VIEWSTATE data. (Score:4, Informative)
The blog module uses templated controls. When you bind data to a templated control, all that data get's stuffed into the viewstate as default. To fetch the comment content, the template for a comment has this snippet:
<%# Container.CommentContent %>
As default in
<asp:Literal runat="server" ID="litBlogCommentContent" EnableViewState="false" Text=""></asp:Literal>
I usually check the size of the viewstate, but none of the blogposts I checked had any comments, so I didn't catch it when we created the site. I'll update it as soon as traffic slows down a bit.
Re:Here's my short list (Score:2, Informative)
Do you really think that a thousand if-else statements is more readable than a regex statement. If it takes you one hundred lines of code to test for one condition, then the code becomes less readable, even if each piece makes more sense. RegEx is optimized to test for formatting of a string. This is what it was meant for.
Pseudo-code:
'If Email Address
If (String.RegExMatch("^([a-zA-Z0-9_\-\.]+)@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([a-zA-Z0-9\-]+\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)$")) Then
'Do Stuff
Else
'Do Other Stuff
End If
As proof of the point I'm not going to try and program the same functionality with If-Else statements. If you are using regular expressions correctly you leave a human-readable comment explaining what the regular expression matches.
But I think the important point to take away here, is that we can all agree that VB sucks. =)
RegEx copied from regexlib.com [regexlib.com]
What, no plus sign? (Score:3, Informative)
Re:Here's my short list (Score:5, Informative)
dude, THIS is the regex to validate an email address: http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html [ex-parrot.com]
Re:Here's my short list (Score:3, Informative)
That has to be the +5 funniest thing I've read in a month. Thank you, I just about fell out of my chair.
Re:There are actually a few good reasons (Score:4, Informative)
I quite like the way that the article claims that it shows an exception to Spolsky's rule, but actually isn't at all: they claim to have started off as a successful CMS company with "big name" clients, embarked on a rewrite that took them off the market for two years and ended up as a tiny player with "more than two hundred web projects [...] in Norway".
As far as I can tell this is a project that went exactly the way Spolsky predicted: they had a decent product, they embarked on a rewrite that took longer than they expected and they lost the market by doing it.
Re:There are actually a few good reasons (Score:2, Informative)
Rewriting works sometimes, without a doubt (Score:2, Informative)
I worked for a company that rewrote the same application three times in different technology. 2 time using MS .net tech - aspx, .net desktop, and 3rd with PHP.
The first incarnation was a disaster from a performance/scalability point of view, but we did learn the (surprisingly complex) business requirements very well.
The second incarnation was good, developed quickly, but missed the target market -- nobody wanted a desktop app
The third performed much better than either predecessor, was simpler to maintain, and actually made money... still is.
There was some desire to rewrite it a fourth time, but that has been abandoned in favor of extending the existing system has been the current methodology.
The lesson here is "if it sucks, rewrite it". And more often than not, it is too costly to not rewrite it. Specifically, if the system was not rewritten a third time, the company could not (and would not) exist. As it sits, the product is quite good at what it does. The balance is looking 5 or 10 years forward and looking 1 year forward. If the system you are using won't last 1 year forward, let alone 10, a rewrite may be needed, duh!
The second lesson is "if it is not perfect, fix it". (In the third case it would last a year, but fixing it would maybe make it last 3 or 5 -- it's going on 5 now, and is looking good for another 5)
What this person seems to be faced with is the same thing as that of COBOL ... asp is old tech, nobody really wants to work with it, and it definitely is not perfect. A rewrite is the only sensible thing. (And yes, anything in COBOL should be rewritten too.)
Joel contradicts the IEEE (Score:3, Informative)
Joel's position contradicts a paper I read years ago in an IEEE software journal that basically said you needed to plan on rewriting your application about every 7 years or have it collapse on you. The logic in the paper was based on two things I've found to be true in the real world. First, the world changes. Individually it's small changes, but looking at it on the half-decade-to-decade scale it can add up to huge differences in what's needed in the software. Second, software isn't infinitely extensible/adaptable. Any software has a basic architecture and world-view, and a limit beyond which it can't be pushed without an exponential increase in the time and effort needed to successfully make the changes. The two combine to mean that at some point it simply becomes technically infeasible to extend and adapt an existing system. The requirements have changed too much and you're having to fight the system trying to make it do, not just what it wasn't designed to do, but what it was actively designed not to do.
Now, business doesn't like this. It doesn't make sense from a business perspective, and it'd be much better to simply keep adapting and extending what's already there. But that ignores the fact that something must be technically feasible before you can even ask whether it makes business sense. If you've got the best idea in the world that'll make the business tons of money while giving you a virtual monopoly in the field and reducing costs by 99%, that basically is from a business standpoint the absolutely ideal thing to do, but it requires the manufacture of say room-temperature superconducting wire by the mile, then it just ain't gonna happen. How desirable it is from a business perspective doesn't matter because it just isn't technically possible at this point in time.
I also liken it to building a 20-story office tower. It's tempting to start with a simple one-story building and slowing add to it until you've got what you want, but the foundation of a one-story building just isn't going to be able to support a 20-story tower. You might be able to get 2 or 3 stories out of it, but at some point you're going to have to tear the whole building down and re-do the very foundations themselves to support the greater weight.
Re:Don't pay so much attention to Joel Spolsky. (Score:4, Informative)
Dinky company, perhaps, but quite successful at a personal level. In less than ten years, Joel took his company from zero to seven million dollars per year by my accounting.
http://joelonsoftware.com/articles/BionicOffice.html
$700 per employee in the original office
http://joelonsoftware.com/items/2008/12/29.html [joelonsoftware.com]
"built for 18 employees" = about $12,600/month
http://www.inc.com/magazine/20080601/how-hard-could-it-be-adventures-in-office-space.html [inc.com]
"When we moved into our current offices, our rent had been equal to 15 percent of revenue, which was high. But the company grew, and today our rent is only about 2 percent of revenue."
So revenue was $84,000/mo ($1,008,000/yr) and is now about $7,500,000/year.
So he's not a complete waste of space. And he may not be God but that doesn't mean he's never right and/or never worth listening to. READ THE F ARTICLE about rewrites--plenty of Slashdotters (you included) have been here long enough to know that at least, his example about Netscape/Mozilla is 100% accurate. They lost YEARS because they chose to rewrite everything.
And judging by the comments here, I think a lot of people are reading the title and thinking he's saying "never make any changes." That is 10000% NOT what he is saying. He's saying "never throw away 100% of your code and start over from scratch." If you actually read his original article (I know, I'm new here) you'll see a lot of really good points.
Joel isn't God, but he isn't just some stumbling moron either. There IS a continuum between those two extremes, you know.