One of the calling cards of poorly or hastily developed custom software is lack of flexibility: it cannot easily be reconfigured, enhanced or adapted to changes in your business. Rigid software can make adapting your application to evolving business needs extremely time-consuming and expensive. In fact, sometimes it can be more cost effective to consider a “rewrite” than to pursue costly maintenance of inflexibly designed code.
Here are three techniques you can use to improve your software’s flexibility:
- Configuration files – most applications make use of environment settings that are subject to change, such as server names or email addresses. These values should be stored in configuration files where they can be easily modified, not embedded in the source code of an application. Configuration files can also be used in more advanced ways, such as listing the names or locations of code libraries that the system can use to modify or extend its functionality. This means migrating to that new email server takes 15 minutes to update your app and zero down-time, as opposed to hours of coding and an over-night re-release of the software!
- Code abstraction – say an application is being written for a car dealership that currently only sells Fords. The developers could probably save a little coding time by assuming that all cars in the system will be Fords. But with a little extra effort, the application could likely be made to support cars from all manufacturers. The benefit is that if the dealership grows and begins selling Hondas in addition to Fords, the code would not have to be modified or redeployed (NO COST!). Creating code that supports general concepts (automobiles) instead of specific instances of those concepts (Fords) is called code abstraction.
- Regression testing – even with the best development practices, it is always possible that new bugs will arise (or old bugs return) when an application is modified, and most businesses would prefer that bugs be “caught” by the development team, not by end users, where errors are much more costly. If unit or functional tests were created during development to make sure the code worked, then re-running all of these tests to make sure no part of the code that was previously working has been broken can be a great way to achieve this preemptive bug detection. Such re-running of tests is commonly referred to as regression testing.
Entrance uses these three techniques as part of our rigorous development methodology to ensure that we deliver high-quality cost-effective solutions that are relevant to our clients’ unique business models. If your software is showing signs of inflexibility, please contact one our experts to set up a consultation.
In summary, if your software does not adequately employ configuration files or code abstraction, then the chances that it can be readily and economically adapted to new environments or business problems are pretty slim. Furthermore, without regression testing, it will likely be your end users or customers that first experience the bugs resulting from application changes, not the development team. If you wonder about these things, ask your internal development team:
Do you use configuration files in my software and if so, to what extent?
How do you use abstraction in our application?
Are we currently doing automated regression testing before we release updates?
Our Expert Software Audit can also help you identify any weaknesses your application may have in these areas and others (Security, Scalability, etc.).