5 ms·

The OP has so many reasonable, smart-sounding advice that doesn't work in the real world. 1) "Do not fall into the trap of improving both the maintainability o

The OP has so many reasonable, smart-sounding advice that doesn't work in the real world. 1) "Do not fall into the trap of improving both the maintainability of the code or the platform it runs on at the same time as adding new features or fixing bugs." Thanks. However, in many situations this is simply not possible because the business is not there yet so you need to keep adding new features and fix bugs. And still, the code base has to be improved. Impossible? Almost, but we're paid for solving hard problems. 2) "Before you make any changes at all write as many end-to-end and integration tests as you can." Sounds cool, except in many cases you have no idea how the code is supposed to work. Writing tests for new features and bugfixes is a good advice (but that goes against other points the OP makes). 3) "A big-bang rewrite is the kind of project that is pretty much guaranteed to fail. No, it's not. Especially if you're rewriting parts of it at a time as separate modules My problem with the OP is really that it tells you how to improve a legacy codebase given no business and time pressure.

thehardsphere 9y ago
>3) "A big-bang rewrite is the kind of project that is pretty much guaranteed to fail. >No, it's not. Especially if you're rewriting parts of it at a time as separate modules I guess it depends on what he considers to be a "big bang rewrite." I don't think any of the incremental approach you mention counts as one.
- MaulingMonkey 9y ago
  My preferred definition here, is that a big bang rewrite is a monolithic rewrite so big it goes bang (fails), pushing things from "pretty much guaranteed to fail", to "is by definition a failure". You might end up rewriting the entire codebase through an incremental approach ala the Ship of Theseus through a series of smaller rewrites, but that's something very different and distinct from a "big bang rewrite" to me.
jacquesm 9y ago
On the contrary, we do this work under extreme business and time pressure, sometimes existential pressure (as in: fail and the company fails). That's exactly why this list is set up the way it is: you will get results fast and they will be good results. If you want to play the 'I'm doing a sloppy job because I'm under pressure' card then consider this: the more pressure the less room there is for mistakes. Here is a much more play-by-play account of one of these jobs where management gave me permission to do a write-up as part of the deal: https://jacquesmattheij.com/saving-a-project-and-a-company https://jacquesmattheij.com/saving-a-project-and-a-company (For obvious reasons management usually does not give such permission, nobody wants to admit they let it get that far on their watch, I did my best to obscure which company this is about.)
- sz4kerto 9y ago
  > That's exactly why this list is set up the way it is: you will get results fast and they will be good results. What do you mean by 'fast'? If you can get meaningful improvements in a few months' time, then you're just working with smaller code base than what I thought of. If you're talking about stopping for a year, then .. well, that's the problem I'm talking about. > If you want to play the 'I'm doing a sloppy job because I'm under pressure' card No, I just wanted to share my opinion that I disagree with the overly generalized suggestions you're making.
  - jacquesm 9y ago
    > What do you mean by 'fast'? Much faster than by going the rewrite route (assuming that is even possible, which I am convinced for anything but the most trivial problems it isn't). Preferably to first deploy within a few days and incremental changeover to the new situation starting within two weeks or so of the starting gun being fired. > If you can get meaningful improvements in a few months' time, then you're just working with smaller code base than what I thought of. No. > If you're talking about stopping for a year, then .. well, that's the problem I'm talking about. Who said so? All I said is that you should only do one thing at a time. Do not attempt to achieve two results with one release. > No, I just wanted to share my opinion that I disagree with the overly generalized suggestions you're making. You are very welcome to your own opinion about my 'overly generalized suggestions' it's just that they are a lot more than suggestions, they are things that I (and others, see this thread for evidence) have used countless times and that simply work. All you do is a bunch of naysaying without offering up anything concrete as an alternative that would work better or evidence that anything posted would not work in practice. It does and it pays my bills.
    - alexwebb2 9y ago
      > > What do you mean by 'fast'? > deploy within a few days and incremental changeover to the new situation starting within two weeks or so I'm going to take this as confirmation that you're working on very, very small projects. This would be an extraordinarily unrealistic timeframe for large projects, which take vastly larger quantities of time to apply the steps you've outlined - which, in turn, renders those steps useless in a competitive business context as far as large applications are concerned.
anilshanbhag 9y ago
While the advice sounds cool, doing one feature at a time is often impractical. I recently moved an old app with spaghetti Jquery to Vue. The paradigm is completely different. What ended up happening is I had a base that worked, moved a set of features at a time from the old to the new. This is more like rebuilding the git history from a new base compared to doing incremental one change at a time that the article advocates.
hacker_9 9y ago
But.. all these things do work in the real world. Keeping refactorings to a separate commit is important as when you break something, you can just roll it back. Countless times I've seen new people come in and try refactoring things to their liking as they work on some other feature. Then when it later breaks some component they didn't know about, we have to unpick their commit and manually separate out the crap 'refactoring' they did and the actual feature they were working on. End to end tests are great to test the system actually works as expected as per the requirements spec. You should know how to write this, else.. how are you even testing your feature to begin with after you've written it? And big rewrites always take longer than people think, which can sink a business if they're not careful with their resources and don't manage their time appropriately. All in all, these points you've mentioned all seem actually very reasonable to me.
pc86 9y ago
A "big-bang rewrite" means rewriting the entire app from scratch. So if you're rewriting pieces as modules you are by definition not doing a big-bang rewrite.
hinkley 9y ago
#1 is just refactoring. Make the change simple, then make the simple change. They only know it took you three days to implement the feature. They don't need to know how you spent the first 2 days. Paying down that debt allows the team to scale larger and maintain velocity longer. If they don't like your rate of delivery now, how are they going to like it when the code calcifies and everything takes twice as long?
indogooner 9y ago
I can vouch that the approach suggested by OP works from my own experience. Incremental refactoring backed by confidence of safety-nets (tests and ability to fast-fail and revert) helped us stabilize a legacy codebase and then improve it. Depending on how bad the state of code is, adding new features may be even accelerated by minor refactoring. I would argue that is you do not have idea about how the codebase works adding new features without breaking anything else is going to be sheer luck most of the times.
- jacquesm 9y ago
  That's ok, we'll be more than happy to charge his boss $something terrible K/month per person to bail them out at some point :)
  - sz4kerto 9y ago
    Nah, that's condescending, really. We might have different experience because of the codebases we've worked with; but I don't think there's a need for this kind of sarcasm.
    - jacquesm 9y ago
      Well, I've been in this line of business for 30+ years, if you think there is some aspect of it that you structurally encounter that I don't then I'm all ears. Keep in mind that almost everybody that we end up cleaning up after has the exact attitude that you display and the only reason they feel that way is because they leave before the bill is due. I don't mind, it keeps me employed.
      - sz4kerto 9y ago
        Ad hominem and appeal to authority are not the best way to argue about technology, so let's leave this. (It feels really odd that someone tells me that he's making a living after cleaning up after people like me while so far I've thought I am paid for scaling small, poorly written systems up to enterprise levels, but well. I'd have appreciated more if we could have talked about specifics instead of "this works because I know it works").
