One of my college professors used to say that good software developers create software for today, while great software developers create software for tomorrow. That was the kind of advice that rings hollow when you are a computer science undergrad trying to finish a class project that you know will never see the light of day ever again.
A few years later and now I have enough experience to understand what the professor was trying to say. When we create software we are trying to solve a problem, mainly, by turning someone’s vision into a programmatically functional algorithm. That product doesn’t exist in a vacuum. It needs to grow, change, and adapt as the vision changes and the world around the software evolves.
Some of you might be familiar with WordStar, a word processor that governed the market from the 1970s up to the end of the millennium. It was a fine piece of software that by all modern standards is extremely outdated. In fact, it would be rather unknown in mainstream culture if it weren’t for the fact that George R.R. Martin of “A Game of Thrones” fame, still uses it to write his books.
WordStar is a perfect example of what I’m talking about. It solved a problem back when it was created, and for all intents and purposes, it still solves it. But the world around it has evolved. Getting it to run on modern systems is painful at best, and it lacks features that by more modern standards are a given.
The point is that software is never truly done. I could grab the WordStar source code and upgrade it to run on modern systems, but what if the code was built in such a way that it relies on slow processor speeds? Or if for some arcane reason could only save data to a diskette? The more quirks like that, the more work it would take to upgrade the software to modern standards.
When we write software we should always write thinking about the future. We make it flexible so it can scale with ease, and we comment on our code so we can return to it in the future. We write good documents for our users to help them learn about the software when we can’t provide support. And we build software to make it auditable.
What Is Auditability?
Auditability is the ability of an auditor to achieve accurate results with low effort in the examination of a product. The term is mostly used in financial environments, but in truth, it can be used to describe any process in which we are trying to determine something about our business. Audits can come from within our company or from an outside agent. For example, consulting services often audit our processes to find areas of improvement, and government agencies audit our businesses to assess if we meet compliance.
What can be audited in terms of software development?
- Code
- Software outputs
- Databases
- Hardware
- User information
- The development cycle
- User access and security
- Compliance with national and international laws
While it would be extremely difficult for a developer to cover all possible bases, some general principles can help foster auditability.
Documentation
Always make documentation a core part of your software development life cycle. Exhaustive documentation will save you hours of headache when an auditor wants to know what a specific function is doing—or even when you are returning to a project after a long hiatus. It’s a two birds, one stone kind of situation.
The point being, for many people, auditor included, documentation serves both as an introduction to the software and a window into the mind of the development team. For everything horrible I could say about R, I always found it very responsible that most R libraries mention the equation they are using and point to an academic source. For an academic reviewer, that makes the process a lot less cumbersome.
Keep Records and Backups
Less related to the software itself, but equally as important, record your development process, from simple things like dates and meeting keynotes to more involved information like the decision-making process for prioritizing certain stories above others. Your registry will help outsiders understand how the process unfolded.
This is very important, especially with problematic projects. Good record keeping will help you audit the whole process and pinpoint possible reasons for the project falling off the tracks. The opposite is also true: Records can help you understand why a project went especially well and how that can empower future endeavors.
Some tools already have excellent record-keeping features. For example, both Amazon and Azure excel at tracking and predicting costs. In both cases, it’s extremely easy to figure out where each expense is coming from. Make use of these features extensively.
Be Wary of the Legalese
Few people know just how much goes into creating a compliant product. For third-party solutions, we have to keep a strict record of each license as well as the limitations involved (and that includes open-source software). Something as simple as installing more clients in your office than allowed by a license can be a headache down the line.
User data is of special concern. Ask anyone who had to live through the GDPR process just how overwhelming user privacy can be. Not only is it extremely important that you keep track of all the legal requirements, but it can also help a lot if you build functions in your code that can help others audit if you are meeting those requirements.
Foster an Audit-Positive Culture
I’ve been part of audits more times than I would like, so I know how nerve-wracking being scrutinized by a third party can be, especially when they have little understanding of the software development process. That kind of situation isn’t uncommon, and it has given audits and auditors a bit of a bad reputation.
Having said that, these processes can be extremely positive for you, your team, and your project. And to be perfectly honest, audits are pretty seamless if you’ve done your homework. Talk with your team and help them understand that writing good documentation, keeping track of everything they do, and sticking to the legal constraints of the project may be extra work at first, but it will save time down the line.
Create KPI based on audit-positive behaviors and offer incentives such as bonuses or rewards. This serves as a gateway toward building these behaviors, and then, when the audit comes and you pass with flying colors, the team will realize the benefits of this approach.
Thinking Outside the Computer
Regardless of the memes, software development isn’t a solo activity. We are constantly communicating with the outside world, be that our managers, our clients, or other third parties. When we do our work with auditability in mind, we are building tools to effectively communicate with the outside so that others can understand what we are doing and provide feedback to create a better product.
