5 ms·

I've heard this time and time again, but what if your application is a genuine ball of mud? Would you really not advocate a rewrite for an unmaintainable spaghe

I've heard this time and time again, but what if your application is a genuine ball of mud? Would you really not advocate a rewrite for an unmaintainable spaghetti classic asp app still in production today?

dasil003 16y ago
I'd say it depends on if your engineering talent is vastly superior today than what it was when it was written. Even then it's so risky. It's probably always better to do it incrementally even if it takes twice as long to do so, because you can maintain working software and fix bugs as you go. The approach I would take is to get the minimum set of engineers who know the most about each major aspect of the code, and put their heads together on what the ideal architecture would be. But rather than building it from scratch, figure out how to implement just one of those pieces now. That way you can decrease entropy in the codebase piecemeal without chucking out all the code at once, which is no doubt full of forgotten assumptions that no one will remember until it's too late.
MartinCron 16y ago
I would advocate an incremental rewrite of parts of the unmaintainable spaghetti classic asp until there's none of the spaghetti left. It's easier to rewrite part of a system than an entire system. Release to production dozens, if not hundreds of times. Releases are non-events, rollbacks are non-events. A system-wide ground-up rewrite with a big-bang switchover at the end is a classic clusterfuck recipe. It's a shame that so many people think it's a good idea, even in 2010.
- davidw 16y ago
  > incremental rewrite of parts of the unmaintainable spaghetti classic Sounds good in theory. In practice? Part of the problem with many big ball of mud systems is that all the parts depend on and talk to all the other parts. Want to fix that horrid DB schema? You'll have to rewrite all the code that talks to it, or rewrite it to talk to an intermediary. Want to rewrite that horrid bit of code that's called foobar_20040623 ("foobar" has been changed, but yes, I saw this in some PHP code...), you'll have to find out what all it interacts with, and likely redo that too.
  - rwmj 16y ago
    In reality yes, it works, I've done it. We took a horrible, accreted web application, and rewrote it in stages over a period of about 12 months. At the same time we were making regular releases, and needless to say the site stayed up the whole time. You just have to plan things carefully, work hard, and keep your head screwed on. (Just like with many things in life ...)
    - davidw 16y ago
      This would make a great topic for blogs/books/whatever. "How to dig yourself out of a pile of shit."
      - MartinCron 16y ago
        I agree, although it's a somewhat sensitive thing to write about if you're doing it in practice. I sure as hell don't want to be known as the guy who comes in and calls all of the existing code a pile of shit. I guess I could "change the names to protect the innocent" and tell some stories about digging out of tight places incrementally. If it would convince even one development team that they didn't absolutely have to do a total rewrite, it would be worth it.
  - MartinCron 16y ago
    In practice? It's not easy, but nothing is. I see three options to the big ball of mud problem. 1. Wallow in it (work with existing structure). Sadly, this is what a lot of people do. I left a job once because that was the only way out of the ball of mud. I was afraid I would turn into a mud-person. 2. Slowly crawl out of it (incremental rewrite). This is hard, but do-able. It involves setting up barriers to mitigate ripple effects, automated testing to be comfortable with frequent releases, and tolerance for temporary imperfection (basically, you need to be willing to frequently release things that are only a tiny bit better than status quo, even if it's not ideal). Not everyone is willing to accept this persistent imperfection and lack of conceptual consistency, especially when option #3 is more exciting and fun. 3. Try to leap out of it and land wherever (total rewrite). This is very, very hard, and prone to total failure or spending valuable money and time to effectively stand still in the market. I've seen development teams leap directly out of one ball of mud into a different one. One where nobody even knew their way around anymore. How is that anything but a huge waste of time and resources?
