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.
About the Author
