| Clean Sheet Redesign
|
|---|
Date: 19/5/2005
| There are 2 types of programmers, those that lean towards incremental change and those that lean towards radical redesign. I fall fairly much in the incremental camp and have done so for a long time. For a long time (4 years?) have needed to make substantial architectural changes to an application I've written and for the sake of incremental change not bothered fixing certain "dead ends" in the design that I'd discovered. I tried redesigning it at least 3 times and then bringing those designs to life in code. And failed. 3 times. I have a few insights into why these redesigns failed that I'd like to share.
- I realize that software is never going to be any good unless the author uses it themselves and so if I was just toiling away on some abstract codebase that I never got to use the motivation factor would just drop till I gave up. So I deliberately set up that most recent effort to get to a working codebase in the least amount of time possible. Using lots of glue code so that I didn't have to modify much of the existing code.
- Another trap I found in getting over the hump of a redesign is relying on a complicated peice of technology that you are developing at the same time. Getting the underlying tech working at the same time as redesigning the app is just too much to keep in the working space of my head. This time I opted for an existing technology so that I could concentrate on the redesign work.
- Finally the other thing that stops you from getting the redesign happening is to aim your design too far away from the body of code that already exists. It's better to make it just past the architectural dead end than to aim for much further away, and miss because of the longer lead time until you getting a working demo and greater disparity between the current code and the "new" code. This time I ignored all but the worst of the design issues to make the task smaller and more approachable. And it worked.
Redesign can usually be done in chunks and it's easy to break them up into peices as small as possible if the redesign is going to be hard. And then tackle them one by one. Better to succeed in something simple than fail at something hard.
|
| Comments:
|
19/05/2005 8:17am
| awareness is the first step |
Ed
19/05/2005 9:19am
| Nice comments. You're the practical sort, aren't you ;-)
I love this quote by Eric Raymond (http://www.catb.org/~esr/faqs/loginataka.html):
"The Rite of the Rewrite is not the only Path to Mastery, but it is perhaps the highest and most Sacred of all Paths. Few indeed are those who, travelling it, have crossed the dark and yawning Abyss of Implementation to Delivery. Many, yea, many in truth stagnate yet in the Desert of Delay, or linger ever in the ghastly limbo called Perpetual Beta."
...but I guess you're not doing a total rewrite, you're doing an incremental one! |
Mario Cassani
24/05/2005 5:44pm
| Ultrafunk Popcorn
Developement of this great piece of software is stopping. The authors will realease the source code only to someone who wishes to futher develope it in the opensource... In cas you are interested:
http://www.ultrafunk.com/cgi-bin/ufbb/YaBB.cgi?board=news;action=display;num=1116570646 |
Chris
26/05/2005 12:58pm
| I agree. Radical redesigns very rarely succeed for the reasons you mention, mostly motivation due to overwhelming complexity too early.
However, you are talking about redesigns by the original author. Redesigns by a new programmer can be successful as long as the original author is not involved in any way. I have done these on several occasions. It is very important that the original author is not involved as they will add a level of complexity that will deflate the new effort. This probably only works when the new programmer is a better coder than the original author.
I do agree though, complete redesigns are in general a very bad idea. Incremental changes let you get immediate results which keeps the motivation level high. Plus it allows you to make small steps and then work on something else for a while. |
|
|
| Reply
|
|---|
| From:
|
|
| Email (optional):
|
(Will be HTML encoded to evade harvesting)
|
| Message:
|
|
|
|
|
|
|
|
|
|
