7 ms·

They fell into the big rewrite trap ... possibly driven by developers hoping to clear out some cruft http://www.joelonsoftware.com/articles/fog0000000069.html

by damian2000 11y ago

They fell into the big rewrite trap ... possibly driven by developers hoping to clear out some cruft http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html

jayvanguard 11y ago
The article is dubious at best. You hear about the big failures or notice when rewrite releases take forever, but you never hear about the companies that slowly lose opportunities or fail to keep up with innovators because they keep trying patch a crappy codebase. Nor do you necessarily hear about the successful rewrites since they just happen under the covers.
- jerf 11y ago
  One of the major points of the Joel article is that the best option is usually one you didn't name; incrementally fix the "crappy" codebase. At no point do you do a "big rewrite", at no point do you have a big step back, at no point do you lose the ability to make forward progress because the new code isn't ready and the old code is deprecated, etc. Even if it may take somewhat longer to get there, the integral of value over time often still comes out larger for incremental improvement. Developers want the default answer to "abandon the old mess and write a new one" (snarkiness fully on purpose); Joel's point is that the default answer ought to be incremental improvement. Not that it's always the right answer, but other answers ought to be scrutinized more closely than developers might like. From a professional point of view, it's actually perfectly fair to consider that greenfielding a new project with hot new tech (or even "newer"-but-established tech, my personal favorite choice) is more fun than trudging through old code. Human factors matter a lot. But we are also professionally obligated not to overprivilege it. Besides, if you treat it as a serious project instead of a series of hack jobs, in my experience, very serious incremental improvement still offers a lot of engineering challenge and fun. I think one of the biggest mistakes people make is to prejudge incremental improvements as a hack job, when it becomes a self-fulfilling prophecy.
  - ebiester 11y ago
    Incrementally fixing the "crappy" codebase is great in some cases: Michael Feathers's book on rescuing legacy code is fantastic. However, the limit comes at the language barrier. Consider a COBOL codebase on a mainframe where you cannot find developers interested in learning the language and developing against the mainframe is convoluted -- you may not be able to pay talented people enough to toil in those coal mines, and you have to have to overpay subpar talent (or chase after the handful of expert mainframe COBOL developers.)
    - derefr 11y ago
      You can incrementally rewrite, just like you can incrementally refactor. Stick an API gateway in front of your COBOL mainframe that responds the same way it does, and then stand up a new well-architected service, microservice by microservice, that has a good API—and have the API gateway query the new service (using its nice API) whenever clients make calls to what they think is the legacy service, passing whatever calls you haven't re-implemented yet through to the legacy service. Eventually, everything will be on the new services, and you can shut down the legacy COBOL system and just keep the API gateway there to pretend. (If you can get clients switched over to consuming the new APIs directly, you can shut down the API gateway too—but good luck with that; their side probably has mainframes too.)
      - ebiester 11y ago
        It's called the strangler pattern by many. (You probably know that, but our dear reader may want to follow up.) It also assumes that you have a proper API to start. It assumes that you have the organizational maturity to handle synchronizing two separate systems and the distributed transactions that entails. The other problem not mentioned in the rewrite/refactor conversation is that the most common reason for rewrites is that the business has backed itself into a corner and the assumptions under the first system do not apply to where the business wants to go.
        jerf 11y ago
- EdSharkey 11y ago
  What you are saying sounds cavalier to me. Fact is, big rewrites are very risky and there's nothing appealing about working on them, I can attest! Any developer worth his salt should fight tooth and nail to kill such a rewrite project and then run screaming when business and management go forward anyhow with scrapping the working legacy system in order to "start fresh". Lost opportunity does suck. It would be nice if the first system was written in an extensible way with lots of tests and correct documentation, but it rarely is. All software needs to be replaced at some point. All software has a finite useful lifespan. So, this is a common problem. But you must have a responsible plan for replacing any first system. Any sort of project plan that has a magic day where the legacy system is shutdown and the second system is turned on is reckless and absurd. I've heard of failure rates for such projects being 80%, with the rest going way over budget before completion. The best you can do when replacing a crufty old system is to employ strangulation. You slowly, methodically kill off the legacy system one feature at a time with the equivalent features in the well-written/tested new system. You run both systems side by side, sharing the processing load until one day, years in the future, when you have replaced all the features and the legacy system has nothing to do. It's a hassle and it requires everyone to be organized from start to finish, but you eliminate the big-bang release risks. Luckily, with all the web services and factored out componentry we've been building in software over the past 10 years, the strangulation approach has never been more feasible. There's lots of good youtube lectures and agile community blog posts on the topic of second systems and strategies to implement the strangulation. Here's an old classic that introduces the concept better than I could: http://www.martinfowler.com/bliki/StranglerApplication.html http://www.martinfowler.com/bliki/StranglerApplication.html
pekk 11y ago
Yes, because the best way to make software is to eternally add more features to the same pile of code until it is impossible to get anything done.
- JBReefer 11y ago
  When my room is dirty, I clean it. When it's really dirty, I pay a professional to clean it. I don't burn my house down and start over.
  - maxsilver 11y ago
    And when your room is so dirty that there are bugs in the walls, termites eating the wood, the thermostat is leaking mercury, the ceiling is dropping lead paint + asbestos, and the foundation is cracked and pulling the house apart ... you burn your house down, and start over. As technology people, I agree that we lean far too heavily towards the "rewrite it" option than we should. But that doesn't mean it's never the right option.
    - JBReefer 11y ago
      I deeply get your point, but to step away from the metaphor, usually the problem of shitty code is a lack of focus on continual refinement instead of adding features, which is a management/process problem. If you have a serious problem with your process, you're never going to build a solid code base. Hell, at my last company, we have a big server product made of duct tape and spit, and about halfway through a total rebuild, we had another ball of spit and duct tape made of a slightly trendier stack. We added coders, we brought in front end guys, but guess who we didn't replace?
    - gutnor 11y ago
      Worse than that - if just the foundations are bad, you may have to start the house over. Even if the house is fine but you get the wrong type of mushroom in the wall of 1 room, the house will have to be rebuild. Strange analogy by GP, you have way more possibilities of fixing stuff in the software world than in the physical one.
bsg75 11y ago
Or perhaps by the chasing the universal / web view on the desktop unicorn. Native apps still best HTML frames on the desktop in terms of functionality, and no amount of cost savings for the vendor will convince users otherwise. Multiple code bases may be a pain, but they still produce better UIs when you support more than one OS.
- morgante 11y ago
  > Multiple code bases may be a pain, but they still produce better UIs when you support more than one OS. I don't know if that's universally true. Slack uses Electron for its desktop apps, yet has received a lot of acclaim for its UI and seems to be trouncing alternatives with truly native offerings (IRC, HipChat).
  - tluyben2 11y ago
    I do not really understand how Hipchat can be so bad though. The client is ghastly on all platforms and not being able to handle shaky internet connections these days is a joke.
  - sanderjd 11y ago
    I have always been surprised they get so much UI praise. To me, it feels like the HTML frame that it is, and often confounds my expectations of how a native app works. It is definitely better than its competitors, but that doesn't mean it's all that great. Having said that, it seems like they've wielded the web view approach to achieve a great flexibility and development speed advantage, so it's definitely a valid way of doing things. But I keep waiting for them to switch to full-native now that they're well established and can afford way more developers.
  - maccard 11y ago
    I'd hardly call slack the epitome of usability. It guzzles memory, is laggy on my workstation (Xeon cpu lots of ram and a high end gaming gpu), their search functionality is abysmal too. I quite like slack, but I really wish they would consider a native app, or even just address the performance problems of their chat client.

jayvanguard 11y ago

The article is dubious at best. You hear about the big failures or notice when rewrite releases take forever, but you never hear about the companies that slowly lose opportunities or fail to keep up with innovators because they keep trying patch a crappy codebase. Nor do you necessarily hear about the successful rewrites since they just happen under the covers.

jerf 11y ago
One of the major points of the Joel article is that the best option is usually one you didn't name; incrementally fix the "crappy" codebase. At no point do you do a "big rewrite", at no point do you have a big step back, at no point do you lose the ability to make forward progress because the new code isn't ready and the old code is deprecated, etc. Even if it may take somewhat longer to get there, the integral of value over time often still comes out larger for incremental improvement. Developers want the default answer to "abandon the old mess and write a new one" (snarkiness fully on purpose); Joel's point is that the default answer ought to be incremental improvement. Not that it's always the right answer, but other answers ought to be scrutinized more closely than developers might like. From a professional point of view, it's actually perfectly fair to consider that greenfielding a new project with hot new tech (or even "newer"-but-established tech, my personal favorite choice) is more fun than trudging through old code. Human factors matter a lot. But we are also professionally obligated not to overprivilege it. Besides, if you treat it as a serious project instead of a series of hack jobs, in my experience, very serious incremental improvement still offers a lot of engineering challenge and fun. I think one of the biggest mistakes people make is to prejudge incremental improvements as a hack job, when it becomes a self-fulfilling prophecy.
- ebiester 11y ago
  Incrementally fixing the "crappy" codebase is great in some cases: Michael Feathers's book on rescuing legacy code is fantastic. However, the limit comes at the language barrier. Consider a COBOL codebase on a mainframe where you cannot find developers interested in learning the language and developing against the mainframe is convoluted -- you may not be able to pay talented people enough to toil in those coal mines, and you have to have to overpay subpar talent (or chase after the handful of expert mainframe COBOL developers.)
  - derefr 11y ago
    You can incrementally rewrite, just like you can incrementally refactor. Stick an API gateway in front of your COBOL mainframe that responds the same way it does, and then stand up a new well-architected service, microservice by microservice, that has a good API—and have the API gateway query the new service (using its nice API) whenever clients make calls to what they think is the legacy service, passing whatever calls you haven't re-implemented yet through to the legacy service. Eventually, everything will be on the new services, and you can shut down the legacy COBOL system and just keep the API gateway there to pretend. (If you can get clients switched over to consuming the new APIs directly, you can shut down the API gateway too—but good luck with that; their side probably has mainframes too.)
    - ebiester 11y ago
      It's called the strangler pattern by many. (You probably know that, but our dear reader may want to follow up.) It also assumes that you have a proper API to start. It assumes that you have the organizational maturity to handle synchronizing two separate systems and the distributed transactions that entails. The other problem not mentioned in the rewrite/refactor conversation is that the most common reason for rewrites is that the business has backed itself into a corner and the assumptions under the first system do not apply to where the business wants to go.
      - jerf 11y ago
