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
-
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
Some systems are beyond repair. Although Joel is a great writer it does not make him always right. 1 years worth of work by a moron can easily be replaced by 2 months of solid work. The biggest question is how flawed are the assumptions and how hard is the maintenance on the old system? If you are afraid to make even the smallest change in the old system because something might break and it is nearly impossible to test dump it. If you can make changes reasonably well that deliver functional improvements with a low risk the old application will slowly come up to par and can be salvaged.
File Not Found
-
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
Don't think of it as "throw everything away and start fresh" or "live with crappy code". You can start replacing especially bad portions, while using the existing system as a means of verifying that you haven't introduced new bugs into the new system. I never start from scratch if there's an alternative. That doesn't mean that the ugly code i re-use stays ugly after i'm done re-using it...
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
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:
have any of you guys thrown away the existing stuff (reasonably sized project) and started from scratch?
Only if what was there, just flat-out didn't work. Regardless if the code is sloppy, doesn't follow standards and/or is poorly implemented/designed, if it works ... it works. It is my personal and professional opinion, that it is better to refactor portions of the code base, bringing the project "up to spec", than to ditch a working project and start over ... My two cents. [ I did fail to mention that this applies only to projects that are in the field. if the project hasn't been released, and there isn't a mission critical dead-line that must be met, by all means, kill it off and start over ] -- modified at 12:36 Wednesday 31st January, 2007
:..::. Douglas H. Troy ::..
Bad Astronomy |VCF|wxWidgets|WTL -
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
We had this problem at my last job. Things to look at: 1. How much more code will be added in the future? If you have an unstable foundation things will just get worse. 2. how much processing time will be saved in completely redoing it versus smaller fixes? In other words, say a process takes five minutes. Completely starting from scratch you estimate gets the time to one minute. Small fixes will get it to three. how much time will this save for the company versus your programming time?
_________________________________________________________________ Dick Cheney looks like a high school calculus teacher with persistent heartburn.
-
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
I followed both the routes: start over as well as incrementally build. In my first project I started over from scratch. The project was successful but it took lot of time and extremely lot of hard work. In the next two projects I developed the product incrementally and huge success, on time and with far more features than originally planned. In the fourth project I am in now, I decided to start over and it is taking heck of a lot time. The ideal thing was to develop incrementally. If the system works doing a piecemeal replacements of parts one by one is the best option IMHO. A running product is always good.
-
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:
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.[^]
-
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
If it's modular enough to fix incrementally, then do that. If the current problems cannot be fixed without touch every other aspect of the system, consider first that an investment into unit testing the whole thing will pay off much more than a rewrite. You'll know what you break by patching, and you can ultimately use the same unit tests to tests a rewrite. Starting from scratch doesn't fix old problems, it creates new ones. The only way to overcome that is with a test first approach to the development. Otherwise, you'll end up a year from now in the same room, just with different wallpaper. And another piece of sage advice is, don't develop concrete code against an abstract specification. Develop abstracted, modular code against a concrete requirement. 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 -
wout de zeeuw wrote:
have any of you guys thrown away the existing stuff (reasonably sized project) and started from scratch?
Only if what was there, just flat-out didn't work. Regardless if the code is sloppy, doesn't follow standards and/or is poorly implemented/designed, if it works ... it works. It is my personal and professional opinion, that it is better to refactor portions of the code base, bringing the project "up to spec", than to ditch a working project and start over ... My two cents. [ I did fail to mention that this applies only to projects that are in the field. if the project hasn't been released, and there isn't a mission critical dead-line that must be met, by all means, kill it off and start over ] -- modified at 12:36 Wednesday 31st January, 2007
:..::. Douglas H. Troy ::..
Bad Astronomy |VCF|wxWidgets|WTLDouglas Troy wrote:
if the project hasn't been released, and there isn't a mission critical dead-line that must be met, by all means, kill it off and start over
He! Like Vista? :-D
________________________________________________ Personal Blog [ITA] - Tech Blog [ENG] - My Photos Developing ScrewTurn Wiki 2.0 (2.0 Beta is out)
-
wout de zeeuw wrote:
have any of you guys thrown away the existing stuff (reasonably sized project) and started from scratch?
Only if what was there, just flat-out didn't work. Regardless if the code is sloppy, doesn't follow standards and/or is poorly implemented/designed, if it works ... it works. It is my personal and professional opinion, that it is better to refactor portions of the code base, bringing the project "up to spec", than to ditch a working project and start over ... My two cents. [ I did fail to mention that this applies only to projects that are in the field. if the project hasn't been released, and there isn't a mission critical dead-line that must be met, by all means, kill it off and start over ] -- modified at 12:36 Wednesday 31st January, 2007
:..::. Douglas H. Troy ::..
Bad Astronomy |VCF|wxWidgets|WTLThanks for your view douglas, you're reassuring that we're on the right track restructuring gradually (the project is out in the field). It's not easy though! But restarting from scratch is a huge risk to take.
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
Calculate time, costs and benefits. Remember the triangle of software development (time/feature/resources) what in truth is a rectangle (time/feature/resources/quality).
:sigh: Still searching for a good resource to LEARN English grammar ... :~
For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.(John 3:16) :badger: -
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
A common problem with 'legacy code' is Dependency Injection. This is when you have classes that rely too much on other classes, and THAT makes refactoring (fixing) code very tough. I'd start by getting rid of dependency injection, and just refactor bit by bit. As long as you take small steps, and don't actually change what the code is doing, you'll probably be ok.
-
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
The product I'm working on took the start from scratch approach and spent 3 years on a complete rewrite, and then spent the last year merging that rewrite in with the existing product because they couldn't manage to get the rewrite under control. So now there is a combination of existing tested poorly written code merged in with a huge mass of slightly cleaner untested code all pushed out the door to get some benefit from the time spent on the re-write. So, only go with a re-write if you absolutely have to, there are things that are much worse then starting from bad code and making it better.
Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you. -Chris Maunder
-
The product I'm working on took the start from scratch approach and spent 3 years on a complete rewrite, and then spent the last year merging that rewrite in with the existing product because they couldn't manage to get the rewrite under control. So now there is a combination of existing tested poorly written code merged in with a huge mass of slightly cleaner untested code all pushed out the door to get some benefit from the time spent on the re-write. So, only go with a re-write if you absolutely have to, there are things that are much worse then starting from bad code and making it better.
Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you. -Chris Maunder
Aaaah, that's the kind of horror story I was looking for! :laugh: That makes me feel a lot better!
Wout
-
If it's modular enough to fix incrementally, then do that. If the current problems cannot be fixed without touch every other aspect of the system, consider first that an investment into unit testing the whole thing will pay off much more than a rewrite. You'll know what you break by patching, and you can ultimately use the same unit tests to tests a rewrite. Starting from scratch doesn't fix old problems, it creates new ones. The only way to overcome that is with a test first approach to the development. Otherwise, you'll end up a year from now in the same room, just with different wallpaper. And another piece of sage advice is, don't develop concrete code against an abstract specification. Develop abstracted, modular code against a concrete requirement. 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 one... we don't have any testing in place yet. I'm gradually massaging everybody to see the need for unit testing. I have noticed things that were not right in the code/design, but still we had to release because of time pressure. And my thinking has been that at least they will see that the software has a lot of problems, so as a result they will see the need for unit testing hopefully.
Wout
-
If it's modular enough to fix incrementally, then do that. If the current problems cannot be fixed without touch every other aspect of the system, consider first that an investment into unit testing the whole thing will pay off much more than a rewrite. You'll know what you break by patching, and you can ultimately use the same unit tests to tests a rewrite. Starting from scratch doesn't fix old problems, it creates new ones. The only way to overcome that is with a test first approach to the development. Otherwise, you'll end up a year from now in the same room, just with different wallpaper. And another piece of sage advice is, don't develop concrete code against an abstract specification. Develop abstracted, modular code against a concrete requirement. 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 SmithOooh, 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
-
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. :)