tspike 9y ago
We used the same strategy OP describes to bring a legacy emergency firefighter dispatch system under control and it worked well.

thehardsphere 9y ago

>3) "A big-bang rewrite is the kind of project that is pretty much guaranteed to fail. >No, it's not. Especially if you're rewriting parts of it at a time as separate modules I guess it depends on what he considers to be a "big bang rewrite." I don't think any of the incremental approach you mention counts as one.

MaulingMonkey 9y ago
My preferred definition here, is that a big bang rewrite is a monolithic rewrite so big it goes bang (fails), pushing things from "pretty much guaranteed to fail", to "is by definition a failure". You might end up rewriting the entire codebase through an incremental approach ala the Ship of Theseus through a series of smaller rewrites, but that's something very different and distinct from a "big bang rewrite" to me.

jacquesm 9y ago

On the contrary, we do this work under extreme business and time pressure, sometimes existential pressure (as in: fail and the company fails). That's exactly why this list is set up the way it is: you will get results fast and they will be good results. If you want to play the 'I'm doing a sloppy job because I'm under pressure' card then consider this: the more pressure the less room there is for mistakes. Here is a much more play-by-play account of one of these jobs where management gave me permission to do a write-up as part of the deal: https://jacquesmattheij.com/saving-a-project-and-a-company https://jacquesmattheij.com/saving-a-project-and-a-company (For obvious reasons management usually does not give such permission, nobody wants to admit they let it get that far on their watch, I did my best to obscure which company this is about.)

