Starting Over Might Be Better Than You Think.
If you have worked in the software industry for more than a week, chances are you have reached the point where the only way to fix your software was to throw it away and start over. Chances are equally high that when that happened, the fingers of blame were pointed at everyone around the room. It was the fault of the software developers for writing “bad code”. It was the database administrator’s fault for creating a “bad schema”. It was the product owner’s fault for having a “bad roadmap”. It was the sales manager’s fault for insisting on features that are “out of scope”. It was most certainly the fault of someone who’s not in the room or no longer with the company.
Today’s client is tomorrow’s potential client.
The point that I’m referring to is when the cost and effort to maintain the current software prohibits developing new software to attract new clients. There have been numerous studies and articles written about the cost to attract new clients vs the value of retaining current clients. Without a doubt, it is much easier, cost-effective, and faster to keep your current clients than to attract new ones. It may seem like a no-brainer. If we have software that clients are using, we should do whatever we can to keep them using that software. That is correct, but it might also be short-sighted. Before you scoff at that and go read something else, consider this: Today’s client is tomorrow’s potential client. Just because your software is solving their problem today, it doesn’t mean it will solve the problems they will face tomorrow and in the future. When your software has reached the point of starting over, your current clients are a dwindling resource. It is inevitable that your clients will reach the point where their problems have evolved while your software has not and they will solve their problems with your competitor.
You may ask yourself: “How did we get to this point? What went wrong?” While this may not be easy to hear: Nothing went wrong. Reaching the point where software has grown in an unpredictable manner is the natural result of the software being adaptable. The more easily you can adjust to your client’s needs, the more likely you are to introduce a change that may have restrictive consequences. It takes time for those individual updates to accumulate into an unbreakable barrier, but it will happen. Nothing can live forever and software is no exception. The more agile your process for shipping software updates, the faster your software will reach this point. It’s not a mistake, it is the maturity of your team and business. Could you imagine operating your business today with technology from 15 years ago? Odds are you would have been running Windows XP with Internet Explorer 6. You wouldn’t be able to use Google Chrome for another 5 years. Just as your business grew and evolved, so will your clients. The software they use will also need to evolve.
Reaching the point where software has grown in an unpredictable manner is the natural result of the software being adaptable.
Now that we understand that software sometimes needs to be completely rewritten, how can we all get on the same page? How do we approach the conversation to start over? Chances are if you have had the conversation to rewrite software it started with a software developer. Chances are equally high that the first time a rewrite was mentioned it was met with an “Are you crazy?!” from the business side of the equation. While everyone involved with supporting a client-driven software has the same goal, it is difficult for each team to come to the same conclusion at the same time. The people writing the code and fixing the bugs are the ones who deal with the limitations of the software first. They are forced to get creative and discover workarounds to solve a client’s problem with a software that never intended to solve that particular problem. Support agents certainly don’t like seeing repeating bugs, but if the solution is quick and repeatable, it might be considered acceptable to continue working around the problem. The sales team might not be concerned with bugs that don’t affect their clients or inhibit them from attracting new clients. Product managers might be frustrated that milestones in the roadmap can’t be reached, but client retention is still good so things are okay. There are a lot of reasons why the different teams that come together to make a software happen would not be on the same page, but it’s important for all team members to know how to open up to the rewrite conversation.
Making the decision to start a new software from scratch should not be approached lightly or you run the risk of repeating the actions you took which led you to the rewrite. It’s important to not ignore what has made you successful, to assess your strengths, identify weaknesses, and discover the best path forward.
