One of our startup clients recently hit the big payday: They were acquired. It was a gratifying conclusion for us, too. We helped them tame their custom-built apps.

Our partnership began several years ago, when the firm asked us for a consultation. They had built their business-critical custom software and related systems with a mix of in-house programmers and disparate contract developers. They had a very compelling business model, but the hodgepodge of software prevented them from growing. The business was drowning in manual processes, bug fixes and unreliable delivery of software enhancements. They knew they had a problem, but they were stuck. They hoped to fix the existing software and avoid starting over. 

When companies come to us for a software consultation, they often do so because of a growing sense of uncertainty and concern that they may be in trouble. We’re typically a last resort, after failed efforts to manage the problem(s) themselves.

They may or may not have pinned down the source of their pain. Maybe they’re too dependent on a single person. Sometimes they’re frustrated because software updates have slowed or stopped. At a deeper level lies the lingering fear of rewriting the custom software in which they’ve invested so much time, money and creative effort.

Custom Software Rescue vs. Rewrite

The instinct to fix instead of rewrite custom software is completely understandable. No one wants to write off a significant investment in their current software. No one likes to throw away time and money. Starting over seems like a non-starter.

But the investor and managerial instinct that resists starting over tends to conflict with the effects of age on software. This conflict can be summarized across six specific fronts:

• Development Resources – Most experienced programmers prefer to work in their own code and systems, which they understand deeply and can work in most efficiently. Over time, the cost-to-benefit of working on aging software just doesn’t add up, and the availability of its developers has faded in favor of other priorities.
• Poor or Missing Documentation – Without software specifications, requirements and technical documentation, a new programmer must read raw code to extrapolate business logic. This laborious work is hard to explain to a client desperate for a quick solution to a challenging software problem.
• Poorly Structured Code – A programmer given poorly structured code will spend a lot of time reading and deciphering the functions that make the program work. Very little custom development is truly novel, yet it is common to find software built with unique nuances and non-standard techniques. Efficient software development leverages best practices and established software patterns. This allows fast onboarding, reduced risk and predictable results when subsequent developers start work on the codebase.
• Old Technology – An old, poorly supported custom software platform will be hard to troubleshoot and practically impossible to update. Most good programmers follow and carefully adopt new platforms and technologies. They constantly look for better ways to build apps and keep systems and code up to date. Programmers who take on antiquated technology sign up to work in risky, fragile and inefficient ways. This can frustrate both the developer and the client. As software ages, the cohort of developers willing and able to work on it shrinks.
• Dependencies with External Systems – A trend toward integrating custom systems with external systems has taken hold in the last decade. This approach provides businesses with new automation strategies, reduces manual-entry processes and enables complex workflows. But this approach also incurs hidden costs in ongoing management. Without careful checks and measures, integrated systems can devolve into a house of cards; a single, seemingly simple change in an external system can bring everything crashing down.
• Technical Debt – Technical debt refers to the cost of deferred maintenance. Ideally, software is actively maintained. Bugs are squashed without prejudice or delay, customer feedback is carefully and strategically folded into the system, and everything is configurable, logged and redundant. In reality, though, the development lifecycle faces pressures related to feature priorities, project schedules, unclear or conflicting requirements, human error, component obsolescence, and dependencies on systems outside the realm of control. Over time, these pressures add up, resulting in higher costs, higher risks, and slower or halted development. Technical debt has a big impact on operational costs, yet remains unmeasured and unmanaged in most organizations.

We often see all these concerns come into play during consultations. Our critical concern is to measure the client’s desire to move forward with what they already have against the potential efficiency of starting anew. At Northwoods, we pride ourselves on being our clients’ digital best friend. Job One is to help them understand their current state and to clarify the challenges and opportunities of each approach. The decision process varies widely based on each client’s unique circumstances, but careful weighing of all options always pays off.

The Custom Software Rewrite Process

When a complete software rewrite appears to be the best choice, the next best step is discovery/analysis. Our discovery process often includes full ROI analysis. This can lead to project savings for the rewrite, by tightening up scope, for instance. This step commonly adds value through broad-stroke strategic discussion.

Typical deliverables include proofs-of-concept, formalized requirements, road maps with pain-points and wish-list items, process documentation and diagramming, complex system-dependency diagramming, and even detailed legacy software assessments.

When a Full Software Rewrite Isn't an Option

The decision to fix the software you have or to rebuild it from scratch isn’t always clear-cut. You may need to change one part of your system while leaving the other parts intact. A couple of recent examples of a hybrid approach come to mind:

• A large manufacturing client of ours was losing support for its very old database. The systems and components that depended on this database included apps, workflows and websites - none of which could be changed. After initial discovery work, we arrived at an approach that provided safety for the dependent parts and allowed them to safely update the database system.
• Another client needed a commercial web application rebuilt. We found that it relied heavily on a core set of business logic deeply buried in an old web application. This was complex and fragile, but we were able to systematically pull the business logic into its own Application Programming Interface (API), which accomplished three critical things:
  • First, it provided safety and eliminated most of the complexity on the web development side.
  • Second, the API itself stands alone, and can be upgraded independently over time.
  • Third, due to the nature of APIs, the critical legacy business logic is available for use by other applications, systems or workflows.

A hybrid approach isn’t right – or possible - for every organization. An experienced software developer can help you understand what’s doable and what’s not.

Take Our Custom Software Self-Assessment

If you’re pondering whether to fix, rewrite, or strategically overhaul custom software, our Custom Software Self-Assessment - based on our top 10 software and app development best practices - can help.

For each attribute below, score your results as follows:

• 0 Points – No, and the developer has no answer when you ask.
• 1 Point – No, but you understand the question and it is being worked on.
• 2 Points – Yes, but you don’t fully understand how.
• 3 Points – Yes, you are comfortable that this is being done and understand how.

Download a PDF of our Custom Software Self-Assessment Tool.

How to Understand the Results

• A perfect score = 30 points. Few organizations will score a perfect 30 but a score in the mid-20s indicates you’re doing well. 
• A score of less than 20 points indicates a problem, and a consultation with an external vendor is recommended. (It’s wise to discuss options before you’re in a critical situation, so you have time to decide on rescue vs. rewrite and to plan ahead.)
• If you score 0 on any attribute, address it immediately with your custom software development team.

We recommend taking this assessment at least once a year, so you’re never in a position of making an urgent decision to either fix or rewrite your custom software. This process of quantifying your software environment will help strengthen a shift in your organization toward the modern DevOps disciplines of continuous-improvement/integration/delivery (CICD), which promotes incremental, frequent improvements and quality checks to keep your software up to date and fine-tuned.

If you face the difficult decision of rescuing or rewriting your custom software, give a seasoned software developer - Northwoods, for example - a call for a discreet evaluation. The right team can give you the information you need to develop a solid roadmap for the future of your software.

To request a consultation with our team, contact us here or give us a call at 414-914-9102. 

If you face the difficult decision of rescuing or rewriting your #customsoftware, here's why a software consultation is important, what to expect, and a helpful self-assessment to identify potential areas of concern: http://bit.ly/38WoJjv. @northwoods