- zeemonkee 16y ago
  Another issue is whether you are just rewriting the code, or fundamentally changing your data store (as Digg have done). Rewriting the code is fine - if it goes wrong, just back up to the old code, users won't notice the difference. You can do it on a page-by-page basis, just route URLs selectively to the new install. Migrating data is something that should be done under only the most extreme circumstances - and something will inevitably go horribly wrong, so be prepared to rollback.
  - MartinCron 16y ago
    Because migration is a scenario that may go horribly wrong, you should be prepared to tackle it in small pieces. So often (especially with relational databases, I don't have much experience with the NoSQL realm) everything is in one logical and physical data store, even for non-related features. That makes any migration harder than it needs to be.
_delirium 16y ago
Microsoft could be one example of a successful one. Their flagship Windows codebase that ran the 3.1->95->98->ME line was basically ditched with the rewrite-from-scratch NT (famously done by an ex-VMS team), which later had some APIs ported to it to make Windows 2000 and especially XP be close to drop-in replacements for the old line, while not really sharing much code. I think in retrospect that was probably a good idea: the NT rewrite put the codebase on much better footing than the aging, incrementally updated classic Windows codebase had been. Solaris is another example of a rewrite that seems to have worked, though the rewrite did derive from a different set of existing code, not a total from-scratch job. But the classic SunOS 1.x.-4.x codebase was ditched, and SunOS 5.x / "Solaris 2" replaced it.
- alabut 16y ago
  You covered Windows and Linux - don't forget Apple's switch to OS X. They wouldn't done a wholesale switch at some point even if they hadn't gone with something unix-based because the other alternative was Copeland, the internal project to do a complete rewrite.
  - alabut 16y ago
    EDIT: they would have made the switch. Stupid iPhone.
- papaf 16y ago
  Its a good point that NT was a successful rewrite. However, its worth noting how this was done. NT was originally aimed at a different market, there was a overlap of several years where the old system was still available AND NT ran Windows 3.1 apps in their own subsystem which contained .... the codebase of Windows 3.1.
- rythie 16y ago
  I think the NT and OSX updates were absolutely required due to architectural reasons which impact security, 98/ME and MacOS 9 just simply weren't suited to types of threats on the internet (no support for dropping process privileges, file permissions, cutting direct access to hardware etc.). If you think XP is bad in 2010, think what Me would be like if widely installed still, one program crashing the whole machine, boot sector viruses etc.
scorpion032 16y ago
but what if your application is a genuine ball of mud? Hello, Flash? (via Gruber)

dasil003 16y ago

I'd say it depends on if your engineering talent is vastly superior today than what it was when it was written. Even then it's so risky. It's probably always better to do it incrementally even if it takes twice as long to do so, because you can maintain working software and fix bugs as you go. The approach I would take is to get the minimum set of engineers who know the most about each major aspect of the code, and put their heads together on what the ideal architecture would be. But rather than building it from scratch, figure out how to implement just one of those pieces now. That way you can decrease entropy in the codebase piecemeal without chucking out all the code at once, which is no doubt full of forgotten assumptions that no one will remember until it's too late.

MartinCron 16y ago

I would advocate an incremental rewrite of parts of the unmaintainable spaghetti classic asp until there's none of the spaghetti left. It's easier to rewrite part of a system than an entire system. Release to production dozens, if not hundreds of times. Releases are non-events, rollbacks are non-events. A system-wide ground-up rewrite with a big-bang switchover at the end is a classic clusterfuck recipe. It's a shame that so many people think it's a good idea, even in 2010.

davidw 16y ago
> incremental rewrite of parts of the unmaintainable spaghetti classic Sounds good in theory. In practice? Part of the problem with many big ball of mud systems is that all the parts depend on and talk to all the other parts. Want to fix that horrid DB schema? You'll have to rewrite all the code that talks to it, or rewrite it to talk to an intermediary. Want to rewrite that horrid bit of code that's called foobar_20040623 ("foobar" has been changed, but yes, I saw this in some PHP code...), you'll have to find out what all it interacts with, and likely redo that too.
- rwmj 16y ago
  In reality yes, it works, I've done it. We took a horrible, accreted web application, and rewrote it in stages over a period of about 12 months. At the same time we were making regular releases, and needless to say the site stayed up the whole time. You just have to plan things carefully, work hard, and keep your head screwed on. (Just like with many things in life ...)
  - davidw 16y ago
    This would make a great topic for blogs/books/whatever. "How to dig yourself out of a pile of shit."
    - MartinCron 16y ago
      I agree, although it's a somewhat sensitive thing to write about if you're doing it in practice. I sure as hell don't want to be known as the guy who comes in and calls all of the existing code a pile of shit. I guess I could "change the names to protect the innocent" and tell some stories about digging out of tight places incrementally. If it would convince even one development team that they didn't absolutely have to do a total rewrite, it would be worth it.
- MartinCron 16y ago
  In practice? It's not easy, but nothing is. I see three options to the big ball of mud problem. 1. Wallow in it (work with existing structure). Sadly, this is what a lot of people do. I left a job once because that was the only way out of the ball of mud. I was afraid I would turn into a mud-person. 2. Slowly crawl out of it (incremental rewrite). This is hard, but do-able. It involves setting up barriers to mitigate ripple effects, automated testing to be comfortable with frequent releases, and tolerance for temporary imperfection (basically, you need to be willing to frequently release things that are only a tiny bit better than status quo, even if it's not ideal). Not everyone is willing to accept this persistent imperfection and lack of conceptual consistency, especially when option #3 is more exciting and fun. 3. Try to leap out of it and land wherever (total rewrite). This is very, very hard, and prone to total failure or spending valuable money and time to effectively stand still in the market. I've seen development teams leap directly out of one ball of mud into a different one. One where nobody even knew their way around anymore. How is that anything but a huge waste of time and resources?
