When is it Time to Rebuild Your App?

The reincarnation decision

Whether it’s from age, functionality or neglect, all software eventually reaches its end of life. When we approach custom software with a client, we normally will evaluate several factors before deciding whether our engagement will be simple support, light rebuild or even a complete ground up reincarnation. Here are some of the factors we consider:

Cost

Cost is the factor that clients are interested in hearing our thoughts on; But it’s also one of the most difficult things to estimate. We’re firm believers in continuous improvement, but in order to get to a minimum viable product to be able to improve on, sometimes it will cost more to fix an existing app versus starting again from scratch. Our considerations on cost then steer towards:

• Is it going to cost more in the long run to get
  to where we want to be if we must tread through an existing legacy application
  first?
• Knowing what we know now about the necessary
  functionality, how difficult would it be to start over?
• Is there an opportunity to improve the quality
  of all features and the database contents through a ground-up rebuild?

Age

Age is the next factor we look at. This can lead to numerous issues in custom software, as the older an app gets, the higher likelihood that it has somehow been fragmented in some way from the original design and vision.

• When was the app first developed? Who developed
  it?
• Has it been converted from very early versions
  of platform software, like FileMaker version 7 or older?
• When was the last time the app received minor and
  major updates? Who developed those changes? How were those updates requested
  and documented?
• Has the software been updated by many developers
  over time, or just one?

Functionality

Functionality assessment is an important part of the decision as well. If there are many functions of the software that are not working properly, then it may be an easy choice to start fresh and develop new functions that work. Unused functions can clutter the app and also become dangerous dependencies during future changes.

• Do users frequently complain that functions
  don’t work properly?
• Do users complain that performance is slow?
• Does analysis
  show a lot of items in the UI and schema that are broken?
• Is there a lot of functionality that sits there
  being unused?

Data

Data is one of the last things we consider, but also the most important. After all, most of the apps we develop have a pretty major database component underlying the interface.

• What are the current backup and record archiving
  strategies?
• Are there orphaned records in sub tables where
  parent records were deleted?
• Does the data schema represent performance
  minded design (reducing index, calculation and summary fields)?
• Are there tables that are not in use (zero
  records).
• Are there fields that are duplicated, redundant,
  poorly named?
• When was the last time the app was compacted?

After considering factors like these, it’s time to make the
choice! Sometimes it’s ok to choose to just provide basic support to keep
things up and running. Other times it makes sense to approach a new project.
It’s an exciting prospect that can also make many people nervous. Documenting
and researching a system to make an informed decision on how to proceed is a
great first step.