If you’re in charge of the decision making process for custom software that your company depends on, you may at some point have to decide whether you need to make significant changes to your solution.
This could be anything from simply modernizing an existing codebase to starting over completely from scratch with a new technology stack.
The challenges that you’ll face will greatly depend upon your comfort level with evaluating a given technology. If you haven’t done a lot of coding yourself the answer may or may not be obvious.
One example of this was micro services. Several years ago there was a huge push for micro services as the answer to all software problems.
The reality though was much different. For some companies it made sense, while for others it created additional layers of complexity which were expensive to maintain if not consciously designed.
So the question ends up being, how do I know what path to take?
That’s why I wrote this guide. By asking you a series of questions and providing you with a framework for evaluation, I can you help you significantly reduce your level of uncertainty and therefore make a decision.
So let’s get started!
What path do I need to take?
As a decision maker, what you need is to be informed.
Start off by analyzing what the challenges you’re facing with your current custom software. What aren’t you able to do? What are your current and near future business objectives? What day to day needs of your organization are not being met by your current custom software?
Equipped with this knowledge, it’s time to have a conversation with a programmer that’s knowledgeable about your codebase or another technical stakeholder who at least knows it well enough to answers your questions.
Now is the time to open a line of communication with your programmers (and other technical stakeholders). Let them know that you’re interested in well informed, pragmatic feedback. Tell them not to pull their punches.
If you’re unaware of what the state of your codebase is ask them directly. While this question can be a bit subjective, a skilled programmer should be able to put aside their preferences to give a fairly objective answer.
Don’t have a senior programmer on your team that knows the codebase well? Then consider hiring a consultant (such as a software architect) to have a look and provide a comprehensive report before proceeding any further.
The overall state of your codebase will be the determining factor in whether or not you should; stick with what you’ve got, make incremental improvements over time, or scrap everything and start over from scratch.
Non-technical employees should not be making this determination.
Just as we wouldn’t want business majors engineering bridges, subsequently we don’t want non-technical staff making important technical decisions.
That’s not to say that non-technical stakeholders should be left out of the decision making process. On the contrary, your input is both necessary and desired. However, when it come down to the technology of choice or how that technology is initially implemented, that’s better left up to the technical stakeholders.
As mentioned previously, if your organization does not have the internal technical resources to make this determination, I would highly recommend that you engage the services of an external software architect or engineer.
There's no universal solution
There are business and technical stakeholders alike that are so invested in the idea of using a particular technology that they truly believe it’s going to solve all of their problems: a universal solution, if you will.
The truth on the other hand is far more nuanced.
Every technical decision has its drawbacks. Some solutions have extremely high maintenance or adoption costs. Some solutions are so obscure or bleeding-edge that you’ll be hard-pressed to find a developer. Some solutions produce rapid results but provide diminishing returns or even outright setbacks in growth months (or even years) after implementation.
There’s always a compromise. I cannot stress this enough.
So if that expensive conference you just got back from sold you on a specific technology that they claim will solve all of your problems…
Proceed with caution.
Make sure to do your homework. Take the time to actually do the legwork and figure out if the juice is really worth the squeeze.
What are the pros and cons of using this specific technology?
Don’t just assume. Spend the time to conduct a full evaluation with your team by utilizing this technology is small sample project. If you don’t have the internal technical expertise required to do this, consider hiring someone to provide guidance based on your particular business needs.
Whatever you do, try to avoid technology “evangelists” who recommend the same technology for every single project they work on.
There’s no such thing as a universal solution.
The time to start over
In my fifteen years of professional experience I’ve seen a number of companies make the decision to start over from scratch. While these companies codebases and technical challenges may have been quite different, their motivations on the other hand looked incredibly similar.
Let’s take a look together at a few of the most common ones;
In all of these scenarios, starting from scratch is almost always going to be the more prudent decision from a business perspective.
In fact, I can only think of one scenario that may prevent you from moving forward with starting from scratch: Internal resistance to change.
If you your own development team provides significant pushback anytime you bring up the idea of making improvements, then you may face an uphill battle.
In my experience this often comes down to egos or people feeling like you’re overstepping your own expertise. Unfortunately, this often prevents the team from working together in unison towards a common goal.
When it's not so clear
Sometimes there are situations where the path isn’t quite clear. Perhaps your custom software isn’t giving you a lot of headaches and you could develop new features or functionality without too many problems.
Perhaps a new technology comes out that does have significant advantages, but your team just isn’t acquainted with it.
This is when choosing a particular path is difficult.
You could be more inclined to just continue doing thing the way you always have, but your codebase is now beginning to show it’s age and worse yet it’s keeping your company trapped in the past.
Conversely, you may choose a more modern technology stack that has significant advantages (supposedly), and then end up having to deal with a lot of features that aren’t well documented or updates that happen so fast that you end up devoting too much time to managing everything.
It’s far too easy to get stuck in analysis paralysis and not do anything. A good place to start is by taking an inventory of where you’re at:
After you performed this assessment, you’ll be in a much beter place to make a determination about the best path forward.
Wrapping it all up
Whether you decide to stick with your existing technology stack, modernize it, or rewrite your custom software from scratch – I hope this guide has armed you with the knowledge you need to make an informed decision.
If you still have questions or are feeling uncertain about the best path forward, please don’t hesitate to reach to me directly.
An experienced software architect can make all the difference.