When is it time to rebuild your app?

[MainSpring 0]

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.

View the full article