The Old Joel on Software Forum: Part 3 (of 5) - On Things You Should Never Do, Part I

On Things You Should Never Do, Part I

Hi,

My company is just about to re-write an existing piece of software from scratch and reading your article at this point is kind of unnerving to say the least!

--
Ranju. V
--

Ranju. V
Wednesday, December 3, 2003

We really need to put perspective around this topic. "Never say never" should have applied. There are very good reasons to rewrite things from scratch. Would we expect CityDesk to be written for 8088 cpus? Windows 3.1? Given the "never" shouldn't we all still be using DOS?

Of course not. However, rewriting for the sake of rewriting (i.e. going from C++ to Java), without a compelling business reason, is a bad idea. If however, you do have one: going from desktop to web or adding infrastructure to support a necessary feature/function then it does make sense.

Be attentive, not afraid.

MSHack
Wednesday, December 3, 2003

Perhaps you can suggest that code be refactored first so you can see if there are modules/classes that can be reused to reduce overall coding time.

Lou
Wednesday, December 3, 2003

<i>My company is just about to re-write an existing piece of software from scratch and reading your article at this point is kind of unnerving to say the least!</i>

Why have they decided to rewrite it from scratch?

There's a difference, for example, between rewriting a working application and rewriting one that is fundamentally flawed and still won't work after a considerable effort.

Joe
http://www.joegrossberg.com

Joe Grossberg
Wednesday, December 3, 2003

If you're rewriting it because your developers in charge of it doesn't know/like the programming language or platform it was written for, send them to training.

If they refuse to go to training or still refuse to work on the project as it is after training, fire them. Good developers are gold, but primadona developers (unless they really are gods gift to IT) aren't worth the mediocrity they put out.

Now, that being said, as others have pointed out there are some valid reasons for rewriting your application.

For example, the platform it runs on is too costly to maintain. ex. Your org is finally getting rid of the old, slow IBM mainframe that takes up 3 rooms all by itself. (of course, what my org did in that situation was to hand-code an IBM mainframe emulator that runs on Solaris faster than it ever did on the mainframe, but we have that kind of talent working here)

For any application you develop at any time, you run the risk that the users requirements will not be met (maybe they didn't even state their requirements properly). What often happens is that appliction X is old and crufty so Org desides to rewrite it from scratch. 3-5 years and lots of developer hours later, application Y is rolled out. However, with all the new features in app Y, it is more confusing to the users than X. Even though they were clamoring for these improvements, the users rebel and continue to use app X instead of Y. You end up having all the costs of maintaing X as well as Y (because the new users learn Y).

Rewriting is a very risky thing. Make sure you have a valid business case for it and a damn good plan to implement it in a successful way (read: no loss of service to the end users).

Richard P
Wednesday, December 3, 2003

1) New Development
2) Rewrites
3) Maintenance

Of the big 3... ..rewriting an app has the least favorable risk/reward in terms of user success probability, justifying your job, and your value to the firm (something you should weigh in this cost-cutting climate) I vowed to never again work on a rewrite effort, especially if I was working for clueless, buzzword driven mgmt. That one decision served me well, and made me lots of money.

Bella
Wednesday, December 3, 2003