How to achieve higher quality software with audit logs and a no blame culture

This article offers insights into how to achieve higher quality software by working with users and audit logs in an open culture to significantly reduce defects and increase productivity.

We build software by and for people, therefore people are our drivers.

Combining user input and documenting outcomes is an invaluable insight into the working of any system.

Oops! Did I do that?

Users make mistakes all the time. Blaming users is likely to cause any issue to be suppressed, hidden or ignored because of negative outcomes regardless if they are perceived or real.

By encouraging an open culture, questions such as "how can the system be improved?" are likely to be received as genuine help with a positive outcome.  Better still, small focussed study groups offer excellent insights and can offer significantly improved outcomes when there is openness and trust. Imaging the following request in a blame culture and a non blame culture: "Can we closely monitor how you work to help identify and improve the system?". Evaluations will go ahead in both scenarios, but only the latter open culture will gain added insights of our individual foibles. By understanding those human, input and workflow issues allows significant improvements in user experience (UX).

From input validation, feedback and workflow, UX improvements can increase friction when added alertness is required and reduce friction when throughput speed is preferred.

Back to audit logs. They are evidence when examining details that matter. Was the right amount entered, was a box checked.

Oops! It shouldn't do that!

Coding error or misunderstanding of requirements. Software defects - bugs - cover a multitude of potential issues that might cause them. It has always been the case that modular development offers significant reusability advantages, and with increased resources focussing on individual components, better chances of discovering and fixing bugs. Keeping up to date is essential, and this sometimes comes with additional costs of compatibility and upgrades.

By working with users in an open culture, it's easier to understand each others strengths and build a better future.

All software has bugs, some are hard to find, and tough ones even harder to reproduce.

Audit logs provide evidence of what has happened. They are essential for recording an event, then if well designed, by including enough detail to offer insights to rectify any defects.

Activity logging

Activity logging is best designed from the outset. Although traditionally a paper record or a single line text log file, sometimes it's better to store activity in a database so that it can be more easily sliced and diced. When used as part of a user's workflow it's often worth the extra investment to organise it to their specific requirements. UX matters.

It's possible to optimise reach for example using TURF (Total Unduplicated Reach and Frequency) by evaluating literally millions of permutations of elements to find the best combinations. However it's essential to record what was said, when and to whom to avoid missing opportunities, over targeting individuals, and measure success.

Recipients have always trashed leaflets, disposed of letters before reading and in today's world deleted emails before reading them, nevertheless it's essential to log relevant activity. Only by meticulous recording of events is it possible to measure effectiveness, and correlate positive, negative and neutral activity. This type of logging needs to be consciously built into any system.

Supporting many different web browsers and operating systems can be challenging without accurate technical feedback. Except for the most straightforward cases, automated collection and recording of events and technical details is essential for successful support and development feedback.

Examples

What are good examples of everyday audit logs?

Bank and credit card statements are traditional event logs, we may ignore them most of the time but when there is unusual activity or something that needs clarification they are our first point of call. When reconciling treasury activity, it may be essential to detail individual account and also collated summaries.

What are good examples of software logs?

Web servers are good examples of configurable software log files.

Apache web server offers fine grained configurable access to module activity enabling deep insights into how a module is working the way it does.

Django web server has great developer logging and debugging built into the framework. Server errors are usually rare but when they happen it's important to know what caused the event in order to address any issues. By setting an email error handler, it's possible to record sufficient details to identify the underlying cause and take appropriate action.

Most frameworks offer configurable logging facilities, if they don't it's well worth the effort to build one. By knowing what you want to record and why, it's possible to achieve greater things when there's trust.

All software has bugs. Intelligent and open logging can deliver fantastic results.

Activity logs offer evidence of what happened.