Fog Creek Software
Discussion Board

To write from scratch or not

Yes, I know why I should not re-write from scratch, but let me explain, will you? ;-)

Well, I needed a web-site to work, at least the front-end, in order to show investors, clients etc. I was on a shoe string budget and very limited, so I used a programmer to write sh*t.

That guy had no feeling for UI (he wouldn't even try to make things look normal), hard-coded anything imaginable (the database password), and anything else that can fit into the description of sh*t. Spaghetti code, does that fit too?

He made it so hard to make any changes, so it took month to do the job, and a few more month went by, and things didn't get done.

I now have to hire a new guy. All is written in PHP/MySQL. Even if I will Hire the best person for PHP/MySQL, he will probably need to work very hard to straighten the old code, and I don't know if he will want to use the old.

Or, I can hire (the best of course...) in a different language (let's say, but that's not the point of the question), and start from scratch.

What do you think? Still try to keep the old code? Not worth it?

Some sam
Wednesday, July 30, 2003

Joel's argument only works for large projects, and core business. For something like you describe, I beleve re-writting would probably be acceptable.

Mr Jack
Wednesday, July 30, 2003

I assume the code doesn't have a documented design. Imagine you had to document the design. If it would be too complex because of the spaghetti code, then you're probably not going to be able to maintain it easily.

Even in spaghetti code though, there are small pockets of code that can be reliably reused. Maybe a function that validates something. Or something that reads registry values (then again I've seen one with a colossal resource leak).

If there really aren't though, then a rewrite sounds like the least risk.

Better Than Being Unemployed...
Wednesday, July 30, 2003

Sounds like .dot-com all over again :-)

If you have time for a rewrite then by all means do a rewrite.  If your clients/investors expects the system to be "almost complete" as it surely looked on the demo, your biggest problem is not to rewrite the code into a maintainable system, but to do some serious "expectaions management"  to get the expectations of your clients down to a manageable level where you can meet them.

1) What time to market is expected by your clients?
2) What feature set was shown during the demo?
3) Were deadlines set for delivery of the finished thing?

If some finished-looking mocked up features were shown, will they be functional on time for version 1?

So I think this is as much a managment problem as a programming problem so you can deliver what is expected on time for the release.

Wednesday, July 30, 2003

From what you are telling us I'd say retire the code. We have an almost identical situation here: PHP/MSSQL, totaly unmaintainable, developed under fixed price by employee that has since left the company. Every day we keep our fingers crossed the system will hold till the end of the year (when the included support runs out).
Postponing the rewrite will only make matters worse, and increase the costs. Since this certainly does not sound like a well gardened and grown system that has embedded years of tacit knowledge, ignore the "do not go here" signs surrounding the rewrite area.

Just me (Sir to you)
Wednesday, July 30, 2003

Is the architecture solid, with the right code on the right page and no nontrivial kludges?
Is the datamodel solid? (very important)
Is the folder structure of the app logical and fit for futher expansion.

If so, dont rewrite. Test, analyze, improve.

Eric DeBois
Wednesday, July 30, 2003

When a certain authority writes "Never write from scratch" chances are he really means "Rewriting from scratch is generally a bad habit and far too many developers rewrite from scratch without overseeing all the consequences. Think thrice before you rewrite.". But nobody would read past the boring title.

Say you have 1000 lines of spaghetti nightmare code written by a BPFH (Bastard Programmer From Hell), the kind that just doesn't care about requirements, is proud of the fact that only he understands the code and likes mixing dozens of languages to show his smartness. Do you really want stay away from a total rewrite?

When the "Rewrite from scratch" option comes up, a very loud alarm bell should go of in your head. After all there are a few million reasons why not to rewrite from scratch. But if you considered all of them and still find the balance strongly on the rewrite side, just do it.

You can break the rules if you understand them.

Jan Derk
Wednesday, July 30, 2003

The ROI of fixing and refactoring depend upon the original code base working in the first place.  From what you've said the codebase doesn't currently work so writing off the previous code and starting again is the only economic decision to make.

Simon Lucy
Wednesday, July 30, 2003


Exactly right.  One of my cardinal rules is never to copy and paste code.  Whenever I find myself selecting a block of code and copying, the alarm bells do go off, and I start thinking about whether it should be in its own function.  (=  It doesn't always go there, but it at least gets me thinking about it.

Some (other) sam-

Sounds like time for a major overhaul, if not a complete rewrite.  If your investors/clients understood that you were demoing a prototype, I'd hope they'd be okay with you taking the time and money to do it right this time.  And if you want Joel to back me up on this, think of your existing app as third-party (since if you can't understand the crap this other guy wrote, you may as well not have the source at all) and read "In Defense of Not-Invented-Here Syndrome":

Sam Livingston-Gray
Wednesday, July 30, 2003

Thank you every one for thoughtful replies.

Some sam
Wednesday, July 30, 2003

I have some thoughts.

PHP is a fairly simple scripting language. It should be easy to re-write parts as they need improving & refactor the old parts at the same time.

When you create a new page, write a generic database connect string, and then replace the old one wherever you can find it. Take it little by little, improving where you can, and eventually the code should shape up.
Wednesday, July 30, 2003

*  Recent Topics

*  Fog Creek Home