Question: When is it time to rewrite?

16 Sep

I don’t know how many of you have read the following post:  Things You Should Never Do, Part I, by Joel Spolsky, but if you have not, you should.  He raises some very interesting points about making the mistake that we as developers often take part in, “we have to scrap this thing and get a new one… it is old, it does not work, and it needs to be rewritten.”  I’m sure we have all either said or if you have developed for more than 2 days, you have heard someone say something to that effect.

I must say, I agree with his article, a lot!  However, this leads me to a question; “when is it time to rewrite?”  Couple this question with my last article on “Future Proof,” and I fear that I may be becoming “the old guy in the room.”  Since I’ve already (in my mind) proved beyond a shadow of a doubt that there is no such thing as “Future Proof” and I have to say I agree with Joel’s points in his post… I also have to say that on many projects that I’ve been on, I too have stated, “this thing is unbelievable and needs to be rewritten.”  I will give you an example of a product I was working on for a startup in CA and how not making the move to a new approach seriously wasted lots of money, resources, and time.

The product that we were building would be considered collaboration software today, but it was a virtual meeting software product, kind of like WebEx or GoToMeeting.  The team that I had assembled had some great ideas of where a product like that needed to go and we thought we would be able to do it.  However, when I came into the organization the current “selling” product was based on a very old technology that the investors had purchased from another country, we had NO developers from the original code and the product code was to do virtual classroom with avatars for higher learning institutions.

In a time before I joined, the original developers changed the product to be a more simple “meeting” software but only they really understood the underlying code and structure.  To make matters even worse, I found out that we did not get all of the code and that the underlying engine had not been compiled since 1998 and it was 2006.  By the way, that was the first thing that I had to fix and it was because we were shipping a product on it (it was originally compiled for Windows NT).  The story goes on from there, but as you can imagine, everything we touched, tried to add, or even fixed, broke other pieces of the code and to make matters even more exciting we had no testing code.  Wow, writing this really makes me cringe.

Now also keep in mind that the investors wanted to take advantage of the investment in a “killer piece of code, which could do anything.”  Being a startup, we had plans for a new platform to handle what we knew we needed for the next generation of collaboration software, however we were stilled tied to the “shipping” product to help offset the investment.  By the way, I did do my concept of Software Archeology to try to better understand the code and have a better approach and it did help, but it did not give the team enough underlying knowledge to build a great system using the old technology.

So this leads to my top 3 things that kind of balance Joel’s thinking a little.

¨     Knowledge;  The underlying platform is unknown to the team and it is not possible to quickly get an understanding of the technology through normal methods and the team does not have the killer skills for that technology.

  • Could we have gotten the knowledge?  IMO, no.  The code was too convoluted and cryptic to be picked up, plus the software was being used as something it was not designed to be used for in the first place.

¨     Out and out technology limitation;  This one is more difficult, as the tech being used on any existing product is always limited or needs replaced to fix limitations.

  • What do you mean?  This may be something like a 32-bit implementation and it needs to be a 64-bit implementation or you are on the iOS and you need to be on Android.  Now if you are using a good development language and environment, then moving to 64-bit does not require a complete rewrite… hmm, I wonder what product I may be thinking of… anybody?

¨     Direction change;  This was much more evident when a majority of companies and programmers moved to Java from something else.  This usually causes a new product to be written in the new language or direction.

  • Can’t you wrap the existing?  Maybe, but in most cases the developers will make the case that having a limited number of things to support is a good thing and that the whole reason for moving to a new platform or direction is because it will give an advantage and wrapping the old tech will be more of the same.

Do you use a set of questions or criteria to figure out what you have and how to go forward?  Do you have strict guidelines that you have used that helps with this question?

Let me know you thoughts.


More to come…


Posted by on September 16, 2011 in Opinion, Technology


3 responses to “Question: When is it time to rewrite?

  1. MozHasTheFlu

    September 18, 2011 at 5:37 pm

    When the list of outstanding change requests has been growing faster than the list of implemented change requests to the point where prioritising becomes triage becomes “aim for legal compliance”. Do you add staff to beat the dead horse harder, or add staff to build a new horse?

    When that one guy who has coded himself a job for life quits his hobby of divorcing bimbos and starts building a pile of cash. You know it’s only a matter of time until no-one will be around to maintain whatever core elements he currently maintains.

    When the requirements/use of the software is so far from what the software does that it’s hard to see what most of the code actually does for most of the users. Shared classroom software with avatars being used for videoconferencing is heading down this path IMO. I’ve worked on a shared contacts database that had become a CRM tool then migrated to the web, and it turned out that about 90% of the code that was older than 5 years was never executed by users (but we still tested it and maintained it). I don’t know if dumped that old code is refactoring or an implicit rewrite.

  2. Angelo Serra

    September 22, 2011 at 10:22 pm

    Mike – Being a very consistent reader of Joel’s (my favorite post of his is from a while back is The Joel Test [] – I have used it in a few job changes to get my feet under me!), I like the items you have added on. For me, the rule of thumb is it is time to rewrite when the list of defects grows with every release. If you are consistently breaking down-stream items when a new feature is added, you have reached true code-entropy/code rot and you are In A Bad Place.

    Sometime your team is forced to rewrite – such as when the underlying software (e.g. the JRE, OS, or MS Framework) has gone through a significant shift and APIs you relied on have been deprecated too far or are no longer supported.

    Refactoring aside (you know, in order to remove a code smell), this may be better to ask when not to rewrite. There are always deadlines and always new features to cram in as close to a deadline as possible (esp. when shipping a commercial product). I believe rewriting should be considered a luxury, and code wrapping of older, static code (no change velocity after five years) a necessity.

    So, my short list of questions to ask (some overlap with what you have – and in no order) is typically:

    1. Do we have a copy of the source? Does anyone here understand the source?
    2. When does this feature (that will rely on the code being considered for rewrite) need to be implemented?
    3. How long has the code been idle/no changes?
    4. Does it perform to spec?
    5. Is it compatible with the production environment?

  3. Michael Thuma

    September 27, 2011 at 1:23 pm

    Rewriting is a good idea in rare cases. In our country Java huge developments are done when maybe a IBM server (HOST) is replaced. This is also in the context of something new and adoption to changed requirements due to changing business processes or an increased demand for application security. Just rewriting a Software … I have seen some approaches in the corner of data-driven apps, tiny but intelligent developments that could be ported within 14 days from an old Software to a newer one on WPF. The moment you don’t have the one, who holds the business knowledge available, it tends to make no sense.

    If people would rewrite also if assuming little speedup in development via more experienced developers and more professional adoption of more flexible and less time consuming methodologies (also this assumption is more wishful thinking because requirements grow and formalism too), we would get less and less new things. This means throw away Software whenever the point in time came when the Software sees it’s sunset for whatever reason.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: