Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Programming Software

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."
This discussion has been archived. No new comments can be posted.

When Rewriting an App Actually Makes Sense

Comments Filter:
  • by Anonymous Coward on Saturday May 22, 2010 @08:50AM (#32304762)

    5. When it is written in Visual Basic. Always.
    4. When I'm getting paid by the hour and it is written in Visual Basic. Always
    3. When it was written in a mid-90s WYSIWIG bastard child of a mid-80s interpreted language.
    2. When it uses a thousand "IF-THEN-ELSE" when it means to use regular expressions
    1. When it is written in Visual basic.

    • Re: (Score:2, Insightful)

      by beakerMeep ( 716990 )
      See if someone put in a bunch of cryptic RegEx, I would re-write it as If-then-else statements.

      For me readability > length of code.

      I always find it funny when developers are struggling to fit their code on as few lines as possible. Like the forgot how to scroll or something.

      Still, if it was written in Visual Basic, I'd let you take care of it.
      • Re: (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.

        '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

        • What, no plus sign? (Score:3, Informative)

          by tepples ( 727027 )
          I noticed that your regular expression doesn't allow the plus sign as a valid character in e-mail addresses. For example, a lot of e-mail providers allow receiving mail at, say, pino+regexlib@example.com, which gets put in the same mailbox as pino@example.com but tagged with "regexlib". See here [dustindiaz.com] for instance.
          • Sorry about that. I just used that as an example and did a quick search for a code. I agree that I am frustrated when a program doesn't validate, but the entry is to specification. The poster after you posted a link to a proper email regex string.

          • You are aware that parsing an email address is not the same as saying pino@example.com is equivalent to pino+whatever@example.com ... the + is something done by the server, nothing to do with the standard.

            Granted, most email validators don't follow the RFC. I still go with "the only way to validate an email address is to send an email to the address and monitor for a valid response" (meaning user interaction, bounceback, etc).

        • by hjf ( 703092 ) on Saturday May 22, 2010 @10:22AM (#32305318) Homepage

          dude, THIS is the regex to validate an email address: http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html [ex-parrot.com]

        • My $.02 (Score:3, Insightful)

          I'm not a real programmer. I used to play with BASIC back 25 years ago or so and I've fooled around with writing C code for microcontrollers a bit lately but my skills are very limited to say the least. None the less, I was able to parse that regular expression without too much trouble. That leads me to believe that it can't be all that hard for someone who codes for a living to understand it. Still, it would be helpful to spend a minute or two with some helpful commenting.

      • by Tanktalus ( 794810 ) on Saturday May 22, 2010 @09:51AM (#32305126) Journal

        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.

        • by Sarten-X ( 1102295 ) on Saturday May 22, 2010 @11:49AM (#32305908) Homepage

          My supervisor is (rightfully) wary of regexes, due to their reputation for unreadability. My favorite solution (in Java): Make a bunch of string constants to match various elements, then assemble those strings together into more strings, which are finally assembled into a single real regex. Sure, it takes about 15 lines for a moderately-complicated regex, but readability is superior to using 15 lines of indexof and substr.

          And now, to just bring up a topic that I have a personal interest in:

          Nobody knows how to write parsers anymore. I've never seen a recent university CS curriculum that covers parsing with respect to different parser constructs for different languages. Sure, the students learn to load up the chosen XML parsing library and pull in XML, and they learn to take text from stdin, but there's seldom any emphasis on what to do with more screwy formats. Maybe, just maybe, they might get exposed to different languages through a compilers class, but generally not how to process different languages outside of lex/yacc. This bothers me greatly.

          • Re: (Score:3, Interesting)

            by BikeHelmet ( 1437881 )

            Nobody knows how to write parsers anymore. I've never seen a recent university CS curriculum that covers parsing with respect to different parser constructs for different languages. Sure, the students learn to load up the chosen XML parsing library and pull in XML, and they learn to take text from stdin, but there's seldom any emphasis on what to do with more screwy formats. Maybe, just maybe, they might get exposed to different languages through a compilers class, but generally not how to process different languages outside of lex/yacc. This bothers me greatly.

            Warning: Long rambling post follows. To summarize, I haven't found any courses that covered anything close to parsing, except maybe invoking XML parsing libraries and stuff.

            Before I took any programming courses, I figured out how to create an XML parser in javascript. I had a dream of making a game, which needed server-side storage, but I never got around to finishing it. Quite an experiment, though.

            After that I went on to help decode Outpost 2 [wikipedia.org]'s compiled map format. (maps were DLL files - oh the design ch

      • by Surt ( 22457 ) on Saturday May 22, 2010 @10:41AM (#32305440) Homepage Journal

        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'.

        • Re: (Score:3, Insightful)

          Your statement reminds me of novices who avoid ?: in favor of if/else because it's 'cryptic'.

          It's not about being cryptic. I use if/else and I've been cutting code for decades. if/else and ?/: do the same thing, while one is easier to read while you're scanning through lines of code (it's just English after all). That the novices can understand what's been written is a bonus.

      • by WDot ( 1286728 ) on Saturday May 22, 2010 @11:01AM (#32305606)
        You could just put in a comment that says "This regex tests for an email address."

        I've massaged if-else code into regexes before. Having several if-elses for a piece of data is rickety and (in my opinion) would take more work to rework than a regular expression if the data changed.
        • Bingo! You stole my thunder. Mod parent up Insightful. The solution to the infamous regex problem is to comment them. Your style guide should even have something like, "any regex longer than N characters should have a comment next to it". Developers who live, breathe and eat regex should be mindful that it might look like line noise to the rest of us, or that we might be able to parse it in 15 minutes whereas we can read your comment in 2 seconds.

        • What if there is a misplaced character in a 50 character (or more) regex? If it only broke in some obscure cases, even with a comment saying "this matches an email address", how the hell would you debug it?

          • Re: (Score:3, Insightful)

            by willy_me ( 212994 )
            If there is a problem with the regex you simply have to debug it - this is programming after all. The reason why the comment is important is that the debugger must know exactly what the regex is supposed to do. Is is any valid email addresses? Are there any exceptions? Once a programmer knows exactly what the code is supposed to do they can go about fixing it. Attempting to derive what the coded is supposed to do from the currently broken code is a recipe for disaster.
      • Using a RegEx could simultaneously decrease development time and reduce the number of bugs - everything the code do is located on a couple of lines of codes.
        Conversely, this might make it very hard/impossible to understand and change by someone that isn't a wizard in regular expressions (or might contain hard to identify bugs). Also, moving from ASCII to Unicode might be difficult.
        Regular expressions and pattern matching (see Erlang) are very powerful technologies

    • by PRMan ( 959735 ) on Saturday May 22, 2010 @09:43AM (#32305084)

      5. When it is written in Visual Basic. Always.
      4. When I'm getting paid by the hour and it is written in Visual Basic. Always
      3. When it was written in a mid-90s WYSIWIG bastard child of a mid-80s interpreted language.
      2. When it uses multiple five-to-ten thousand line case statements
      1. When it is written in Access basic.

      This is why I am currently rewriting everything from scratch in .NET at my company.

      • Re: (Score:3, Informative)

        by Surt ( 22457 )

        That has to be the +5 funniest thing I've read in a month. Thank you, I just about fell out of my chair.

    • by fishexe ( 168879 )

      3. When it was written in a mid-90s WYSIWIG bastard child of a mid-80s interpreted language.

      In what universe is a language developed in 1964 and first marketed by Microsoft in 1975 a "mid-80s interpreted language"?


      For the noobs, thats What-You-See-Is-What-I-Got, normally after some software that was promised to deliver ABC gets XYZ instead, after paying M thousand dollars, and is in the process of being reported to upper Management.

    • 6. When it was a product of outsourcing to a foreign country. God, maintaining that shit is the bane of my existence. At least they've upgraded to VB 2005.

  • by rxan ( 1424721 ) on Saturday May 22, 2010 @09:02AM (#32304818)
    you must stop looking backward.
    • by dotancohen ( 1015143 ) on Saturday May 22, 2010 @11:02AM (#32305612) Homepage

      you must stop looking backward.

      And loose all your users. They are in your 'Backwards" direction.

      I have filed or triaged well over 1000 bugs for KDE since KDE 4 came out. Forget about the missing features from KDE 3 to KDE 4, they don't care about breaking compatibility from KDE 4.n to KDE 4.n+1. Even Kaddressbook, one of the core KDE apps, had severe functionality loss from KDE 4.3 to KDE 4.4. Amarok, Koffice, and other lose severe core functionality when their "new versions" were actually "technology previews" with dot-oh version numbers.

      • Re: (Score:2, Interesting)

        by Anonymous Coward

        The new Amarok just blows period. They could have actually done mockups and put it to a vote using a poll on their site, produced two or three demo UIs with only basic functionality implemented, put it to another vote and gone with that. In the end, the devs really just wanted to reinvent the UI because table views are so 2001.

        The result is slow as a pig, ugly and more confusing then the old one.

        Hell, I hate it so much that I now just use a Konsole instance running MPlayer instead. mplayer album/*/*.flac FT

        • Re: (Score:2, Insightful)

          This comment is disturbing in many ways.

          1) There was and is a KDE player with the table paradigm: juk. It works very well. In the 1.x days, I would use it for tagging, and amarok for the listening, now, I do everything in Amarok, because the tagging works now so much better than t used to, whether in the tagging dialogue or in the playlist.

          2) Amarok was always about meta-data around the music: similar tracks/recommended artists, WP articles, lyrics, moodbars and whatnot. In the 1.x days it was so, in the 2.

  • Ugh (Score:5, Interesting)

    by drinkypoo ( 153816 ) <martin.espinoza@gmail.com> on Saturday May 22, 2010 @09:07AM (#32304850) Homepage Journal

    Drupal does indeed brutalize your database (see second link). So looking forward to D7 to clean this up. That alone was sufficient justification to rewrite the application :p

    Unfortunately the author goes on to display his ignorance before this is all over: There are also other examples of total rewrites that have been successful. Apple's transition to OS X is a very good example. The classic Mac OS was an operating system with some good ideas, but the core architecture had a lot of problems. Did Apple make a bad decision to start from scratch with OS X? I don't think so. They brought over and improved the best bits from OS 9, and merged it with the solid Darwin core (much like we did). Uh, no, you are totally and completely fucked here. They started with NeXTStep, last updated in 1995; it was itself based on an older version of BSD (4.3?) and an older version of Mach. OSX is not a complete rewrite of anything. Its legacy stretches back into the 1980s, and so does its code.

    • by Suiggy ( 1544213 )
      A better example of complete rewrites would be iterations on game engines where vast swathes of legacy code get thrown out and are completely rewritten from scratch.
    • Re: (Score:3, Insightful)

      by jeti ( 105266 )

      The original rewrite of MacOS was Copland, which used up Apples development resources for five years before it was cancelled.
      http://en.wikipedia.org/wiki/Copland_(operating_system) [wikipedia.org]

      • Re:Ugh (Score:4, Insightful)

        by drinkypoo ( 153816 ) <martin.espinoza@gmail.com> on Saturday May 22, 2010 @10:00AM (#32305190) Homepage Journal

        The original rewrite of MacOS was Copland, which used up Apples development resources for five years before it was cancelled.

        Yeah, I remember that, it's what convinced me to stop being a Mac user. I had the INIT or CDEV or whatever that made your MacOS look like Copland. Then they cancelled it and brought out another shitty MacOS, and I ran like hell and never looked back. All the years from System 7 through System 9 were sad, abusive times to be an Apple customer. They kept bringing out inadequate hardware at astounding prices and almost spent all their cachet. Another year or two and they wouldn't have had enough fans left to float OSX.

    • Not to mention:

      They brought over and improved the best bits from OS 9,

      Apple *threw out* the best bits of OS 9. Right into a dumpster. Oh, they half-heartedly pretended to care for a short while (re-adding some features like Labels in Finder), but it was obvious they did not. They certainly didn't "improve" Labels when they *finally* got around to porting it. And many OS 9 Finder features they never bothered to port in the first place.

      Not to mention abandoning the entire philosophy OS 9 was based around-- a

  • by Opportunist ( 166417 ) on Saturday May 22, 2010 @09:09AM (#32304864)

    The problem is that companies usually rewrite for all the wrong reasons.

    A good reason would be the emerge of a new technology that supports your problem much better, to the point where redoing your code from scratch means easier maintainance later. Usually this goes hand in hand with an old technology (the one you used so far) getting abandoned by its maker. A good example would be how I had to maintain a client/server app written in VB6 using DCOM. Not some quick hack, a full blown client/server solution it was never meant to be, that also has to communicate with a SAP interface and a few more nifty things that cried out "please rewrite me". The overhead to maintain it soon turned from insane to nuts and even the tinyest change required a team of four people to work for weeks.

    Unfortunately, the reasons why something gets rewritten are usually different. Like at my next gig. A pretty well designed and fairly solid piece of code was thrown out when the original creator was fired and someone with an ego that required its own office took over and insisted we use "his" collection of libraries instead of that "old" libraries. We trashed about 2 manyears of labour down the drain to end up with what we had before.

    • Re: (Score:3, Interesting)

      by jonwil ( 467024 )

      Often the problem is that there are things that should be rewritten (either whole apps or specific sections of code) but no-one is willing to green-light such a rewrite even though the rewrite will take less time than bolting hack after hack on top of the old system.

      • even though the rewrite will take less time than bolting hack after hack on top of the old system

        Often the problem is we developers are wildly optimistic in our estimates of how long such a venture might actually take. Especially if we are talking about code we dont know much about. Until we really get to know the problem domain, it all sounds so easy :-)

        In my opinion, what Joel really is against is a wholesale "drop everything you are working on and rewrite the entire app". From hard-won experience, he

    • by Kijori ( 897770 ) <ward.jake@gm[ ].com ['ail' in gap]> on Saturday May 22, 2010 @12:53PM (#32306368)

      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: (Score:2, Informative)

        by vlangber ( 566882 )
        You're correct, we were reasonably successful before the rewrite started, but we started to see limitations in the original architecture that would become much bigger problems in the future. So yes, we traded growth for a while, in order to get a solid foundation. We still think we made the right decision, as we feel our future prospects are so much better now, than if we had continued with the old system. Time will tell.
  • by AnonymousClown ( 1788472 ) on Saturday May 22, 2010 @09:24AM (#32304954)
    The article was interesting in how they made their decision and I don't think it was necessarily a bad decision - assuming their assessment of the old version was correct. The process looked like it broke down in the design and planning phases. The article didn't go into detail on the design and planning; which kind of leads me to believe that may have tried to do the "superstar" programmer thing and rewrite it over a weekend. Anyone whose been in development long enough has heard the "he coded it over the weekend"stories and the programmer "street cred" it gave - at least back then.

    I've seen rewrites/ports go quite well. Systems that were originally on mainframes and needed or wanted to be moved to cheaper hardware for cost - if it was the proper thing to do (Sometimes you really need the metal).

    Another rewrite that went well was a bunch of code that over the decades became so convoluted to be a maintenance nightmare - modify one thing or add on functionality and then break a shit load of other things.

    Just do these basica things and it'll work out.

    Go back to the specs and start there.

    Talk to the stake holders - yep, there will be creep but also feature reduction because there are things that they never used or because it doesn't make sense anymore.

    Plan, plan, plan. No cowboy programming and hacking out shit. And document everything.

    It can work.

  • Joel's article implicitly had some tunnel vision because it did not state any exceptions. The general rule of thumb as to when to rewrite an application are:
    • Change in platform paradigm. This has happened five times thus far (post-ENIAC):
      1. Mainframe to MS-DOS
      2. MS-DOS to Client/Server
      3. Client/Server to Windows
      4. Windows to Web
      5. Web to mobile
    • Vast improvement in software technology (and you have a software project/product that requires significant expansion or improvement), such as:
      1. Machine code to Assembly
      2. Assembly to spaghetti
      3. Spaghetti to structured
      4. Structured to OO
      5. Proprietary unsupported language for obsolete sluggish database to SQL
    • Re: (Score:2, Insightful)

      The other problem is with scale.

      When a company starts a new project or an entrepreneur starts a small business it's sensible to build something quite small and straightforward. It might take off, but it might not, so don't spend more on the tech than you really need.

      So, something gets produced that's VERY hacky. And for a short term solution and from a business perspective, that's quite bright.

      The problem is that scale it up a little and it starts falling apart. It becomes hard to maintain because the funda

  • ... and most of them run in a controlled environment (server-side). So lots of Joel's advice is not going to apply.
    Then they have the balls of comparing their move to the transition from Mac OS 9 to Mac OS X!
    In the end, while their story is interesting, it adds really little value to the "Rewrite/No Rewrite" debate.

  • rewrite ONLY if it means it yields less lines of code to maintain with the same functionality. Use whatever language necessary to keep the length of code to a minimum.

    If the code doesn;t look as if it has been refactored even once... junk it.

    • rewrite ONLY if it means it yields less lines of code to maintain with the same functionality.

      I have to register a huge protest to this idea that "less lines of code" == "more maintainable". Perhaps on a grand scale across several orders of magnitude this is true, but on the small scale of say a factor of 2 or 3 it's most definitely false.

      I don't know that there's any one single simple rule that correlates well with maintainability. Maintainability has something to do with complexity, and quality which a

  • Rewriting an application can work if the developers know what they're doing. However, these rewrites are often side projects. If considerably more resources are spent to extend the original application, the rewrite will be behind until it gets cancelled. On the other hand, a rewrite is always a risk and betting your company on it is insane. In most cases it's safer to refactor the original implementation, even if it's more work than starting from scratch.

  • When your "enterprise" ERP application is written in VB6 with a roll your own alternative to ADO, half your business logic is in stored procedures that can be 5,000 lines long and 30% to 40% of your code was written to spec B.

    5 points if you can name that product

  • by Animats ( 122034 ) on Saturday May 22, 2010 @10:18AM (#32305298) Homepage

    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.

    • by kmike ( 31752 ) on Saturday May 22, 2010 @11:48AM (#32305898)

      Yes, I never understood why so many pay attention to Joel's inflammatory rants.

      I don't even want to start on his company's product (Fogbugz). Seriously, ASP/VBScript translated to PHP? And then inventing a new programming language just for a web app with ability to output in several other languages? Ugh.

      • Re: (Score:3, Insightful)

        by Vellmont ( 569020 )

        Yes, I never understood why so many pay attention to Joel's inflammatory rants.

        Partly because he's a fairly good writer, and partly because he seems to offer simple solutions to the larger problems of software, and partly because he's right at least some of the time.

        I DO think he's just dead wrong on this issue though. In my experience starting from scratch is something that should be very carefully considered, but rejecting it outright on general principles is wrong. I really don't care much about his bo

    • by sootman ( 158191 ) on Saturday May 22, 2010 @10:08PM (#32310780) Homepage Journal

      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.

      $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.

  • We faced the same challenge at our company recently.

    My company publishes a CMS for specialized niches.
    The product started around 2002, and we developed it without real direction, since we added functionalities as we needed them.
    The first years were great, since we were the only ones to release such a tool, but some concurrents emerged after a few years, proposing a much cheaper alternative.

    As we built the project without long-term view, adding new functionalities took more and more time, since the codebase

    • For this kind of approach, you really need to hear about your customers, and write the scenarios that they need, and it's obviously impossible when you start your company.

      The project is now radically different, but not yet released, since it's really a subset of the previous project.

      When you release it you will find the following things guaranteed
      - Customers have forgotten to mention 20% of the scenarios they need which is present in your current release.
      - 20% more have been misunderstood [jacobsen.no] by you.
      - Your new

  • That old crappy code has undecipherable bug fixes for 100's of obscure difficult to reproduce bugs. Many of them which could be hit only under really strange customer usage scenarios & which tooks days to reproduce, days to fix & many more days to fix whatever the fixes broke.

    So unless you original software fully automated testsuites covering every functionality & you have added a bug fix verification test for each bug which has been fixed since then, do not rewrite something from scratch.

    • That old crappy code has undecipherable bug fixes for 100's of obscure difficult to reproduce bugs. Many of them which could be hit only under really strange customer usage scenarios & which tooks days to reproduce, days to fix & many more days to fix whatever the fixes broke.

      Sounds like code that was just poorly written in the first place, and then endlessly patched and re-patched to try to "get it right this time".

      Listen, software development is about software developers and the development proces

      • Do you have experience rewriting huge enterprise software which started small, got lot of features added over the years & now has 5-10 teams of developers working fulltime on it? This kind of software is a disaster to rewrite. Yeah, if you want to rewrite something mid-size like a browser, it would probably not be as bad.
        If you want rewrite huge software, do it in small chunks across different releases after adding a lot of automated test suites & bug fix verification tests.

  • TFA says they released their software 2006, and expected it to be in use for at least 10 years. I realize the benefits of DotNET, quick development, compatible with the most popular platform. I don't think there was any mistake in starting from scratch, in and of itself. And I don't think the downside of developing in DotNET has even materialized yet, and so long as the product pays for itself before it becomes obsolete, I think they're OK. But I have a feeling that, and I admit my prejudice, that the devs
    • DotNET was they're ONLY option... never even considered that it was, never considered anything else... never considered. If a mistake was made, that was it... and again, it may not make any difference because the product may still be successful even with lock in. But there is no doubt they're

      *their *their man I am sloppy today

  • by presidenteloco ( 659168 ) on Saturday May 22, 2010 @12:43PM (#32306306)

    Often a rushed, under-resourced or under-skilled s/w project will congeal into a large, brittle, solid clot,
    which is not extendable without breaking things in mysterious prohibitive to fix ways.

    Congealment comes from insufficient or ill-conceived architecture, and/or rushed or ignorant ill-fitting extensions or mods or "fixes",
    combined with insufficient continuous re-factoring.

    This code may be worth keeping on expensive life-support if there are many existing customers depending on it,
    but make no mistake. Your codebase is already dead, even if its heart still beats.

    So then, if you still need software with similar but slightly updated or extended functionality, you should rewrite,
    and in doing so, make sure you get good architecture, take sufficient time to build each part or layer, evaluate the quality of
    all third party libraries or frameworks used (on the "volleyball" principle that the weakest member of the team drops the ball
    and determines the team's i.e. the system's quality), use continuous refactoring, with technical-risk based work prioritization
    (biggest risks dealt with first, always), document the classes and methods
    sufficiently, and include unit tests and/or invariants and pre-postconditions, so that there is a lower probability that
    further extensions will start congealing into brittle, excess complexity.

    If you can succeed at maintaining that discipline without going bankrupt, then it will have been worth it, because the value
    of your new software capital asset will be much greater than previously.

    Of course you should have done it right the first time, (and should have had management enlightened enough to let you,)
    because it would have been much cheaper to do it carefully once, than the punishing expense of the original crappy
    development and maintenance plus the rewrite. There IS a valid argument that by the time you let your s/w congeal into
    a complex, brittle clot, you are already too late, and you should pull the plug, shed a tear, and walk away.

  • Whether to do The Big Rewrite always boils down to one very simple question: do the expected gains outweigh the expected losses?

    Usually, the argument against doing a rewrite boils down to two key points:

    1. it takes time and resources just to get back to what you already had, which confers no immediate business benefit; and
    2. you risk losing the bug fixes and special cases that have accumulated during the real world use of the original implementation.

    Those are certainly valid concerns, and IME it is often true t

  • 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, a

  • by Todd Knarr ( 15451 ) on Saturday May 22, 2010 @02:18PM (#32307080) Homepage

    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.

The intelligence of any discussion diminishes with the square of the number of participants. -- Adam Walinsky