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…