Allegro.cc - Online Community

Allegro.cc Forums » Game Design & Concepts » Don't rewrite your old code

This thread is locked; no one can reply to it. rss feed Print
 1   2   3 
Don't rewrite your old code
Mark Oates
Member #1,146
March 2001
avatar

nice little article here

Thomas Fjellstrom
Member #476
June 2000
avatar

Hah. In some cases you have to rewrite. Ironically, like the Netscape 4. From what I gather it was SO horrible, that they couldn't continue with it. I know for a fact that the later 4.x versions were horribly buggy, and lacking in features.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Matthew Leverton
Supreme Loser
January 1999
avatar

I don't agree with his blanket statement. (Yes, I read the article.) I'm sure it's true under some circumstances, but in my experience if you come across code written by incompetent fools, you are better off burning it and starting over.

For instance, at a previous job in a previous life, a co-worker had been working on a web project for three months. The project manager came to me and asked me to "take over" since the deadline was rapidly approaching. After taking one look at the code, my eyes started to bleed. That weekend, I re-wrote the entire thing from scratch. Came in on that Monday, and handed it him. I couldn't care less that it meant they just wasted three months of salary on her.

Now I know that Joel is talking about re-writing code that already "works," so my example may not be at all what he is talking about. But he considered Netscape 4 as something that "worked," which is a very bad example. Netscape 4 was very screwed up; IE 4 was blowing it away. He obviously never had to look at it from a developer's perspective.

Thomas Fjellstrom
Member #476
June 2000
avatar

Matthew said:

He obviously never had to look at it from a developer's perspective.

I don't think he looked at it from a USER's perspective.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Matthew Leverton
Supreme Loser
January 1999
avatar

Quote:

I don't think he looked at it from a USER's perspective.

To be clear, I mean a 3rd party web-developer as opposed to a Netscape developer.

Michael Faerber
Member #4,800
July 2004
avatar

Old.

[EDIT]
Although I agree with the article.

--
"The basic of informatics is Microsoft Office." - An informatics teacher in our school
"Do you know Linux?" "Linux? Isn't that something for visually impaired people?"

Paul whoknows
Member #5,081
September 2004
avatar

Quote:

It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.

My personal experience:
One thing to avoid the "start from scratch all over again" is to re-write and re-design your project from time to time, to make it more readable.
In my current project I re-designed a few classes that already worked perfect! but I was not happy with them, because they looked a bit messy, I spent time in the re-design, and I am sure that players will never notice the difference, but as a developer I feel better, because now I have a more legible code.
I allways try to achieve readability because, as the articles said:

Quote:

It's harder to read code than to write it

____

"The unlimited potential has been replaced by the concrete reality of what I programmed today." - Jordan Mechner.

Dustin Dettmer
Member #3,935
October 2003
avatar

Ya I'm not sure about that point. I doubt source code from Netscape 4.0 would stand a chance against all the new standards for CSS and javascript. Maybe some code could be preserved, but the majority could not.

In the feedback link they talk about redoing the FTP code. Heh, now that makes no sense at all.

Bruce Perry
Member #270
April 2000

That Joel guy would not get a job at the company I work for. :-X

Quote:

There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:
It's harder to read code than to write it.

Let me reword that.

Quote:

There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably right. The reason that the old code is a mess is because they don't know a cardinal, fundamental law of programming:
If you code like a muppet, neither you nor anyone else will even bother trying to read your code. (It might help to get a clue before rewriting it.)

We have some golden library design rules at work. They work amazingly well. We can understand our code six months later (shock!), and we can all modify each other's code with confidence and success. It's great! :D

[EDIT]
Actually, he changes his mind halfway through. He starts off by saying that old code isn't messy, but then he changes his mind and concedes that actually it is messy and does need careful refactoring (which is often true). He might get a job then. ;D

--
Bruce "entheh" Perry [ Web site | DUMB | Set Up Us The Bomb !!! | Balls ]
Programming should be fun. That's why I hate C and C++.
The brxybrytl has you.

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

