Disposable Software

I'm a huge fan of pilots and "Flintstones" to demonstrate success on a small scale before worrying about all the edge cases. This allows us to test the entire solution and roll it out to everyone without unnecessary risk. There's natural resistance to this approach because it's not the way we've been doing things for almost half a century, maybe even longer. When we try something new, we need to ask ourselves: what was wrong with the old way, and why is this new way better?

To address that, let's take a trip down memory lane and recall why we do things the way we currently do. This goes back to the 1940s and 1950s when computer systems were first built, and the economics were very different, almost opposite to today's computing economics. I remember walking into my first computer centre around 1975. Back then, a computer cost more than the building it was housed in, and often, the building had to be specially built to accommodate the massive machines. These computers required a huge capital investment, and running a computer program was very expensive.

I once saw this estimate: in the 70’s running a data processing program one time could cost between fifty to one hundred and fifty thousand Australian dollars (inflation-adjusted). In that context, it made perfect sense to develop procedures, processes, and documentation that delayed running the program until the last responsible moment. Any issues or mistakes that could be caught by human effort saved a lot of money because it meant running the computer program less often. As the Japanese would say: think, think, think, think, do.

In today's world, the economics have reversed. If you use the right technologies for building your digital solutions and integrations, operating these technologies is often free or costs only a few hundred dollars a month per solution, including the full cost of the people managing it. So, it no longer makes sense to spend more than a few minutes documenting what you're going to build before you build it because it's actually cheaper to build it than to document it first.

Any money, effort, or time spent on consultants, business analysts, or technical architects to plan a solution before it's built is wasteful. If I build a solution this week, throw it away, build it again next week, and repeat this for a month with one or two developers, it's still cheaper than creating a requirements document. The feedback from real people using real software is of much higher quality.

This means the capital efficiency of solving a business problem using software, digital solutions, or integrations is much higher with a build-first approach than with the traditional documentation approach. In the documentation approach, you first create a document, then build the system, and finally put the system in front of users with no feedback mechanisms once it's live. In today's world, where computing is so cheap—almost free in most cases—it doesn't make sense to spend a lot of time documenting and planning in advance.

There are much better techniques to ensure you get the best value without wasting resources. In extreme cases, it doesn't matter if something is reusable. Running a pilot to refine your requirements is still more effective and capital-efficient, even if you end up starting from scratch. Starting with a pilot and iteratively building it out to handle more edge cases and releasing it to more users is far more capital-efficient. Often, I quote jobs based on the budget of a failed project and then divide it by two, three, or four, depending on my mood.

I can do this comfortably because building software with immediate user feedback, even on a small scale, is a much more efficient process. Users provide feedback based on real-world usage rather than feedback on a document they're nervous to sign off on. Many of you have probably experienced the frustration of getting a document signed off, only to receive numerous reviews and comments from different users, dragging the process on for months.

I have examples of projects that failed over a two-year period, costing two million dollars, for a ministerial briefing system. In contrast, the solution was piloted within three weeks and delivered over nine weeks, with a total budget of one hundred and ninety thousand dollars. The goal is to get working software into the hands of real users as early as possible, ideally within a month. If it takes longer than a month to deliver a working solution to a small subset of users, you need to re-evaluate and break the project into smaller parts.

It's interesting that we've heard that phrase before, right? Early and continuous delivery of working software to users is a key part of the Agile Manifesto. Ironically, that's often what doesn't happen in most "agile" projects. Documenting everything for all edge cases, users, technologies, architectures, and solutions, and then going to market to tender for a solution before releasing any software to users, is the exact opposite of what the Agile Manifesto intended. I know this from speaking to a few of the signatories.

I encourage my customers to take the reverse view when considering a traditional approach. I ask how many people they expect to involve and for how long before we start building, then I estimate the budget for that. Afterward, I ask a simple question: is there a small solution for part of this problem that we could build for that money to boost our confidence and excitement in our ability to deliver real-world solutions?

Andrew Walker
Technology consulting for charities
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/