Blogs

One of the most common software development paths is the waterfall: requirements specification, design, construction, testing (validation), integration, and maintenance.  Today it’s largely presented as a flawed model, as “there is work left to stabilize the release such as resolving conflicts in component integration, executing detailed tests, and performing a successful deployment of the software to appropriate platforms.”

The art of implementing an electronic records management system includes a strong focus on a quality experience for your user community. Traditionally, quality considerations are delayed against gathering technical requirements, which often for us Records Managers is the inventory phase—that’s our version of defining requirements, through the taxonomy. Bad idea. This is your software, your reputation, your investment. Bug triage is not going to cut it. By bug triage, I mean the post integration and maintenance phases in the waterfall.

The rule of thumb is rather simple: the longer it takes to validate an application’s build, the more likely it is that quality will decay because of lack of feedback. In other words, Records Manager, if you wait to validate your customer’s preferences, you have serious quality debt. This is the heart of an electronic records management software implementation.

All is not lost, however. Mr. Sterling tells us that quality debt in an application is detectable. The list of indicators include:

#1. Lengthening regression test execution. How long does it take to execute regression testing? Old joke: the more code, the longer it takes. The answer is quite simple, really: ensure that the development environment mirrors production as much as possible. Don’t wait to execute performance, stress and load tests.

#2. Increasing known unresolved defects. Another simple one: the number of defects will increase as the development team creates more defects, in turn creating a contaminated production environment from which there is no recovery with the user community.  Infer your own disaster scenario here.

#3. Creating a maintenance team for production issues. Oftentimes companies will place the team in charge of both pieces—production environment maintenance and bug resolution. Mistake. Nothing should distract the production team from stakeholders’ requested features. There should be two teams—and it’s a perfect opportunity for us Records Managers to cycle from one team to the other. The Records Manager is then in the perfect position to advise on the velocity of reduced feature delivery, automated tests to fix defects, and a production issue workflow assembled to handle different severities. Imagine the happy faces when you tell everyone that only one list of work need be maintained!

Thanks to the above indicators, you the Records Manager will be competent enough to recognize when it’s appropriate to use a technique called Acceptance Test-Driven Development (ATDD).  The ATDD approach is a “test first” technique that allows teams to architect design, implementation, and test cases as they’re capturing business requirements. In other words, it is a holistic, iterative approach. Software design drives what’s important to the user. For Records professionals especially, nothing’s more important than the user community trusting us.  Your message will be, “I hear you and you’ll see it reflected in your business application.” It doesn’t get much better than that.

Thanks to Chris Sterling for his excellent work, Managing Software Debt: Building for Inevitable Change”.