This post has been sitting in my drafts folder for ~3 years. Don’t know why I didn’t post it, it’s not terrible…

When I was in college, I took a Cobol course. It seemed like a good idea because Y2K was coming. There was tons of media buzz about all of the jobs there would be to fix the broken mainframe code. It certainly wasn’t the worst decision of my life.
The fun thing about Cobol at a university in 1993 was that in order to run your program, you had to submit it as a job to the university’s mainframe. A simple program might not get executed for 5 minutes on a good day. As it got closer to the assignment due date, it might be 10s of minutes or even an hour.
Cobol is a finicky language. You have to format your code precisely to make it work. Formatting matters a lot (those of you who don’t like Python would have HATED Cobol). Simple text editors like Notepad or vi were the only way to edit code, so you didn’t get any help from your tools.
It would be a small miracle if your code worked the first time. So after your result printed, you would have to fix something and try again. Sometimes many times. Writing a simple college assignment program that did trivial text manipulation might take you a few hours.
Since the heyday of Cobol, we have PCs on which we can run our code without waiting in line. We have development environments that can tell us about the obvious problems with our code as we type it. There are various ways to have automated tests run your code every time you save it. Feedback has become immediate.
Because of that rapid feedback loop, we now can write that college assignment text manipulator in minutes. We know it works because we have good means of verifying it. We constantly know we are “building it right”.

In our organizations, have we made the same progress with feedback about “building the right thing”?

• Edit a submission, if they own it.
• Add a vote to a submission, if they are an organizer reviewing the submissions.
• Delete a submission, if they have the right to do so.
• Accept the submission for the conference, if they are an organizer.

Mother
Yeah, can you keep them in the dark for life
Can you hide them from the waiting world
Oh mother

Danzig’s “Mother” has always been to me a song about parenting. His threats to expose your kids to his world are hollow if you have done a good job and prepared your kids. He is right that your kids will never be ready for such a world without preparation. You prepare them by exposing them to elements of it in a controlled way.

Vaccination is the same idea. You expose a person’s body to a small amount of pathogen turned non-threatening. The pathogen triggers a response so that the body can build antibodies. When the person comes in contact with that pathogen later, those antibodies help them fight it off.

The same can be said for software. You will never know if it is ready for the world without getting it in front of actual users. Betas are as old as software itself, but they are no longer enough. Software has become too complex to take finished software to a few customers and find if is ready for the world. There are too many unknown cases where bugs can hide. Users expect software to be usable as well. It is hard to fix usability once the software has hit beta. You might be able to make some tweaks, but you can’t make systematic changes.

You need to put the software in front of real users often. This helps you see that the quality is there. You can’t repeatedly put unfinished work in front of users and expect them to believe you. You have to get it to done. If the users can use the software, you will see if it is usable. You get this feedback early enough to make changes if you discover major problems. Even small tweaks are cheaper when you can make them before things are completely solid.

Do like Danzig says. Give your software exposure to the real world as often and safely as possible. Then it will be ready when you let it out.

Nadine asked, “Walk me through your design.”

Charlie started, “Well, first we contact the GPS satellites. We need current location and time. Then we reference the map provider to determine the features around us. If there is a mountain casting a shadow or a tunnel, we make note of it.”

Nadine nodded. “Interesting approach,” she said. “Please continue.”

Charlie continued on. “Next we consult the Naval Observatory to find out when the sun rises and sets. After that, we consult AccuWeather to get current weather conditions.”

At this point, Nadine can’t take any more. “Why didn’t you just use the photo resistor to see if it was dark? Isn’t that all you need to figure out if you should turn on the headlights?”

“We need to give the customer a report…”

If I had a dime for every time I heard that, I could at least buy a cup of coffee. We assume that customers like to stare at raw data, try to make decisions from it, and then go change something. I doubt that.

Reports fall in to a few broad categories:
• Lists of items that I need to do (pick lists, for example)
• Data I need to submit to a bureaucrat (tax forms)
• Summary information that tells me the current state of affairs (balance sheets)
• Raw/semi-processed data to make a decision (inventory on hand v. demand, as a contrived example)
In the case of lists, sometimes the best way to present the information is as a list report that we display on a screen or print. Then the user can take that report and use it to do their work, checking off items as they go. For simple cases and short lists, this is a fine solution.

The problem is, if they want to generate a list from a computer, it is a long list. It might even be a list that several people are working on. Reports are a horrible solution in this case. It is better to have a real application that can take into account things like changes to the list, work other people are doing, etc.

In the case of data to submit, just about every possible recipient of this data can accept a data feed. We can do this in the form of a report, but often it is better to just build up an automated interface.

When we need to give the user a summary of the current state, a report can be a pretty good solution. A well-formed report will have the information necessary for discussing the state with others. It can be portable (either by viewing it on a tablet or printing it out). It is concise and easy to find the information you need. These kinds of reports are rare. There are examples of mediocre attempts at this, so we know it is possible, but the reports that achieve this goal are a rare breed indeed.

The final case is happens a lot and I believe is the key problem with reports. We give the user some information, expect them to process it themselves, and then come back to our software to make some sort of change. We have turned the human into a computer that is subservient to a real computer.

Why does this happen? It happens because we are too lazy to do the analysis to figure out how the “algorithm” the human is using works. That might be because there are decisions made that are difficult to encode. It could be because we’re afraid we’ll get it wrong so we don’t even try.

Sometimes it is because we are afraid the user won’t trust our answer. There are ways to address this. We can show the user what we plan to do and allow them to confirm or override. We might have to display more information to the user so they can make that decision. Over time the user will trust the code and just let it do the work. At this point we have a happy user. To do this we need to iterate over the solution and get user feedback.

There are so many horror stories of how software makes people’s jobs harder. It’s ironic, because this software was sold to make their lives easier. We need to remember why we are building the software and do the hard things that will make our user’s lives easier. That is what they want.