EdSharkey 11y ago
What you are saying sounds cavalier to me. Fact is, big rewrites are very risky and there's nothing appealing about working on them, I can attest! Any developer worth his salt should fight tooth and nail to kill such a rewrite project and then run screaming when business and management go forward anyhow with scrapping the working legacy system in order to "start fresh". Lost opportunity does suck. It would be nice if the first system was written in an extensible way with lots of tests and correct documentation, but it rarely is. All software needs to be replaced at some point. All software has a finite useful lifespan. So, this is a common problem. But you must have a responsible plan for replacing any first system. Any sort of project plan that has a magic day where the legacy system is shutdown and the second system is turned on is reckless and absurd. I've heard of failure rates for such projects being 80%, with the rest going way over budget before completion. The best you can do when replacing a crufty old system is to employ strangulation. You slowly, methodically kill off the legacy system one feature at a time with the equivalent features in the well-written/tested new system. You run both systems side by side, sharing the processing load until one day, years in the future, when you have replaced all the features and the legacy system has nothing to do. It's a hassle and it requires everyone to be organized from start to finish, but you eliminate the big-bang release risks. Luckily, with all the web services and factored out componentry we've been building in software over the past 10 years, the strangulation approach has never been more feasible. There's lots of good youtube lectures and agile community blog posts on the topic of second systems and strategies to implement the strangulation. Here's an old classic that introduces the concept better than I could: http://www.martinfowler.com/bliki/StranglerApplication.html http://www.martinfowler.com/bliki/StranglerApplication.html

pekk 11y ago

Yes, because the best way to make software is to eternally add more features to the same pile of code until it is impossible to get anything done.

JBReefer 11y ago
When my room is dirty, I clean it. When it's really dirty, I pay a professional to clean it. I don't burn my house down and start over.
- maxsilver 11y ago
  And when your room is so dirty that there are bugs in the walls, termites eating the wood, the thermostat is leaking mercury, the ceiling is dropping lead paint + asbestos, and the foundation is cracked and pulling the house apart ... you burn your house down, and start over. As technology people, I agree that we lean far too heavily towards the "rewrite it" option than we should. But that doesn't mean it's never the right option.
  - JBReefer 11y ago
    I deeply get your point, but to step away from the metaphor, usually the problem of shitty code is a lack of focus on continual refinement instead of adding features, which is a management/process problem. If you have a serious problem with your process, you're never going to build a solid code base. Hell, at my last company, we have a big server product made of duct tape and spit, and about halfway through a total rebuild, we had another ball of spit and duct tape made of a slightly trendier stack. We added coders, we brought in front end guys, but guess who we didn't replace?
  - gutnor 11y ago
    Worse than that - if just the foundations are bad, you may have to start the house over. Even if the house is fine but you get the wrong type of mushroom in the wall of 1 room, the house will have to be rebuild. Strange analogy by GP, you have way more possibilities of fixing stuff in the software world than in the physical one.

bsg75 11y ago

Or perhaps by the chasing the universal / web view on the desktop unicorn. Native apps still best HTML frames on the desktop in terms of functionality, and no amount of cost savings for the vendor will convince users otherwise. Multiple code bases may be a pain, but they still produce better UIs when you support more than one OS.

morgante 11y ago
> Multiple code bases may be a pain, but they still produce better UIs when you support more than one OS. I don't know if that's universally true. Slack uses Electron for its desktop apps, yet has received a lot of acclaim for its UI and seems to be trouncing alternatives with truly native offerings (IRC, HipChat).
- tluyben2 11y ago
  I do not really understand how Hipchat can be so bad though. The client is ghastly on all platforms and not being able to handle shaky internet connections these days is a joke.
- sanderjd 11y ago
  I have always been surprised they get so much UI praise. To me, it feels like the HTML frame that it is, and often confounds my expectations of how a native app works. It is definitely better than its competitors, but that doesn't mean it's all that great. Having said that, it seems like they've wielded the web view approach to achieve a great flexibility and development speed advantage, so it's definitely a valid way of doing things. But I keep waiting for them to switch to full-native now that they're well established and can afford way more developers.
- maccard 11y ago
  I'd hardly call slack the epitome of usability. It guzzles memory, is laggy on my workstation (Xeon cpu lots of ram and a high end gaming gpu), their search functionality is abysmal too. I quite like slack, but I really wish they would consider a native app, or even just address the performance problems of their chat client.