Modeling That s Too Real


Modeling That’s Too Real

Here’s the ultimate in modeling. (Wouldn’t this be so cool!) I can envision a new kind of computer screen that lets you reach right into it. Instead of typing into a spreadsheet, you see what looks like a sheet of paper with rows and columns, and you have a special device that lets you actually write on the sheet of paper. And when it comes time to recalculate all the fields in the spreadsheet, off to the side sits a program that looks just like a calculator. And it has buttons that you push just like a real calculator. Once you do your calculation, you reach over and write the answer on the spreadsheet.

If computers ever reach the point that we can do this with them, I’m selling mine and buying a boat and getting the heck out of here. But do you see the absurdity here? This “program” I’m suggesting models the world so closely, it reaches the point of Why bother? Computers give us so many capabilities and we should be making use of them. Further:

RULE

When you model the real world, recognize that because of a computer’s storage space and speed of calculations and general power, you don’t have to duplicate the way things used to be done.

In formal circles, this idea of changing the way things can be done is called business process reengineering (BPR). BPR doesn’t just cover software processes; it covers the whole offline business, too. Consultants in BPR help companies revise their whole processes, and often this even impacts the customers. Here I’m not going to get heavily into BPR, because as computer folks most of us would be in over our heads. Besides, BPR requires not only an investment from a company but a willingness to change. If you’re writing off-the-shelf software and your software will be used by thousands or millions of customers, how many of them would want to be told that to use your software they have to change their offline business processes, too? Not many, I imagine. And thus I have this rule of thumb:

RULE

The software you create should not require that your customers change their business processes just to use it. If it does, they’ll buy somebody else’s software that doesn’t require a change!

REAL WORLD SCENARIO: “The Computer Can’t Change, so You Will” (I Once Said and Nearly Got Fired).

start example

Years ago, in the early-to-mid-1980s, when the IBM PC just came out, I was helping a small business get their computer going. The owner had bought himself a Commodore computer to have at home, and he liked it so much he decided it was time to computerize his office. He bought a PC, along with a really good accounting software package called ACCPAC. (Quick side note: This particular software package lives on in a modern form and is still quite successful!) The ACCPAC software in the early 1980s had something that was ahead of its time, a complete report-generation language. To create a report, you would write lines of code describing the report. The report generator had its own unique language and included constructs for accessing fields in the accounting database. (As you can imagine, I had lots of fun playing with it!) But we had a bit of a problem: We had this giant dual dot-matrix/daisy wheel printer that could take paper as wide as 18 inches. And I couldn’t figure out how to get the font set from within the report for the smaller 8 11” paper. So I set up my reports to print on the big paper and(brace yourself) I told the boss he would have to use larger paper for all his reports.

No, he didn’t get angry. He simply looked me in the eyes and said, “No. I can’t do that. I need smaller paper. I can’t have these great big sheets of papers; they won’t fit in my binders.” I argued a bit. But to my amazement, he managed to solve the problem quickly and easily. His solution was this: “Go fix it. I don’t care what it takes, but go fix it.”

And I did. I spent a few more hours and eventually solved the problem. I was all proud of myself that I managed to figure out the font codes required by the printer and embed these font codes right in the report, switching the printer to small enough fonts for the smaller paper.

I learned an important lesson that day; the lesson, as you can see, some 20 years later as I write this, has lived with me: Don’t force people to change for the sake of the computer. Why? Because they won’t. (And worse, they’ll either hire somebody else or buy somebody else’s software.)

end example

The two preceding points might seem a bit contradictory, but in fact, they provide for a fine line that you should walk on: Use the computer’s power, but don’t just create a completely virtual version of the real world. Build software that models the real world and does a good job at it, optimizing processes when possible. But at the same time, don’t go overboard on the optimization. Keep what you model within reason, and make sure the software doesn’t require your users to change the way they do things. And that’s the topic of this chapter: how to build models that are both useable and reasonable.




Designing Highly Useable Software
Designing Highly Useable Software
ISBN: 0782143016
EAN: 2147483647
Year: 2003
Pages: 114

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net