Start from scratch?
-
I'm working on a fairly big project, and like always it has its legacy code. Unfortunately it's based on legacy code of about a year's work by somebody that was not great at (.NET) programming, let alone architecting and designing it. The whole thing is currently operational, but it's not structurally sound. The pricing structure in the application hard to understand, and has its flaws. The database and web service design are just in the state that things work most of the time, but they have their issues and the design is not good. So the dilemma is, should we start from scratch? I've been telling the company's president that hires me, not to do that, that it would be the biggest mistake ever. The reasoning being taking smaller steps towards a sound structure involves much and much less risk, and we can still gradually move towards this goal. I also read a really good blog note by Joel ("Things you should never do, part I"[^]), confirming my views on not starting from scratch. So I'm wondering, have any of you guys thrown away the existing stuff (reasonably sized project) and started from scratch? What has been your success/fail ratio on this approach? I'm still resisting the urge to start from scratch, it seems so appealing when working with the crappy code.
Wout
Like anything it's whatever is appropriate to the situation. The only major project I redid from scratch is a very large commercial application we built and had been selling for many years. It was originally written in mfc / c++ and when it came time to add a lot of new features for a major new version I decided that it was better done in .net and so then had the opportunity to redo it from scratch. In your case it really depends on how messed up the original one is, but I disagree with Joel in that there are definitely times when it makes more sense to redo from scratch, but in your case it really depends on how messed up the original is.
-
Like anything it's whatever is appropriate to the situation. The only major project I redid from scratch is a very large commercial application we built and had been selling for many years. It was originally written in mfc / c++ and when it came time to add a lot of new features for a major new version I decided that it was better done in .net and so then had the opportunity to redo it from scratch. In your case it really depends on how messed up the original one is, but I disagree with Joel in that there are definitely times when it makes more sense to redo from scratch, but in your case it really depends on how messed up the original is.
We're in .NET 2.0, IIS 6, SQL server 2000. In all honesty, there's not a single problem I don't think we can restructure in at most 2 weeks time. Though it feels shitty, it is probably the best path to progress. Actually I'd be pretty happy when we can release an improved version every 2 weeks. On most items we can probably release quicker.
Wout
-
wout de zeeuw wrote:
I also read a really good blog note by Joel ("Things you should never do, part I"[^]), confirming my views on not starting from scratch.
Another one worth reading, IMHO is The Big Rewrite.[^]
Ah, pretty good one too (though I always find Joel's reasoning very clean cut).
Wout
-
We're in .NET 2.0, IIS 6, SQL server 2000. In all honesty, there's not a single problem I don't think we can restructure in at most 2 weeks time. Though it feels shitty, it is probably the best path to progress. Actually I'd be pretty happy when we can release an improved version every 2 weeks. On most items we can probably release quicker.
Wout
Well that sounds like an incremental approach should be taken then. To me the only showstopper that would prompt a re-write in your case is if the app was not properly stratified in it's design with the UI layer being separated cleanly from the actual guts of the program in another layer below. I would never work with a monolithic design ever again, that way lies madness. :)
-
I'm working on a fairly big project, and like always it has its legacy code. Unfortunately it's based on legacy code of about a year's work by somebody that was not great at (.NET) programming, let alone architecting and designing it. The whole thing is currently operational, but it's not structurally sound. The pricing structure in the application hard to understand, and has its flaws. The database and web service design are just in the state that things work most of the time, but they have their issues and the design is not good. So the dilemma is, should we start from scratch? I've been telling the company's president that hires me, not to do that, that it would be the biggest mistake ever. The reasoning being taking smaller steps towards a sound structure involves much and much less risk, and we can still gradually move towards this goal. I also read a really good blog note by Joel ("Things you should never do, part I"[^]), confirming my views on not starting from scratch. So I'm wondering, have any of you guys thrown away the existing stuff (reasonably sized project) and started from scratch? What has been your success/fail ratio on this approach? I'm still resisting the urge to start from scratch, it seems so appealing when working with the crappy code.
Wout
Do you have the analysis, requirments and specification documentation from the original effort? If that work was not previously performed then you have no choice but to start from scratch. Otherwise if you have all those artifacts a short period to verify their accuracy should suffice and a completely new implementation with modifications to design should not be difficult nor time consuming.
led mike
-
Well that sounds like an incremental approach should be taken then. To me the only showstopper that would prompt a re-write in your case is if the app was not properly stratified in it's design with the UI layer being separated cleanly from the actual guts of the program in another layer below. I would never work with a monolithic design ever again, that way lies madness. :)
He, we're not quite there yet! Still got some logic in the UI layer indeed, but we already moved quite some of that into the data layer. :rolleyes:
Wout
-
Do you have the analysis, requirments and specification documentation from the original effort? If that work was not previously performed then you have no choice but to start from scratch. Otherwise if you have all those artifacts a short period to verify their accuracy should suffice and a completely new implementation with modifications to design should not be difficult nor time consuming.
led mike
No, no and no unfortunately. However the systems isn't of such proportions (yet) that we don't know what it should do or figure it out by spending 2 days of staring at code. So the approach I'm taking now is gradually get consistent documentation up.
Wout
-
Oooh, while you mentioned it, we're doing client app, web service, db. Would you happen to know a good way of unit testing this chain? I have done a lot of NUnit testing, but not that much that crossed several processes (or machines). (IIS 6 don't run on windows XP, so that's inconvenient too).
Wout
wout de zeeuw wrote:
Would you happen to know a good way of unit testing this chain?
The thing people forget (and me too) is that unit testing is supposed to test the most fundamental units. I guess I'd start there. But you'll also need to make use of mock objects, which unfortunately requires an architecture that lets you swap out the real object with a mock one--object factories and code that uses interfaces, in other words. I suspect the programmer did not design the code (nor implement it) with unit testing and mock objects in mind. If you don't have that, you can't use mock objects effectively, and you can't test higher level functionality effectively. Which leaves you with creating test data and having the unit tests coordinate their activities across system boundaries. You'll probably write as much, if not more code than the original system going that route. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
I'm working on a fairly big project, and like always it has its legacy code. Unfortunately it's based on legacy code of about a year's work by somebody that was not great at (.NET) programming, let alone architecting and designing it. The whole thing is currently operational, but it's not structurally sound. The pricing structure in the application hard to understand, and has its flaws. The database and web service design are just in the state that things work most of the time, but they have their issues and the design is not good. So the dilemma is, should we start from scratch? I've been telling the company's president that hires me, not to do that, that it would be the biggest mistake ever. The reasoning being taking smaller steps towards a sound structure involves much and much less risk, and we can still gradually move towards this goal. I also read a really good blog note by Joel ("Things you should never do, part I"[^]), confirming my views on not starting from scratch. So I'm wondering, have any of you guys thrown away the existing stuff (reasonably sized project) and started from scratch? What has been your success/fail ratio on this approach? I'm still resisting the urge to start from scratch, it seems so appealing when working with the crappy code.
Wout
In my 20+ years engineering experience I've found it to be universally true - patching a broke system will only cost more in the long run. A bad design doesn't get better when someone 'fixes' it. Always start over, learning from the bad first try what not to do. There are no exceptions I've ever seen or heard reported by a reasonably sober witness.
"...a photo album is like Life, but flat and stuck to pages." - Shog9
-
wout de zeeuw wrote:
Would you happen to know a good way of unit testing this chain?
The thing people forget (and me too) is that unit testing is supposed to test the most fundamental units. I guess I'd start there. But you'll also need to make use of mock objects, which unfortunately requires an architecture that lets you swap out the real object with a mock one--object factories and code that uses interfaces, in other words. I suspect the programmer did not design the code (nor implement it) with unit testing and mock objects in mind. If you don't have that, you can't use mock objects effectively, and you can't test higher level functionality effectively. Which leaves you with creating test data and having the unit tests coordinate their activities across system boundaries. You'll probably write as much, if not more code than the original system going that route. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithGood thinking Marc, I had not thought along these lines yet. Thanks.
Wout
-
I'm working on a fairly big project, and like always it has its legacy code. Unfortunately it's based on legacy code of about a year's work by somebody that was not great at (.NET) programming, let alone architecting and designing it. The whole thing is currently operational, but it's not structurally sound. The pricing structure in the application hard to understand, and has its flaws. The database and web service design are just in the state that things work most of the time, but they have their issues and the design is not good. So the dilemma is, should we start from scratch? I've been telling the company's president that hires me, not to do that, that it would be the biggest mistake ever. The reasoning being taking smaller steps towards a sound structure involves much and much less risk, and we can still gradually move towards this goal. I also read a really good blog note by Joel ("Things you should never do, part I"[^]), confirming my views on not starting from scratch. So I'm wondering, have any of you guys thrown away the existing stuff (reasonably sized project) and started from scratch? What has been your success/fail ratio on this approach? I'm still resisting the urge to start from scratch, it seems so appealing when working with the crappy code.
Wout
Seeing as it is already being used, I'd have to say you are making the right decision going with incremental improvements. I know how tempting it can be to just start from scratch when dealing with someone else's code though. In fact, I ended up doing exactly that on my last project. However, it was an abandoned project that had not ever been released. The previous "developers" sneaked out the back door after realizing that maybe getting some actual training might be a good idea. Unfortunately, the client was under the impression that the project was very close to production worthy. It had a nice interface and most of it worked. Needless to say, he was very surprised by my recommendations after evaluating the existing system to either cut his losses or start over. The end result was a success and a very satisfied client but only because we treated the project as though it had never existed. Had the client requested that any of the existing code be reused, I would have respectfully declined the contract. It was that bad.
-
I'm working on a fairly big project, and like always it has its legacy code. Unfortunately it's based on legacy code of about a year's work by somebody that was not great at (.NET) programming, let alone architecting and designing it. The whole thing is currently operational, but it's not structurally sound. The pricing structure in the application hard to understand, and has its flaws. The database and web service design are just in the state that things work most of the time, but they have their issues and the design is not good. So the dilemma is, should we start from scratch? I've been telling the company's president that hires me, not to do that, that it would be the biggest mistake ever. The reasoning being taking smaller steps towards a sound structure involves much and much less risk, and we can still gradually move towards this goal. I also read a really good blog note by Joel ("Things you should never do, part I"[^]), confirming my views on not starting from scratch. So I'm wondering, have any of you guys thrown away the existing stuff (reasonably sized project) and started from scratch? What has been your success/fail ratio on this approach? I'm still resisting the urge to start from scratch, it seems so appealing when working with the crappy code.
Wout
wout de zeeuw wrote:
So I'm wondering, have any of you guys thrown away the existing stuff (reasonably sized project) and started from scratch?
I have done that with the project I am working on now. Although its not huge and some of the previous code will be use with only little modifications. Its a few thousand lines or more of code. Not very big. It may end up being over 6k lines. Sometimes its better to start from scratch, the new version of my project used a completely different architecture that would require major work to rework the old code, more than building from scratch.
█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██
-
No, no and no unfortunately. However the systems isn't of such proportions (yet) that we don't know what it should do or figure it out by spending 2 days of staring at code. So the approach I'm taking now is gradually get consistent documentation up.
Wout
wout de zeeuw wrote:
figure it out by spending 2 days of staring at code.
Ok but what about the definition of the problem domain, does anyone understand that? Most often some of the high level OO design can/will/should mirror the defintion of the problem domain which of course is produced through analysis and the resulting documentation. So starting from scratch would mean "define the problem domain". IMHO that would be more productive than staring at code especially if that code misrepresents the problem domain.
led mike