July 21, 2016 at 3:22 pm
Fred P Brooks wrote a paper called "The 2nd system affect". It's worth reviewing it.
The problem with a rewrite is that identifying the true scope and therefore the costs involved and likely timescales is nigh on impossible. There is a fractal affect in IT.
If a system is a convoluted mess then the dependencies on that system will be a convoluted mess. Short of getting agreement for a scorched earth policy the risks are immense. This is especially because people massively underestimate the dependencies and the people and processes affected.
July 21, 2016 at 3:29 pm
Steve Jones - SSC Editor (7/21/2016)
Stephanie Giovannini (7/21/2016)
I don't understand why code re-writes cause so much fear, both among developers and management. It's the code equivalent of cleaning out the basement by emptying it, scrubbing it clean, re-painting the walls, and then putting back only what belongs there, cleaned-up and reorganized.A code re-write is so much easier than writing a completely new application. Sometimes the original application is marked all over by the issues that arose during its development. I've rarely found a business group that is able to coherently explain requirements. The business almost needs to be provided with a completed application before they can say, "You gave us X but we wanted Y." The back-and-forth that happens during initial development, especially under a tight schedule, can leave "scars" all over the first-deployed application, even with competent development. After some years of real-world experience in the application--it's time for a re-write.
The code re-write has the benefit of comprehensive requirements. The requirements are: do what the application already does, minus the bugs (both known and discovered during code analysis), plus the feature requests. This requires excruciatingly detailed code analysis, but it's quite doable (and enjoyable IMO). With the requirements extracted, an architecture can be designed up-front that matches the real requirements and the real performance profile (gathered from experience). Coding proceeds smoothly and much more quickly than initial development with the big picture fully defined. The re-write simply doesn't have the risk profile that an initial app does.
I've lost count of how much I've re-written in my career. There certainly are cases where a re-write is the wrong approach, or has to be done incrementally. But when I get management approval for a much-needed re-write, I'm a happy camper, that's for sure.
I agree. In fact, if you have experience, I saw a study once that showed you'll write the code the second time around 50% faster, it will be tighter, and have fewer bugs. I wish I could find that again.
This is the game I like to play; the current aspx.net monster I somehow inherited a few months after joining, I am gradually rewriting to a decent 3-tier mvc app - as I previous said, it does delay every change, but delivering some of the little-but-important updates to the users, keeping them informed, involving them and making them feel valued has bought me some leeway. It has also removed it from the top of the list of RAD [outsystems] redevelopments (I think this is a good thing...).
Redevelopment from scratch, usually in another more trendy tech, has a massive element of risk, and often the project fails completely (not helped when it is outsourced). Reworking it, bit by bit, testing and delivering it as you go, means there's always a working version, the user feels that it's progressing, and the whole thing is less likely to be scrapped and some kind of off-the-shelf product brought in/customised instead.
Steve Jones - SSC Editor (7/21/2016)
There's an argument there to say that you should have developer prototype things quickly, then trash the prototype and rewrite from scratch right away.
Back in the days when developing a prototype first was more common, the thing we found was, no-one would ever throw that prototype away! Always, it was rewritten, then partially redesigned, and ended up as spaghetti, but still it would be there, like a zombie or unwelcome guest...
July 22, 2016 at 1:19 am
Stephanie Giovannini (7/21/2016)
I don't understand why code re-writes cause so much fear, both among developers and management. It's the code equivalent of cleaning out the basement by emptying it, scrubbing it clean, re-painting the walls, and then putting back only what belongs there, cleaned-up and reorganized.A code re-write is so much easier than writing a completely new application. Sometimes the original application is marked all over by the issues that arose during its development. I've rarely found a business group that is able to coherently explain requirements. The business almost needs to be provided with a completed application before they can say, "You gave us X but we wanted Y." The back-and-forth that happens during initial development, especially under a tight schedule, can leave "scars" all over the first-deployed application, even with competent development. After some years of real-world experience in the application--it's time for a re-write.
The code re-write has the benefit of comprehensive requirements. The requirements are: do what the application already does, minus the bugs (both known and discovered during code analysis), plus the feature requests. This requires excruciatingly detailed code analysis, but it's quite doable (and enjoyable IMO). With the requirements extracted, an architecture can be designed up-front that matches the real requirements and the real performance profile (gathered from experience). Coding proceeds smoothly and much more quickly than initial development with the big picture fully defined. The re-write simply doesn't have the risk profile that an initial app does.
I've lost count of how much I've re-written in my career. There certainly are cases where a re-write is the wrong approach, or has to be done incrementally. But when I get management approval for a much-needed re-write, I'm a happy camper, that's for sure.
I'm sure we would all love to do what you suggest. The problem is with incremental re-writes they have habit of not being followed through on and so you end up with a partly rewritten app and thus a bigger mess.
When I started reading this comment I thought "mwhahahahahaha", but then you reigned it back at the end.
Your basement analogy in my book doesn't work because a) in an app of any real world size you don't know all the requirements and if it's been going long enough you'll either have a rainforest of requirement docs or worse none or the functionality started like the doc but over time has been tweaked significantly, b) rewrite it to do the same as what it does now but without bugs and better - that is the real LOL. The problem is typically what it does now is probably a accumulation of hacks due to time pressure but now that users have gotten use to it working that way if you make it "better" inevitable that will mean "different" and then you are screwed because although it is better from a technical perspective users don't care about that it's different from before and then you get pressured to improve it, read mess it up again under time pressures.
July 22, 2016 at 8:39 am
Stephanie Giovannini (7/21/2016)
I don't understand why code re-writes cause so much fear, both among developers and management. It's the code equivalent of cleaning out the basement by emptying it, scrubbing it clean, re-painting the walls, and then putting back only what belongs there, cleaned-up and reorganized.A code re-write is so much easier than writing a completely new application. Sometimes the original application is marked all over by the issues that arose during its development. I've rarely found a business group that is able to coherently explain requirements. The business almost needs to be provided with a completed application before they can say, "You gave us X but we wanted Y." The back-and-forth that happens during initial development, especially under a tight schedule, can leave "scars" all over the first-deployed application, even with competent development. After some years of real-world experience in the application--it's time for a re-write.
The code re-write has the benefit of comprehensive requirements. The requirements are: do what the application already does, minus the bugs (both known and discovered during code analysis), plus the feature requests. This requires excruciatingly detailed code analysis, but it's quite doable (and enjoyable IMO). With the requirements extracted, an architecture can be designed up-front that matches the real requirements and the real performance profile (gathered from experience). Coding proceeds smoothly and much more quickly than initial development with the big picture fully defined. The re-write simply doesn't have the risk profile that an initial app does.
I've lost count of how much I've re-written in my career. There certainly are cases where a re-write is the wrong approach, or has to be done incrementally. But when I get management approval for a much-needed re-write, I'm a happy camper, that's for sure.
I agree with you, but speaking only for myself, getting management sign-off on re-writing software is very hard.
Kindest Regards, Rod Connect with me on LinkedIn.
July 22, 2016 at 2:05 pm
Rod at work (7/22/2016)
Stephanie Giovannini (7/21/2016)
I don't understand why code re-writes cause so much fear, both among developers and management. It's the code equivalent of cleaning out the basement by emptying it, scrubbing it clean, re-painting the walls, and then putting back only what belongs there, cleaned-up and reorganized.A code re-write is so much easier than writing a completely new application. Sometimes the original application is marked all over by the issues that arose during its development. I've rarely found a business group that is able to coherently explain requirements. The business almost needs to be provided with a completed application before they can say, "You gave us X but we wanted Y." The back-and-forth that happens during initial development, especially under a tight schedule, can leave "scars" all over the first-deployed application, even with competent development. After some years of real-world experience in the application--it's time for a re-write.
The code re-write has the benefit of comprehensive requirements. The requirements are: do what the application already does, minus the bugs (both known and discovered during code analysis), plus the feature requests. This requires excruciatingly detailed code analysis, but it's quite doable (and enjoyable IMO). With the requirements extracted, an architecture can be designed up-front that matches the real requirements and the real performance profile (gathered from experience). Coding proceeds smoothly and much more quickly than initial development with the big picture fully defined. The re-write simply doesn't have the risk profile that an initial app does.
I've lost count of how much I've re-written in my career. There certainly are cases where a re-write is the wrong approach, or has to be done incrementally. But when I get management approval for a much-needed re-write, I'm a happy camper, that's for sure.
I agree with you, but speaking only for myself, getting management sign-off on re-writing software is very hard.
Yes, it's hard and it's been getting harder over the years. It was SO MUCH easier to get approval back in the 90s! (I know some of you were babies then... no need to remind me).
The easiest sign-off I ever received was from managers who were all electrical engineers. They contracted me to add significant features to an old manufacturing system. After taking a look at the code (yikes), I decided to go for the re-write. I had prepared a half-hour presentation selling the "rewrite" case and they agreed after 5 minutes!
I've had a number of "lone wolf" contract assignments in which I was the sole developer with no "IT" oversight. (I would use the term "cowboy coder" but that's taken on the meaning of someone who ignores best practices because they can, and that's not necessarily true of a sole developer). I had a lot of freedom in those positions. My job was to "make it work." Ah, the good old days... I'm spoiled now by having colleagues, an actual desk in an office, paid vacation, you know...
July 25, 2016 at 3:35 pm
The idea of making changes doesn't scare me at all, and shouldn't scare any competent developer or DBA.
The idea of trying to make changes without the resources that are clearly needed to make them successfully puts me into a stubborn mode where I won't start the changes unless/until the resourcing is sorted out. Maybe some people are scared of benig stubborn in that situation? Maybe they feel that there's a requirement to do the impossible and that makes them scared and whatever they do will be wrong, and that gets them scared. When management is insisting on change but refusing to budget for doing it the people under those managers could reasonably think that they are in a rather unpleasant situation: they can refuse to attempt the changes, which may get them sacked (it never got me sacked, although I did it a few times); or they can start trying to do the changes, which probably will get them sacked if they don't jump ship before it all turns into a disaster.
Tom
October 11, 2016 at 2:19 am
Steve Jones - SSC Editor (7/21/2016)
...There's an argument there to say that you should have developer prototype things quickly, then trash the prototype and rewrite from scratch right away.
I also am more of a fan of the throwaway prototype over the evolutionary prototype too.
The problem with evolutionary prototypes is that as soon as some of it looks functional you hear calls to ship it. This is one of the reasons that Agile can work. Each iteration ends up with a partially implemented, but working, system. The state of play is kept transparant thus avoiding the nightmare scenario when "smoke 'n' mirrors" are deployed leading to stakeholders believing that it is complete.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 11, 2016 at 2:34 am
I was once brought in to recover a system whose development team had left en masse and what was in the source control system was not what was live. Over a million lines of code. I was not even familiar with every part of the stack.
I was the only person who was interviewed for the task and who both was offered the role and accepted it (some people didn't fancy the challenge). It was a major challenge. There were plenty of flaws - as in any reasonably complex system. My client's client (the users of the system) had some urgent updates needed to meet their business requirement.
The first deployment of that fixed system was scary. It should have been. It was a huge and complicated task that was core to the business (a UK national coach company - this was their fare calculation engine).
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 8 posts - 31 through 37 (of 37 total)
You must be logged in to reply to this topic. Login to reply