sz4kerto 9y ago
> That's exactly why this list is set up the way it is: you will get results fast and they will be good results. What do you mean by 'fast'? If you can get meaningful improvements in a few months' time, then you're just working with smaller code base than what I thought of. If you're talking about stopping for a year, then .. well, that's the problem I'm talking about. > If you want to play the 'I'm doing a sloppy job because I'm under pressure' card No, I just wanted to share my opinion that I disagree with the overly generalized suggestions you're making.
- jacquesm 9y ago
  > What do you mean by 'fast'? Much faster than by going the rewrite route (assuming that is even possible, which I am convinced for anything but the most trivial problems it isn't). Preferably to first deploy within a few days and incremental changeover to the new situation starting within two weeks or so of the starting gun being fired. > If you can get meaningful improvements in a few months' time, then you're just working with smaller code base than what I thought of. No. > If you're talking about stopping for a year, then .. well, that's the problem I'm talking about. Who said so? All I said is that you should only do one thing at a time. Do not attempt to achieve two results with one release. > No, I just wanted to share my opinion that I disagree with the overly generalized suggestions you're making. You are very welcome to your own opinion about my 'overly generalized suggestions' it's just that they are a lot more than suggestions, they are things that I (and others, see this thread for evidence) have used countless times and that simply work. All you do is a bunch of naysaying without offering up anything concrete as an alternative that would work better or evidence that anything posted would not work in practice. It does and it pays my bills.
  - alexwebb2 9y ago
    > > What do you mean by 'fast'? > deploy within a few days and incremental changeover to the new situation starting within two weeks or so I'm going to take this as confirmation that you're working on very, very small projects. This would be an extraordinarily unrealistic timeframe for large projects, which take vastly larger quantities of time to apply the steps you've outlined - which, in turn, renders those steps useless in a competitive business context as far as large applications are concerned.

anilshanbhag 9y ago

While the advice sounds cool, doing one feature at a time is often impractical. I recently moved an old app with spaghetti Jquery to Vue. The paradigm is completely different. What ended up happening is I had a base that worked, moved a set of features at a time from the old to the new. This is more like rebuilding the git history from a new base compared to doing incremental one change at a time that the article advocates.

hacker_9 9y ago

But.. all these things do work in the real world. Keeping refactorings to a separate commit is important as when you break something, you can just roll it back. Countless times I've seen new people come in and try refactoring things to their liking as they work on some other feature. Then when it later breaks some component they didn't know about, we have to unpick their commit and manually separate out the crap 'refactoring' they did and the actual feature they were working on. End to end tests are great to test the system actually works as expected as per the requirements spec. You should know how to write this, else.. how are you even testing your feature to begin with after you've written it? And big rewrites always take longer than people think, which can sink a business if they're not careful with their resources and don't manage their time appropriately. All in all, these points you've mentioned all seem actually very reasonable to me.

pc86 9y ago

A "big-bang rewrite" means rewriting the entire app from scratch. So if you're rewriting pieces as modules you are by definition not doing a big-bang rewrite.

hinkley 9y ago

#1 is just refactoring. Make the change simple, then make the simple change. They only know it took you three days to implement the feature. They don't need to know how you spent the first 2 days. Paying down that debt allows the team to scale larger and maintain velocity longer. If they don't like your rate of delivery now, how are they going to like it when the code calcifies and everything takes twice as long?

indogooner 9y ago

I can vouch that the approach suggested by OP works from my own experience. Incremental refactoring backed by confidence of safety-nets (tests and ability to fast-fail and revert) helped us stabilize a legacy codebase and then improve it. Depending on how bad the state of code is, adding new features may be even accelerated by minor refactoring. I would argue that is you do not have idea about how the codebase works adding new features without breaking anything else is going to be sheer luck most of the times.

jacquesm 9y ago
That's ok, we'll be more than happy to charge his boss $something terrible K/month per person to bail them out at some point :)
- sz4kerto 9y ago
  Nah, that's condescending, really. We might have different experience because of the codebases we've worked with; but I don't think there's a need for this kind of sarcasm.
  - jacquesm 9y ago
    Well, I've been in this line of business for 30+ years, if you think there is some aspect of it that you structurally encounter that I don't then I'm all ears. Keep in mind that almost everybody that we end up cleaning up after has the exact attitude that you display and the only reason they feel that way is because they leave before the bill is due. I don't mind, it keeps me employed.
    - sz4kerto 9y ago
      Ad hominem and appeal to authority are not the best way to argue about technology, so let's leave this. (It feels really odd that someone tells me that he's making a living after cleaning up after people like me while so far I've thought I am paid for scaling small, poorly written systems up to enterprise levels, but well. I'd have appreciated more if we could have talked about specifics instead of "this works because I know it works").

tspike 9y ago

We used the same strategy OP describes to bring a legacy emergency firefighter dispatch system under control and it worked well.