At ZendCon I talked about “Planning a PHP 4 to PHP 5 codebase rewrite, a practical approach”. The talk was based on my own experience, as well as famous discussion of the topic such as Joel Spolsky’s “Things you should never do” and the examination of “famous” platform rewrites.
During my monday morning surf, I bumped into this dailywtf called “No Need to Change It!“. This is an interesting story about a software development company who created car dealership systems. The original system was built in Cobol and the story goes on to explain the various loops that they jumped through to avoid having to rewrite their entire system. These steps included creating a COBOL->C converter (so that they could run under x86), and then the generation of windows forms to run on top of the system so that they could use “new windows technology.”
While it’s obvious that this story was intended to be derogatory, from a business standpoint sounds like a success and probably even something that Joel would be proud of.
Rewriting a mission critical system which has been a cash cow for over 20 years is not a small decision, regardless of the technological benefits involved. The company would have to maintain their floor of COBOL programmers, while hiring another team to do R&D using the new systems. The new development team will have the herculean task, of reproducing the code that a programmers have been hammering on for 20 years. After 2 years (I’m being generous this morning) the platform has been re-written. Deployment opens up a new can of worms.
Customers do not like changing platforms. A car dealership with sales team of 5000 people will not look kindly on having to retrain their staff simply because the upstream software provider decided that it was time that they rewrite the underlying code. The clients are faced with the same question as the software development company. “Do we deploy a new system when the old technology has been working fine for 20 years?” Since the clients have a vested interest in not “rocking the boat” and you will probably find a large percentage of the company clients choosing not to roll out the upgrade onto their systems. This will mean that the software development company will need to support both platforms for 3 to 5 years.
So when suggesting such a huge move to company management you are suggesting:
- Doubling development costs for 2 years
- Doubling support costs for 3-5 years
- Embarking on a herculean software development projects (80% of which fail)
- The possibility of clients choosing not to use the new versions
In exchange for:
- A platform built on (currently) modern technology
- Long term extensibility (providing your new code is better than your old code)
- Reduction if future maintenance costs
Embarking on such a move can break an otherwise successful company. Choosing not to rewrite your platform can have long term repercussions on the success of the company.
Not a choice that I would like to be responsible for.