

Ask HN: How much does this Joel's article hold true? - sankara

http://www.joelonsoftware.com/articles/fog0000000069.html<p>I'm working on a startup and the current codebase is 2.5 years old. The original code was built with a lot of assumptions (or future predictions rather); very few of it hold true today. Also, a major goal back then was to just get it out. A lot has changed and it has become a rather hard problem to maintain it. I'm not talking about bug fixes; it's adding new features that is taking at least 2x the time it actually needs. A couple of us (only in out part time and without disrupting the existing code base) are planning to retouch it; rethink the assumptions as it holds today and incorporate best practices. However my manager is pointing me to the article above and says we are at fault here. Have you been in a situation like this? What would your suggestion be?
======
btilly
Feel free to ignore that article IF you know what you are doing. Joel has a
lot of opinions, that usually sound really good, and only some of them have
any validity.

For example the Netscape codebase that he complained about went on to become
Mozilla, which was the base for Firefox, which has done pretty well.
Furthermore there was actually no choice about rewriting the original - once
Netscape pulled out the bits that were owned by other companies they didn't
have running code. When the only code you've got clear rights to won't run,
drastic measures are called for.

For another example, Perl 5 was a complete rewrite of Perl 4 from scratch. The
result was a much more powerful, extensible, and simpler language. (Yes, Perl
4 was grammatically much more complex than Perl 5.) Perl 5 has been far more
successful than Perl 4. (Some 15 years in the result is creaky, but there are
still a lot of people using it.)

On the flip side I've encountered some true disasters caused by the
refactoring mantra. When you start refactoring in place, it is like you're
living in a construction zone. Worse yet, as you reconstruct it, your opinions
on how to write it will change, and you're likely to change how you're
refactoring it. After a few generations of this, you get a real mess.

That said, _usually_ refactoring is a better idea than a rewrite. There are a
_lot_ of examples where complete rewrites have lead to major disasters. (If
I'm feeling snarky I'd use Perl 6 as an example.) And businesses have real
cause for concern about spending years rewriting a system, with the end result
that they get back to where they started but with more bugs.

Furthermore be warned that the second attempt to write a piece of software is
notoriously hard to do right. Look at
<http://c2.com/cgi/wiki?SecondSystemEffect> for a description of some of the
pitfalls. So be very, very cautious about starting such an effort.

All of that said, if the code is a big mess 2.5 years in, then you probably
have something else going wrong. In my experience good software developers in
a good environment don't generally wind up in that much trouble that fast. I'm
not a big fan of assigning fault. But odds are good that neither developers
nor management are blameless. And if you've got the same developers, and same
management, it would be silly to predict a significantly different result.

Still if you want to start a rewrite, the first question is whether or not you
have good unit tests. Because if you don't, then it will be much, much harder
to be sure that your rewrite is doing the right thing. Furthermore I can
virtually guarantee that the act of trying to write tests for the existing
system will give lots of opportunities to find significant improvements.

If you've brought it up to the point that you have a good set of unit tests,
and you still think that the rewrite is necessary, then you'll be in a much
better position to pursue that. And if you still have pushback from
management, well, it will be some time down the road from now, improving the
code will have improved your skills, and hopefully the economy will be in good
enough shape that a better job won't be that hard to find...

~~~
jacquesm
> When you start refactoring in place, it is like you're living in a
> construction zone.

That's a real gem. I never looked at it that way but it is undeniably true.

------
nandemo
Clickable link: <http://www.joelonsoftware.com/articles/fog0000000069.html>

I think one key point is:

> _The old mantra_ build one to throw away _is dangerous when applied to large
> scale commercial applications_.

How big is your application? How many users does it have? Do you already have
a good regression test suite?

~~~
sankara
Not very complex. It's the backend of a webapplication that we are targetting.
Testing is complex because of the way the current design is and that is one of
the major driving factors for refactor/rewrite.

------
cousin_it
Following Joel's advice may or may not make you better off. Can't really tell
without going into technical specifics. Can you tell us more about your case?

Our current product (online mapping for corporate clients) went through
multiple rewrites when it was already quite successful: the client side went
from JavaScript to AS2 then to AS3, the server side went from PHP to C#, and
in addition to that many big parts of the project were rewritten from scratch
multiple times. None of this was ever done just to "incorporate best
practices", though.

~~~
sankara
>>None of this was ever done just to "incorporate best practices", though.

Of course, no one is gonna rewrite something to just "incorporate best
practices".

------
RiderOfGiraffes
tl;dr : Re-writes are usually a disaster - be absolutely certain of your
ground before undertaking one.

========

The major question to ask is "why?" - and ask it repeatedly.

* Why is it a mess?

* Why do you think writing it from scratch will be faster than fixing it?

* Why do you think you can spend the time creating nothing new for X weeks while you re-write?

* Why do you think you will produce something better/smaller/faster/cleaner/less buggy?

Here are some thoughts:

* Maybe it's a mess because the original design was fundamentally wrong and it really can't be guided into the right form.

* Maybe it's a mess because people kept adding features without really understanding how it worked, so their additions didn't fit the architecture/design/structure.

But maybe it's a mess because it's doing stuff you don't yet recognize as
being important, so what's there is essential complexity.

Some anecdotes and background.

I've overseen two complete re-writes, and five on-going re-workings. One re-
write was a success both technically and commercially, the other was a near
complete disaster. Four of the re-workings are still underway and the product
has remained live, sellable and profitable the whole time. The fifth is under
constant review, but is not a disaster.

So re-writes can work, but the experience is that they usually don't. Go
against the advice only if you are certain of your facts.

~~~
sankara
>>* Maybe it's a mess because the original design was fundamentally wrong and
it really can't be guided into the right form. >> >>* Maybe it's a mess
because people kept adding features without really understanding how it
worked, so their additions didn't fit the architecture/design/structure.

I'm not looking to blame anyone. Whatever has happened, has happened already
(I'm not ignoring the learnings) and I'm just looking to improve things.

~~~
RiderOfGiraffes
Blame is not the point.

Assume that the original authors aren't stupid. Maybe they were, but assume
they weren't. Now ask - how did this get in such a mess? _Why_ did this get in
such a mess? How do I know that if I rewrite it I won't make the same mess?

If you can't answer that then you can't decide whether to re-write or
refactor. Knowing why it got in a mess is a crucial piece of information.

Are you cleverer than the original authors? Do you know more than them about
the problem? Remember, they spent ages writing that code - they know _lots_
about the problem. Are you sure you understand it better?

Unless you can answer absolutely, unequivocally yes then you shouldn't
rewrite. You should work to improve the existing code in small pieces. Only
when you believe you understand it better than the original authors should you
make the decision to rewrite.

Otherwise you are mostly likely to spend a lot of time recreating their
mistakes.

~~~
sankara
I'm sorry if I misread. It is a combination of two. As I had mentioned in a
previous comment everything from process to environment to developers has
changed for the better.

Thank you all for your valuable suggestions.

------
lelele
Have you good unit tests? Then you can refactor/rewrite it as you please.
Consider rewriting a section a time.