To be clear, I mean a 3rd party web-developer as opposed to a Netscape developer.

Ah, ok. But to be clear, I mean from a plain old user's perspective.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Dennis
Member #1,090
July 2003
avatar

Slightly off-topic: Among artists it is common practice to redo some of their old works to learn and to see how they have improved over time. Maybe that's the same reason to rewrite old code, aside from the functional reason of course (code that doesn't work just needs to be fixed/rewritten, whereas a crappy piece of art can still stay as it is, as it doesn't have a well defined function like code has).

ReyBrujo
Moderator
January 2001
avatar

That is called extreme programming: you program thinking in today and dismissing tomorrow. So, instead of thinking "I may need a new argument for this function" you say "I only need these arguments for this function". It is good for evolutionary design, the one where you need to create a prototype, show it to clients, get suggestions, and then update the prototype with the suggestions. We used it at work, but found it to be costly (especially when you have a limited number of programmers).

The truth is, when you are dealing with a 9 year old product (like the one I work with), you usually find several old paradigms that are outdated, and need to write a lot of code again. Personally, in four years I threw many components away, trimmed others, and fully recreated the contraindication module, the drug database, the graphical interface, allergies and, after three weeks, the settings (so that you can query for settings or show the graphical interface to change settings anywhere in the program, for maximum customization). None of these changes would have been possible with the old code (to give some examples, in Visual Basic nobody used implementations until three years ago, there were copies of the same function everywhere, and there were even rem comments... and in the C++ part, a component had created the full COM interface manually, hardcoding the GUIDs, another had an abusive hierarchy of 15 levels, none of which has siblings--think in a hierarchy that looks like a vertical line without branches--, and another was a horizontal one, where leaves did not inherit from each other but instead always repeated code from other classes).

Gamasutra has a feature about it, Embracing Fun: Why Extreme Programming is Great for Game Development.

--
RB
光子「あたしただ…奪う側に回ろうと思っただけよ」
Mitsuko's last words, Battle Royale

Simon Parzer
Member #3,330
March 2003
avatar

"Don't rewrite your old code" is a great title, actually. It doesn't say "Don't rewrite somebody else's old code".

Sometimes the title is ten times better than the article itself :P

Bob
Free Market Evangelist
September 2000
avatar

Joel makes a good point, from a business perspective. If you've got a product that "works", reverting back to something that doesn't makes no sense at all.

That doesn't mean that a certain subset of the code can't be rewritten. In fact, it's probably a good idea to pull out a chunk of code, do some spring cleaning (and by which, I mean rewrite it), and refit it back into the codebase.

When you're dealing with 0.25+ MLOC codebases, rewriting and redebugging them in their entirety is often not a viable option.

Quote:

We have some golden library design rules at work. They work amazingly well.

How well do they work on a long-term basis? Over a 3-5 year basis, yes it's possible to come up with rules and techniques to keep things manageable. When you have a 8+ year old codebase, a lot of things tend to change over time to make the existing code inadequate.

The metric I use is a shelf life of good quality code is 5 years. Call it Bob's Law if you will ;) Basically, you will need to rewrite your code every 5 years. Plan for it.

Code does rot. Not because the code itself functions less over time, or because defects magically insert themselves. It's simply because the requirements change, and keep changing even after the product has shipped. These requirements may not even be under your control, or the control of your company. For example, the OS changes, CPUs get faster, you now need a port to some other platform, etc. The existing code, being static by definition, does not keep up with these changes.

When you do need to make changes to the codebase, you also need to look at things from a business perspective. What's the !/$ of the change? Do the small incremental changes you need to make warrant a complete rewrite to make them a better fit for the architecture?

Of course, you also need to weigh in some metric based on the "mass" of the code. Is the code in such as shape that it will collapse onto itself and turn into a blackhole, sucking all development time into nothingness?

