Decisions, Decisions, Decisions

What is the purpose of enterprise software? To put the right information in front of the right people at the right time. It’s just that simple. If you are writing software for a commercial interest, the odds are *99.9999999% certain that the direct purpose or indirect result is decision support.

There are, I suppose, at least two ways to support a decision; one way is to carry out a decision which has already been made. Another is to inform a decision which hasn’t been made yet. It is hard to imagine writing software which does purely the former and none of the latter. I mean it does happen, but when it does, it’s usually bad.

For instance, recently I received a bill from city hall for my water & trash collection services. It said please pay up by the 25th. A couple of days later, I got a letter from city hall which said pay up by the 15th or we’ll shut off your water. When I pointed out this inconsistency to the nice lady at city hall, she didn’t see a problem. She explained, “that first bill is from our automated system. We don’t control that.”

Hmm, yes. They have a software system which carries out decisions that have already been made, even when those decisions are wrong, and meanwhile nobody at city hall is paying attention to what the software is doing.

But even in this case, it’s worth noting that their software informed me. It perhaps didn’t inform the right people (and perhaps not at the right time), but eventually it informed somebody.

So for this essay I am really just focused on the kind of decision support wherein your software informs decisions yet to be made. This kind of decision support is both more fun and inevitable.

The code you write may inform your own decision process. You may be supporting your colleagues’ decisions. If you write VBScript, you’re probably supporting project managers’ decisions. And neither more nor less importantly, you may be supporting your customer’s decisions. Or it could also be some mixture of the aforementioned cases –but it doesn’t matter: your job, if you write software for a commercial enterprise, is to put the right information in front of the right people at the right time…so they can make good decisions.

Be Humble

With this in mind, there are a couple of important things to remember. First: your software will most likely be only one of several sources of counsel for each person or group which uses it. Executives will love your pretty reports, but to do a good job they must learn how to reconcile what’s on your report with what others are telling them, what they observe when they walk through the warehouse, and ultimately, what their gut tells them. Your customers are most likely also listening to your competition. Your software will likely never be their only counselor.

In the “water and trash” example above, I had a mailing generated by software, but I also had another letter, and I had the nice lady at city hall to help me understand how they understood their software. These things taken together suggested that city hall was crazy. I also had the old adage which says, “You can’t fight city hall.” I used all of these sources to inform my decision to write a check well before the 15th.

Tell The Truth

Second, it’s important to tell the truth with your software. Remember the old adage, “fool me once”? If the counsel provided by your software proves unreliable, it won’t be relied upon very long. When I say “tell the truth with your software,” I don’t just mean refrain from lying. I also mean your software must avoid becoming inadvertently inaccurate. If your software has bugs, there is the real possibility that your software is providing bad advice; not because you ever intended to deceive anyone, but because buggy software is as trustworthy as a contract written with scrabble tiles laid out on a water buffalo’s back. When people realize how buggy your software is (and they will), you can bet they will never sign that buffalo (unless you are city hall, then they have no choice).

But bugs are not the only inadvertent way to tell lies with software. In order to have your software tell the truth, you must discover the truth. Somebody at city hall installed software which didn’t know that sometimes city hall doesn’t want to wait for your money until the 25th, they want it sooner. You can bet that whoever wrote that software never talked to the folks who wrote me the second letter. They certainly never talked to the nice lady. If you want your software to faithfully inform decisions, you had better learn how your company works. If you write software which informs decisions (and remember? You do!) then you had better be well informed about your company’s business.

* Approximation.