A case study in not dealing with legacy software

Published on 2009-02-18 by John Collins. Socials: YouTube - X - Spotify - Amazon Music - Apple Podcast


I heard a story today about a previous company where I worked. While there, I designed and implemented a conference room booking system for their internal meeting rooms in PHP/MySQL. The system proved very popular with staff, so was maintained and upgraded heavily by a small team of PHP developers after I'd left the company. Since then for various reasons the PHP team has disbanded, while the IT department of the parent company will not support a PHP-based application, so there is nobody left in the company to maintain the application.

The problem is, staff love the application so much that they are continuing to use it every day, even though rooms in the building have changed and been given new names! The staff know to mentally map the old names in the PHP application to the new names in the building while booking a room online. So what is to be made of this scenario?

Lessons Learned

  1. A lot of the time, something built in-house is best because it is so close to the end users. This is very agile.
  2. Corporate policy of the parent company is broken, because it refuses to support a wildly popular application, due to the fact that it is written in the "wrong" language.
  3. If they ultimately switch off the legacy room booking system, they will make the hundreds of end users very angry.
  4. If they replace the legacy system with something else, it will meet resistance from the staff using it as they will always compare it to the old system which suited their work flow perfectly.
  5. Re-implementing the system in the "right" language (take your pick) would be a classic example of re-inventing the wheel, obviously a bad thing.

I am sure that this is a situation that has played out many times over in different organizations, and shows a real failure of thinking at a senior management level. Good software should ultimately satisfy the needs of the target audience, and improve productivity for an organization. My old booking room system does both things, and at a very low cost as it is built on open source. The fact that it is written in a language that your IT department does not support should not be a threat to it surviving, instead senior management should be asking their IT department to take a hard look at their skill sets and policies, or at very least take in a PHP contractor for a few days!

Updated 2020 : note that the above post was originally published in 2009, but is left here for archival purposes. Since I wrote this post, the company in question has moved to a brand-new building, so I would be very surprised if this still holds true:   "The staff know to mentally map the old names in the PHP application to the new names in the building while booking a room online."