I don't know what the state of Netscape 4 was at the time. In retrospect, it was definitely a bad idea to rewrite it from scratch. But the neat thing about hindsight is that it's always 20/20. It cost Netscape 2 years of time where they had no new product on the market. No new product == no income. Loss of market share and mindshare. That's a really bad position to be in, business wise.

--
- Bob
[ -- All my signature links are 404 -- ]

GullRaDriel
Member #3,861
September 2003
avatar

I am shared.

Don't we always say that reinventing the wheel is bad ?

Of course, if the code is a total mess, then rewrite ! But if it is good code, nicely organized and structured, where is the need huh ?

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

I don't know what the state of Netscape 4 was at the time. In retrospect, it was definitely a bad idea to rewrite it from scratch. But the neat thing about hindsight is that it's always 20/20. It cost Netscape 2 years of time where they had no new product on the market. No new product == no income. Loss of market share and mindshare. That's a really bad position to be in, business wise.

Netscape didn't make any proffit from The browser at that point anyway, Microsoft forced them to give it away. All it cost was the manpower to write it. And they did get some help from the community (albeit not that much).

Netscape made a majority of their income from their server business even when they were selling the browser. And it shows in how they let the browser rot.

That said, excellent view Bob. I'm adding this to my threadbook.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Bruce Perry
Member #270
April 2000

Quote:

How well do they work on a long-term basis?

For the point I was making, they should work for ever. All our golden rules are ultimately designed to keep the code clear and easy to work with. Of course we have to rewrite or adjust code if requirements change (or if Sun break Java) - but we never have to rewrite code just because we can't understand it. Joel's point was that people have trouble reading other people's code or their own old code, and that just isn't true for us. :)

Now, Sun's standard library code, on the other hand ... :-X Jesus Christ. No wonder they break Java so often.

--
Bruce "entheh" Perry [ Web site | DUMB | Set Up Us The Bomb !!! | Balls ]
Programming should be fun. That's why I hate C and C++.
The brxybrytl has you.

ReyBrujo
Moderator
January 2001
avatar

Something I have learned in five years as professional programmer: you never rewrite code to fix bugs, you rewrite it to add new features.

--
RB
光子「あたしただ…奪う側に回ろうと思っただけよ」
Mitsuko's last words, Battle Royale

Bob
Free Market Evangelist
September 2000
avatar

Quote:

Something I have learned in five years as professional programmer: you never rewrite code to fix bugs, you rewrite it to add new features.

I do exactly the opposite! But then again, the code I work with has a low average quality.

--
- Bob
[ -- All my signature links are 404 -- ]

Trezker
Member #1,739
December 2001
avatar

If the wheel doesn't fit the cart, you need a new wheel.

Johan Halmén
Member #1,550
September 2001

Trezker said:

If the wheel doesn't fit the cart, you need a new wheel.

Then invent it!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Years of thorough research have revealed that the red "x" that closes a window, really isn't red, but white on red background.

Years of thorough research have revealed that what people find beautiful about the Mandelbrot set is not the set itself, but all the rest.

Indeterminatus
Member #737
November 2000
avatar

Quote:

If the wheel doesn't fit the cart, you need a new wheel.

Or a new cart. :P

_______________________________
Indeterminatus. [Atomic Butcher]
si tacuisses, philosophus mansisses

HoHo
Member #4,534
April 2004
avatar

Or a new axel to piece together the two incompatible things :P

__________
In theory, there is no difference between theory and practice. But, in practice, there is - Jan L.A. van de Snepscheut
MMORPG's...Many Men Online Role Playing Girls - Radagar
"Is Java REALLY slower? Does STL really bloat your exes? Find out with your friendly host, HoHo, and his benchmarking machine!" - Jakub Wasilewski

Matt Smith
Member #783
November 2000

..or an elephant to drag the cart along without its wheels. ..or an assassin to wipe out the client waiting for the cart. I'm sure these can be massaged into metaphors for certain industry practices :)

Trezker
Member #1,739
December 2001
avatar

When the cost of modifying the cart to fit the wheel is greater than the cost of getting a new wheel, you should get a new wheel.

 1   2   3 


Go to: