What Makes "Good Software?"

In the nearly five years since I changed careers to become a full-time firefighter I have kept my distance from developing software of any consequence. To be honest, I had lost my desire to sit at a keyboard and relished the chance to spend my time in other ways. Sure, I've made the switch from Linux to FreeBSD, written a few scripts here and there, created a wiki for firefighters and even dabbled in automated stock market analysis for my own interest but I have otherwise turned down for-profit programming gigs in favour of freedom to spend my time elsewhere.

Although my day job as a firefighter has little to do with software development my prior experience building software has come in handy from time to time. In late 2015 I began working on a couple of small programs to replace a shared spreadsheet used by firefighters to record productivity metrics. Using the old system, only one person could enter data at any given time and it was too easy to accidentally wipe-out changes made by others. To solve this problem, I created two small programs using VBScript and HTML Applications as the foundation. Both of these scripts present simple, domain-specific interfaces that make sense to the users and hide the relative complexity of Excel by recording data in spreadsheet files in the background. One script allows users to record productivity information and the other generates a report from this information for use by management-level personnel. The program went live after about 80 or 90 hours of design, development, end-user documentation and testing. It solves all of the problems of the previous system, is simple to maintain and runs with minimal dependencies. It was distributed by placing a link on our intranet that opens a folder where the relevant scripts can be double-clicked and launched. Since it launched I have received a great deal of feedback that indicated that users were happy with the new system and that it ultimately made their job easier.

Recently I began to develop another piece of software. This time we're dealing with the management of annual hose testing information. The problem is significantly more complicated than the previous project which merely dealt with the recording and reporting of numbers for different categories but I'm hopeful that goals of this project will have similar positive results for the fire department.

As I found myself back at the keyboard for the second time I have begun to think about the considerations that will ensure that the current project is as much of a success as the last one. Here are my thoughts, in no particular order, about what makes "good software."

Good software offers excellent user experiences.

It's been said again and again but I cannot stress this enough. Nothing matters unless the folks on the floor find that their jobs have been improved in some tangible way. People's experiences with your software matter. They're not simply automated cogs in a big machine; they have emotions, goals, demands placed upon them by external forces and expectations. No matter how "slick" your software might be, or how well written it is, if it requires users to jump through hurdles it isn't going to gain traction.

Good software "solves the problem."

These aren't the problems you imagine. They're the ones voiced by real people on the floor. Listen to them because they will tell you nearly everything you need to know and give you the background to derive key take-aways. Also, the problem must be solved in as simple a manner as is possible. Complicated approaches, both technically and from a user-design standpoint only serve to make things harder for everyone.

Good software is simple to build and deploy.

So often we, as programmers, over-complicate the development and delivery of our software. We get too concerned with frameworks, philosophies like TDD (hey, TDD is great - stay with me here) and making things "perfect" from our perspective. I have been as guilty as anyone during my time when I punched a keyboard for a living and I understand the desire to refine our work. That said, some really good software has been written in ancient and unpopular languages. We get excited about trendy things like Rust, incorporating git into every possible nook and cranny of our workflow and turn our nose up at legacy programs written in BASIC and COBOL, never mind that those pieces of software may have solved the problem with accolades and ran for decades while we became infatuated with web-only delivery and app integration.

None of this is meant to say that "modern" software isn't moving in a good direction. Only the people who replace us will be in a position to judge as such. Let's remember to take a step back from time to time and reflect on what we're really doing (solving problems and making jobs easier) and stop ourselves from getting caught up in the latest fad just for the sake of it.

Good software fits into "the bigger picture."

This is the tricky piece of the puzzle. Software so often satisfies the other important areas but fails to fit into the bigger picture. We need to develop our programs with a holistic approach that recognizes the part that our programs will play and respects the reality that our software is not the be-all, end-all. The programs we build must fit within the human-driven process in place and play nicely with the other kids in the sandbox (these are "other" software programs -- the ones we did not write). The user experience might be great, and it might solve the problem but if it's a square peg you're trying to shove into a round hole you've missed the boat entirely.

I will readily admit that I don't have all the answers and sometimes I don't even know what the questions are but this is how I see "good software" in a few simple points. What do you think makes good software?