Dealing With Existing Systems

Starting fresh with a new custom application or solution is the ideal situation. There is no existing data to translate and import. We can build the solution the right way from the beginning. But the world is not ideal. We get to transition from old and clunky software systems or systems that are mid-development that simply do not work correctly.

It’s amazing how often we are called upon to clean up the mess that another less experienced developer has left. Companies in their attempt to save money end up spending a lot more in the end. First, they pay many more hours than necessary to get something completed, then the developer bails because the project is over their head or the client determines that progress is not being made fast enough or not at all.

Here’s one nightmare example: The previous developer worked on a system for over a year. During this time, he took away access to their existing software solution. So the client was without any technology to support their business for over a year! When they finally realized that the project was doomed, we were hired to fix it. We rewrote the entire system and had the new solution up and running reliably in less than 5 weeks. If we had been involved from the start, we would have architected and delivered the solution under budget. We would also have built it in parallel so that they would have had an application to use during the development time.

Have you ever seen the home improvement shows where they flip an old house? They start with a plan and a budget. They see what needs to be done on the outside and it looks doable. Then the drama begins. They knock down a wall only to find it was a supporting wall that requires new support beams to be added. Then they find out the electrical in the wall was not built to code and posed a fire hazard. The plumbing is all cracked or leaking. The foundation of the house is crumbling.

Redoing all of this completely blows the planned budget. The homeowner needs to make new choices about what else can be done just to complete some of what they had originally planned. This kind of reprioritization of is common in tech projects that deal with existing systems. It needs to be done unless you have an unlimited budget.

We built a house and found the process largely frustrating. The reason? Everything costs money. There were hundreds of options and choices all with varying costs attached. The process would have been a lot easier if money was no object. But we nearly all have a budget. The constraints imposed by that budget force us to make the difficult decisions.

What are the options?
1. You could tear down the entire house and start again. In our software scenario this is like throwing out all the original code and rewriting from scratch. Sometimes this is the best plan. More often than not it’s too expensive so the budget prevents you from doing the right thing.

2. Rebuild and update as required. In the software world this is called enhancing and refactoring. Refactoring improves the design of existing code for easier maintenance and making future enhancements easier and less time consuming. Often this needs to be done in stages improving with each iteration. The tools change as well. New commands become available and there are better ways to do things than were available at the time the code was written. This also requires rewriting.

 

Working on an existing system written by someone else requires reverse engineering. We need to try to get into the brain of the original developer and figure out why they did what they did and how they had planned it to work. Often we find there wasn’t a good design, no plan, no blueprint guiding them…and that makes reverse engineering more time consuming and difficult. We come in without any documentation to guide our view of the system. Building that documentation as we go helps but it can be time consuming.

Ease of maintenance of the system is directly related to the coding ability and talent of the previous developers. There are a lot of poor coders out there…proportionately more than good ones. Fixing their mess takes time. Often they were not using best practices. We’ve documented many best practices on our blog for other developers…but many don’t take our advice seriously. They get fired and we end up doing it the right way in the end.

In any case, it is really difficult to predict or estimate how long this work will take. All the experience in the world can’t account for running into a complete unknown that changes the scope of the work that must be done. We always recommend the best path that we believe will get you the results you need with the least amount of work. We’re fortunate to have a good queue of work built up so have no need to draw out the process and make it take any longer than necessary.

We know a developer that starts out his projects with the following disclaimer: “At some point in this project you’re going to hate me.” Then when they run into these kinds of surprises, he says “Do you hate me yet?”. The point is, technology projects are often frustrating. The budget is often the sticky point. We do all we can to make it a smooth process. We will always recommend the best plan of action that will get you the features you require within a given budget and time frame. Knowing your budget up front can help us to provide the best solution. For the record, our customers don’t hate us.

So what can we learn? Maybe the lesson is to expect the unexpected. Plan to have more budget available than you think you will need to complete the job and get it done right. It’s just the nature of the beast. In the end though, ROI can be incredible on well architected systems that have been designed and documented. That’s what you’ll get when we’re done with a project.

Bad developers are incredibly expensive. Good developers just charge a high hourly rate.