Start from scratch?

[leckey 0]

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.

[Rama Krishna Vavilala]

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.

[Nemanja Trifunovic]

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.[^]

---

Programming Blog utf8-cpp

[Marc Clifton]

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

Thyme In The Country

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

[Dario Solera]

Douglas 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]

Thanks 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

[Clickok]

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:

[Paul Brower]

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.

[Andy Brummer]

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

[wout de zeeuw]

Aaaah, that's the kind of horror story I was looking for! :laugh: That makes me feel a lot better!

Wout

[wout de zeeuw]

Good 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

[wout de zeeuw]

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

[Member 96]

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.

[wout de zeeuw]

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]

Ah, pretty good one too (though I always find Joel's reasoning very clean cut).

Wout

[Member 96]

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. :)

[led mike]

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

[wout de zeeuw]

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

[wout de zeeuw]

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

[Marc Clifton]

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

Thyme In The Country

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