Old App blues...
I'm currently working on a very large project that involves re-writing a bunch of apps that are part of a suite of applications and this suite is being used at multiple sites. These applications were written in the early 90s I assume, probably version 4.5? But this thing is full of hard coded references to many of the other databases and hardly any of the code is reusable in any way. Also, there are little pieces of code that reach out to these various databases from the various databases. So you may change something in one app and break god knows what in another app. Also, coding practices within these apps are very poor. For example, a variable is set to the value of another variable that got it's value from another variable which got it's value from a field in another database and so on. To say the least, this whole thing has been nothing but a mess, a rather big mess at that.
But the team I'm on developed a brand new version of one of the applications because that would be faster and more cost efficient than fixing all the hard coding. The old app had some of the design elements that are based on the data within the app, so if the data changes the design has to change. But this new app we developed had a more modern user interface, more features and if data changed the design didn't have to change. Nothing was hard coded and it is very configurable to operate the way the customer wants it to operate. We deployed this app and it has been being used for a few months now, which of course has a few months worth of new data in it.
Fast forward to today, the customer now wants to roll back to the app that we didn't remove the hard coding from, change the design elements to match the new data and change the hard coding to still be hard coded but work for the current site. This decision is based on the behaviour of one button and one feature. These are things that can be changed rather easily. I've never experienced a customer wanting to go back to a design that's impossible to maintain, performs poorly and by today's UI standards is butt ugly. They're going to end up paying twice as much as it would cost to just fix the few issues they have with the new version, not to mention the fact that they already paid for the new app which is now being trashed. Also by doing this, the other apps that interact with the new app will now be broken and have to be fixed, it's a rather nuclear reaction that results from this decision.
But what I really don't understand is, from a business point of view, why a decision like this would be made? I assume they've already paid a couple of hundred thousand dollars on this project (salary for a team of 4 developers, 2 project managers, among others for the past 8 months) and are getting ready to dump even more money into it by making the decision to go back. I'm just dumbfounded as to the reasoning behind this. We probably could have re-written the entire suite with this much man power and time for much less money. I may be wrong for posting this rant, but I'm hoping someone can provide me some of the reasoning that I'm obviously missing.
On another note, I'm currently working on a new Open Source project in my spare time, as code starts to come out for it I will post more about it. But for now, I'm going to keep it under wraps at least until I have a workable demo to highlight the initial idea. So, stay tuned for a useful (I hope) freebie in the near (again, I hope) future.
Comments
Date: 06/10/2009 09:09:02 PM
Name: Keith Brooks
Website: http://www.vanessabrooks.com
Never question the wisdom of Executive Management for it proves a Fool exists.
There are budget reasons, politics, new or changed leadership which has their own axe to grind(wants to move to MS or something) and well you get the idea.
I have seen this too and it's because, believe it or not, you exceeded their dreams and they thought you would come back and drop it in their lap.
Basically they don't want to look that good, or bad, as the case may end up.
A million Dilbert strips are coming to mind.
Date: 06/11/2009 12:39:02 AM
Name: Nathan T. Freeman
Website: http://nathan.lotus911.com
Two scenarios: 1) You didn't charge enough for the original app. So the project didn't have visibility at a high enough level in the organization, and so no one at a senior exec level thinks it's a success; 2) You *did* make an impression higher up the chain, and ran into someone that has some ulterior motive for the project not being a success, and is therefore calling for the rollback. This isn't necessarily a "political" decision. It could also be a perception of risk, or an expected training cost, or an imagined future dependency on the new system when they have visions of moving to an SaaS solution or something.
These are all real motivators that tend to get chalked up to "politics," but are really just about having the wrong people in your corner.
Find a champion that can override the rollback request. Or, take the money and run. And short their stock.
Date: 06/11/2009 06:02:14 AM
Name: Henning Heinz
Website: http://
Well if the app is in use that long people probably use it longer than they are married. Their children grew up slowly but their app completely changed in a few months. I am not saying that you did something wrong but from my experience dealing with very old applications still in use and considered worthwhile is hard work and it does not always end the way you expect it.
As for the business point of view. I often deal with customers that have a fixed budget. If they don't spend it they will get less money the next fiscal year (although they might get a bonus). Less budget often coherent with less power and influence. As long as there is still budget left it has to be spend. Even running out of budget is not so much of a problem if you can sell the importance of your efforts. All huge things run out of budget.