Developers Like to Rewrite Apps from Scratch - But Should We?

Discussions

News: Developers Like to Rewrite Apps from Scratch - But Should We?

  1. The first version(s) of a successful application is focused, does what it needs to do and seems to have a killer feature its audience love; sometimes that killer feature was just an accident or maybe it was the plan the whole time. We developers, the creators, also know there are a few rough edges, maybe a few things that don't perform as well as possible so, at some point, we just decide to rewrite the whole entire thing.

    A lot of times there is a valid point behind that decision. Maybe there is some new technology that addresses that certain business problem much more efficiently or maybe the codebase just got too big, difficult to manage and most of it is useless anyway. Unfortunately a lot of times we just decide to rewrite from scratch because our nature as programmers got the better of the situation, we got a little lazy and our heads just got clouded with naive thoughts of brilliance; we do not like to improve incrementally, we believe we can just build something straight out better, no matter how long it took to build what is currently in production. We ignore geek history and lessons learned from the whole horror stories like Netscape's. Do you remember how cool Netscape used to be? Now do you remember Netscape Communicator? Netscape 4? Netscape 5? Ugh. If you do not, get out of here and go ask your mommy to make your cereal! In more recent days, Digg.com's disaster comes to mind.

    Fellow programers, yes programmers (I know that is not a cool term anymore but that's what we are - we are not engineers, I can barely use a screwdriver), be aware of the "Second System Syndrome", term first used by Fred Brooks.

    It is easier to write code than to understand code that already exists and it is a lot cooler (who are we kidding). When we rewrite those applications we try to add every feature the first version(s) did no have because we think that we will do a better job, a sense of confidence that sounds more like a wish. So before you throw away years if hardwork and knowledge, try to really understand what you are leaving behind; and if it does make sense to rewrite from scratch, keep in mind what the priorities are and the core features that made the application a success in the first place.

    By the way, I myself just proposed a partial rewrite of a 10-years system that is very successful. Did it make sense? Yes. But did my wild dreams of cool programming with Scala and hopefully some real-time Bayeux influence my decision? Hell yea!

    (This is my first post from my new home/matchbox in NYC - goodbye sunshine state, we had a great run together).

    Originally posted at http://geeks.aretotally.in/developers-like-to-rewrite-apps-from-scratch.

     

  2. There are good reasons to rewrite an application and there are bad reasons to rewrite an application.  The issue is that a lot of people (developers and not) who are confused about which is which.

    Bad Reasons:

    To use a new tool, technology or langauge.

    Because it's not done the way you would do it.

    Because you don't understand why things were done a certain way.

    Good Reasons:

    The code is known to not work properly and fixing it is more costly than a rewrite.  (This is true more often that you might think.)

    The current technolgy is costly to support (e.g. licensing) and a rewrite will save money.

    Enhancements are needed to the current implementation but it has a very brittle design AND the cost of fixing it is greater than a rewrite.

    It's built in .NET

  3. If anyone isn't sure, the last one is a joke.  Except if today's Wednesday, of course.

  4. Good reason

    When, in an MVC based framework, most application code resides in the view controller, tens of scenarios are combined into single methods of 4-5k lines of 'code', which is controlled by 15 level deep nested if/for/while constructs and dozens of random named flags, concatenated queries all over the place, etc. etc.; this times 100 applications that makes the complete product.

    Or am I just suffering from the 'not invented by me syndrome'? oh man, I love my job... :p

  5. Or am I just suffering from the 'not invented by me syndrome'? oh man, I love my job... :p

    The question is whether it would be less effort to produce the required level of quality with a new application.  This isn't an easy thing to pin down so there's a good bit of subjectivity and you need to make a lot of assumptions.

    A lot of this depends on how often you have to fix bugs or enhance it.  If you have a major upgrade with lots of changes, it might be enough in itself to rewrite large portions of the code for that effort alone.  But if you spend 10 hours a year on small tweaks, probably not.

    I've worked on code that sounds similar.  Another aspect is whether it works properly (code like that often doesn't) or when it can't be proven that it does.  These are real problems that are often ignored.

  6. Oh boy, that code is A DREAM FOR ME, I LOVE REFACTORING, I think refactoring MUST BE an special and VALUED job :)

     

  7. When refactoring, when rewriting?

    The analogy with buildings is good, when you restore a very old building?

    Answer: when value of building is very high (for instance is artistic or archeological) and the infrastructure  is good enough.

    The same in software: when the application is very critical (valued) and is good enough (it does badly the job but it works).

    If the application is good enough (few bugs) but the architecture is a nightmare, hard to maintain and to add simple new features... then refactoring is the path.

    When you are refactoring you are not adding new behavior, you don't fix bugs (in spite of sometimes hidden bugs are discovered), you are reorganizing the code, for instance dividing one class into ten or more classes. Is basically applying OOP, eliminating duplication and applying single responsibility to the code.

     

  8. Code writting is just a time recording of current thoughts and understanding. It's always better to arise to the consideration : "what a dumb!", and recreate the whole stuff (as the most time wasting process is thinking not fingering), than putting some ropes to tie a broken stuff. Sorry for 1 minute managers, but non rentable good usable work is best than poor unusefull bullshit.

    d'écriture de code est juste un temps d'enregistrement des réflexions en cours et la compréhension. Il est toujours préférable de se présenter à l'examen: «Qu'est-ce qu'un idiot!", Et de recréer tout le truc (comme le processus de gaspiller plus de temps pense pas doigté), que de mettre des cordes pour attacher un truc cassé. Désolé pour 1 minute gestionnaires, mais non locative bon travail utilisable est mieux que des conneries unusefull pauvres.
    AfrikaansAlbanianArabicArmenianAzerbaijaniBasqueBelarusianBulgarianCatalanChinese (Simplified)Chinese (Traditional)CroatianCzechDanishDetect languageDutchEnglishEstonianFilipinoFinnishFrenchGalicianGeorgianGermanGreekHaitian CreoleHebrewHindiHungarianIcelandicIndonesianIrishItalianJapaneseKoreanLatinLatvianLithuanianMacedonianMalayMalteseNorwegianPersianPolishPortugueseRomanianRussianSerbianSlovakSlovenianSpanishSwahiliSwedishThaiTurkishUkrainianUrduVietnameseWelshYiddish?AfrikaansAlbanianArabicArmenianAzerbaijaniBasqueBelarusianBulgarianCatalanChinese (Simplified)Chinese (Traditional)CroatianCzechDanishDutchEnglishEstonianFilipinoFinnishFrenchGalicianGeorgianGermanGreekHaitian CreoleHebrewHindiHungarianIcelandicIndonesianIrishItalianJapaneseKoreanLatinLatvianLithuanianMacedonianMalayMalteseNorwegianPersianPolishPortugueseRomanianRussianSerbianSlovakSlovenianSpanishSwahiliSwedishThaiTurkishUkrainianUrduVietnameseWelshYiddishDétecter la langue » French
  9. Code writting is just a time recording of current thoughts and understanding. It's always better to arise to the consideration : "what a dumb!", and recreate the whole stuff (as the most time wasting process is thinking not fingering), than putting some ropes to tie a broken stuff. Sorry for 1 minute managers, but non rentable good usable work is best than poor unusefull bullshit.

    I'm really not sure whether this is a spam bot or just a confused Frenchman that just discovered Google Translate. I'll call that feeling the Turing inflection.

    What's even more disturbing is that it makes about as much sense as other coments...

  10. I laughed out so loud at this one. So true!!

  11. I generally prefer going down the re-factoring legacy code route as opposed to a full re-write.  Generally speaking you can write accceptance tests for the core/important parts of your application fairly quickly and then start to untangel some of the mess underneath.

    Yes sometimes it's worth a complete re-write, but there's often a lot of 'knowledge' hidden in the original source code that you can't afford to lose.

  12. What? Nobody posted a link to Joel's famous article yet?

    Here it is:

    Joel on Software Things You Should Never Do, Part I

    http://www.joelonsoftware.com/articles/fog0000000069.html

     

  13. What? Nobody posted a link to Joel's famous article yet?

    Here it is:

    Joel on Software Things You Should Never Do, Part I

    http://www.joelonsoftware.com/articles/fog0000000069.html

    Joel Spolsky is a smart guy but you might want to read this before you follow his advice without question:

    http://www.joelonsoftware.com/items/2003/10/13.html

  14. What? Nobody posted a link to Joel's famous article yet?

    Here it is:

    Joel on Software Things You Should Never Do, Part I

    http://www.joelonsoftware.com/articles/fog0000000069.html

    I don't buy Joel's arguments, I know the history behind Netscape, Netscape Navigator v4 lost the browser war period.

    There are several reasons why Netscape lost the war, but there is one very important, MSIE v4 was BETTER than Navigator v4, Navigator v4 was a complete nightmare and the code base was terrific because the web paradigm between v3 (Gold version) and v4 had changed, this new paradigm was DHTML and the code base of Navigator v3 was not ready for DHTML and to get quickly some DHTML behavior tons of crap was put on top of v3, in that ocasion a deep refactoring of v3 was needed but there was not time, yes competition (MSIE) and no deep refactoring killed Navigator.

    Because Navigator 4 lost the battle, one year, two year, three years.. were not important, Netscape 5 should be a very different beast to Navigator 4, yes, they could reuse some code of v4 but no very much and in those days time was not important, Internet Explorer dominance was upper 90%.

    Netscape v5 was built because the world NEEDED an alternative to the absolute dominance of MSIE to avoid the web standards being locked "forever" to the Microsoft world, the rise of Java in server, PHP, Cold Fusion etc helped very much. And after this very long path we got Netscape 5 first and later FireFox.