Technology, Teacups and Testing
In the world of internet software, nothing stays the same for very long. Every day there are new tools and technologies that promise to make building web apps faster, cheaper and more fun. If you're always building new apps from scratch, this is great - life gets better every day.
On the other hand, if you're maintaining an existing app, the corollary is that every day the technology it's built on can become slower, more expensive and more painful to use, compared to the current state of the art. Eventually, when the older technology stops being supported, it needs to be replaced.
Upgrading a web app's underlying technology is a bit like the tablecloth trick, where you whisk away the linen without disturbing any of the china. It's always best if none of the fancy teacups get smashed, and ideally the only thing the dinner guests notice is the lovely exposed wood grain. But if they're all in tuxedos and ball gowns, it can take nerves of steel.
Many of the projects we do at GORGES involve completely rebuilding an existing application on a new technology platform, because the old technology is not meeting current needs - it is no longer supported, or it doesn't run on the web, or it doesn't support mobile devices.
In lots of other projects, we periodically do incremental updates of the existing technology platform - Drupal, for example, or an application framework such as Yii, Ruby on Rails, or Angular JS. Updates are necessary to patch security holes, and to benefit from bug fixes and new features. Each platform also has numerous dependencies - Drupal relies on a vast ecosystem of contributed modules, and most "full stack" application frameworks are integrated with core third-party libraries such as jQuery, so to keep all the parts working together you need to do regular updates.
Whether we're doing a complete app rebuild or just a refresh, there is usually a desire to improve functionality and add features, while replicating existing functionality. Most importantly, we need to preserve the valuable data that has accumulated over the years.
So, the biggest challenge we face on many projects is not just designing cool new stuff, but preserving important old stuff at the same time. This is true not only of large-scale legacy migration projects, but of the ongoing development work we do every day - any time you change software code, there is a risk of breaking something. Developers need to be able to make changes without creating bugs in the process.
There are several standard tools and techniques that developers use to manage change - for example, version control software such as Git, which records a detailed history of changes to the source code over time. But the most important technique, without a doubt, is having good testing tools - ideally, a suite of automated tests. By creating tests that can be run repeatedly with minimal effort, the developer gains the freedom to make changes to the code, knowing that the impact of each change can be easily verified. Because verification is easy, it can be done after each small change, so that any breakages can be caught quickly and fixed on the spot. To return to the tablecloth analogy, it's like being able to go into slow motion and spot any tippy cups before they head for the floor, so you don't end up with a crunchy mess.
Now, creating effective automated tests, especially for a legacy app whose functionality may not be completely understood, is work in itself - and it may not always be practical, depending on the nature of the application and the project's budget. Sometimes complete automation is not feasible, and semi-automated or even manual testing is all that is practical. But whenever possible we create a systematic suite of tests, to provide feedback during the development process and ensure quality in the finished product. And as the app continues to grow, the tests must grow as well.
The hardest part of software development, especially in the internet age, is dealing with change - whether it's in the supporting technologies or in customer requirements. Having an effective testing plan is a must - otherwise it's like juggling your best china with no do-overs.