zeemonkee 16y ago
Another issue is whether you are just rewriting the code, or fundamentally changing your data store (as Digg have done). Rewriting the code is fine - if it goes wrong, just back up to the old code, users won't notice the difference. You can do it on a page-by-page basis, just route URLs selectively to the new install. Migrating data is something that should be done under only the most extreme circumstances - and something will inevitably go horribly wrong, so be prepared to rollback.
- MartinCron 16y ago
  Because migration is a scenario that may go horribly wrong, you should be prepared to tackle it in small pieces. So often (especially with relational databases, I don't have much experience with the NoSQL realm) everything is in one logical and physical data store, even for non-related features. That makes any migration harder than it needs to be.

_delirium 16y ago

Microsoft could be one example of a successful one. Their flagship Windows codebase that ran the 3.1->95->98->ME line was basically ditched with the rewrite-from-scratch NT (famously done by an ex-VMS team), which later had some APIs ported to it to make Windows 2000 and especially XP be close to drop-in replacements for the old line, while not really sharing much code. I think in retrospect that was probably a good idea: the NT rewrite put the codebase on much better footing than the aging, incrementally updated classic Windows codebase had been. Solaris is another example of a rewrite that seems to have worked, though the rewrite did derive from a different set of existing code, not a total from-scratch job. But the classic SunOS 1.x.-4.x codebase was ditched, and SunOS 5.x / "Solaris 2" replaced it.

alabut 16y ago
You covered Windows and Linux - don't forget Apple's switch to OS X. They wouldn't done a wholesale switch at some point even if they hadn't gone with something unix-based because the other alternative was Copeland, the internal project to do a complete rewrite.
- alabut 16y ago
  EDIT: they would have made the switch. Stupid iPhone.
papaf 16y ago
Its a good point that NT was a successful rewrite. However, its worth noting how this was done. NT was originally aimed at a different market, there was a overlap of several years where the old system was still available AND NT ran Windows 3.1 apps in their own subsystem which contained .... the codebase of Windows 3.1.
rythie 16y ago
I think the NT and OSX updates were absolutely required due to architectural reasons which impact security, 98/ME and MacOS 9 just simply weren't suited to types of threats on the internet (no support for dropping process privileges, file permissions, cutting direct access to hardware etc.). If you think XP is bad in 2010, think what Me would be like if widely installed still, one program crashing the whole machine, boot sector viruses etc.

scorpion032 16y ago

but what if your application is a genuine ball of mud? Hello, Flash? (via Gruber)