We don’t just take our customers seriously – we take our customers (literally)… away from the competition by offering a level of customer responsiveness and agility that’s hard to beat. You can track that responsiveness all the way down to the foundation of our business – the code behind our document transformation software.
While there’s nothing wrong with disruptive technology (insofar as it can drive innovation), we like to put a lot of our energies into sustaining technology that ensures that our customers are happy using our products for time-sensitive, requirement-driven processes that will not fail.
Consider the following scenario, as provided by our software development manager Rob Schaafsma. Here he lays out a hypothetical day in the life of a developer:
After months of work, development on your new app is all wrapped up, QA is done, and it’s ready to ship. But wait – what’s this? A last-minute minor addition… the innocuous change is made, incorporated into your build, and the final product ships out the door. You can’t wait for the rave reviews from your customers, the pats on the back from your colleagues, and that huge bonus for bringing in the project months ahead of schedule and thousands of dollars under budget.
Then, a call comes in from Customer X, who has installed the product and is – wait for it – not happy to find that a portion of the application is not fully functioning correctly. What?! QA tested and retested the application, all issues had been resolved. Could this be a case of “the myth of the innocuous change”? But no, that defies logic… How can a small change produce such far reaching effects? What can be done to ensure that seemingly trivial changes to source code do not have disastrous consequences?
Development Process Automation
Enter process automation, more specifically: automated unit testing and automated builds. Let’s assume for a moment that you have 100% source code coverage by your unit test suite, and that you have an automated build process that can get the latest source, build the product, run all the unit tests and assemble an installer. In this revised scenario, the innocuous change is made, local unit tests are run and passed by the developer, and the code is checked in – so far, so good.
That night, the build process starts, compiles all the code for the whole project, runs all the unit tests, and quickly detects a failure in a distant but related portion of the application. The build process automatically notifies the offender that their change broke the build, and optionally threatens to expose their malfeasance unless corrective action is immediately taken. The end result: 99.999% confidence that your last-minute change can indeed be incorporated into the product, without risk.
There are many benefits to process automation in software development. Repetitive and error prone tasks are configured once and run many times in exactly the same manner, no matter who kicks off the process (or who may leave your organization). Knowledge of how to test and how to build is built right into your product. Impacts of change can be quickly and easily assessed and issues are caught very early when it is cheapest.
To realize these benefits, Adlib Software uses Microsoft Visual Studio and Team Foundation Server for automated unit testing and automated builds. We’d love to hear about the tools you are using, and perhaps your anecdotes on how these tools and processes have helped you.
About the Author