Dangerware is common in business and government. Dangerware is just ordinary software, but the way it comes into being creates the danger.

• It starts with a basic prototype written in a hurry.
• This is quickly put into production to run the business.
• The prototype screws up repeatedly when faced with new scenarios.
• Resources are tasked to add (not update or correct) the prototype to deal with the latest screwup.
• This process repeats until the resource (or original business person) is tasked to a new project, or the cost of screwup is less than the cost of resources to mitigate.

I call this software dangerware.

And sadly, it runs most businesses and agencies. Dangerware is software written without requirements, design, tests, validation, checks and balances or even an understanding of the business, the big picture or the nature of the problems being solved.

Its software without responsibility.

Shocked?

You should be.

But its as common as desk chairs in the real world.

Think about it: the Excel models, VBA projects, Access databases, SQL queries, built by non-professional programmers, hobbyists, interns, outsourced programmers and juniors that control and manage your business are all dangerware. Where the need to ‘get something out’ completely outweighed the risks, both financial and professional. And where its was easier to blame someone else for the the screwups (or for not recovering from them).

Dangerware is everywhere in business and government. Every single finance person has a horror story of a bad Excel formula that cost someone else their business. And yet they still trust in their own dangerware.

Can you imagine if your MRI machine or autonomous car’s software was created this way? You’d be dead.

The evolution of dangerware into bigger projects and the rush to start larger projects is a fair explanation as to why the vast majority of corporate and government software projects go so horrendously over budget and fail so badly.

Dangerware is easy to detect and prevent.

Detection is simple:

• If the user is the programmer and not a professional full-time programer, you will get dangerware.
• If the programmer does not understand the business problem to be solved within the bigger picture, you will get dangerware.

Solving the first is easy. Get a professional to develop the application. Trust them, listen to them and allow them to do it right.

The second is a lot harder, but not as hard as you think. It boils down to process and communication. And it was taught to me when I was a cocky kid by a middle-aged man with thick glasses and a cane. Sadly, I do not remember his name.

He taught me a simple process to gain an understanding of the business. It was the first step in what used to be called Business Process Engineering and it is all about finding and following the workflows.

To understand a business or a business problem, you need to know that it exists and understand what it is. To do so, you need to learn the workflow, how it starts, how it does (or should) flow and where it ends up. And the first step is to walk through the first one you identify, and then each one it exposes. Follow the existing paperwork, see who gets involved, centrally and peripherally. See which flows depend on this flow and are triggered by it. Follow each variant of the flow, run scenarios on each, both success and failure, to understand the nuances.

And do this with real people. Not the managers and consultants, but with the actual people involved. Work with them to find out what you do not know. Assume nothing. Ask lots of questions, listen to them talk (and complain), ask about what happens before and after, ask why they do what they do to see if they even know. Its amazing what you will find and just how much you did not know to start with.

What will emerge is a picture, often confusing to start, of intertwined people and processes, of contradictory and seemingly irrelevant steps, and a huge pile of exceptions to the rules.

And a lot more questions.

Unravel this picture to understand the flow.

You are not trying to reproduce the flow. Nor blame or replace the folks running it. Pull out what needs to be done, why it needs to be done, where it works and where it fails. And it always shows up what you would have missed had you not gone through this process.

Then, and only then, design software to help.

That will protect you from dangerware. Because you understand the business problem and environment before solving for it and coding it up, you reduce the risks of failure, screwups and blame games.

The counter argument for this is that there is never enough time to execute this process. “We’ll get something out and then, if we have time, we’ll figure it later” is the bat-signal of dangerware. Even a single walkthrough and a few conversations with the folks involved that takes less than a few hours will show up just how much you do not know. And the time and cost spent learning is insignificant compared to the time to add more danger to dangerware and the cost of screwups.

You’ll never know everything, but at least the big nasty dangers will be identified early, exposed and can be solved for in design before releasing dangerware.

A professional programmer will check their code. A professional programmer who understands the business flow will generate product that is not dangerware.

And you, you can focus on building a better business instead of being distracted by the huge number of problems dangerware causes.

Follow the author as @hiltmon on Twitter.