|
I'm writing this column in a hotel room at Utah
State University where I have been attending the 17th annual Partners in Business Information Technology Seminar (www.partnersusu.org) as a Hewlett-Packard Lecture Series speaker.
The University is quite modern and spacious and is the source of the Shingo Prize for Excellence in Manufacturing. If you are not familiar with this award, Business Week called it "The Nobel Prize of manufacturing." (See "A Chip the Size of a Pinhead," May 15, 2000.) The prize is named after Shigeo Shingo who pioneered "just in time" production techniques in Japan.
The Fear Factor
Although Utah may be known as quiet and serene, there were some instances of edge-of-your-seat fear. The first occurred while driving through a snowstorm in the mountains on the way to the University one night. It's not comforting to have your student driver, who grew up in the state, say things such as, "I wonder if we're on the right side of the road?" while you can't see more than 15 feet in front of your face.
Another adventure in dealing with fear came later in the trip, but this time it was my fear of television cameras. Utah State has a distance learning program in which lectures are televised to classrooms all over the state. I have no idea why speaking in front of a live audience of hundreds of people is no problem for me, but facing a camera lens is like staring down a gun barrel. My broadcast was mostly PowerPoint slides, so luckily I didn't have to face my one-eyed nemesis.
Speakers That Made Sense
Once I got past my fears, it was time to get back in the classroom. I always enjoyed being a college professor, and I got a chance to share the platform with David Hay. David's area of expertise is data modeling, so we made a good combination of speakers. I even picked up an idea from David that I can use immediately for some modeling I need to do. The idea, in 25 words or less, is that a purchase order is the same kind of thing as a sales order, but with the "from" and "to" lines reversed.
The concept is a bit high level, but when we model our own enterprise, the model tends to make our enterprise into an environment complete in itself - the center of the universe. We forget that we are an external entity to other enterprises. The symmetry of making our own enterprise into just another client or customer suddenly makes a lot of data models easier.
The other speaker I really enjoyed was David Merrill, a professor in the Instructional Technology Department at Utah State. He has been evaluating computerized courses using a five star scorecard. Nobody has gotten past one star yet! And he is right. There were a few good uses of computerized instruction tools, but they were few and far between. There is a current fad for "themes" in course materials. For example, Dr. Merrill showed us a very nice looking course that was centered around a medieval theme and was supposed to teach auto body estimation. Knights emerge and joust with automobiles and the students score the damage, or some such nonsense.
The problem is that these are two totally different mental images, so the students have to juggle both in their heads. I have a mental picture of one of these trainees keeping a sword in his office at the auto shop - a thought almost scarier than driving through a Utah snowstorm. Dr. Merrill's advice was that you should never allow the graphic artists on your team to design training materials.
Fancy Buttons vs. Fancy Functions
Unfortunately, graphic artists also have the last word in product development. The GUI team gets to determine features, so if there is no graphic way of representing a function, the back-end team is ordered to ignore or even remove that functionality, even if the back-end program could implement it.
I am not talking about fancy little bells and whistles that developers love to add to their code to show off. It can be important functionality, too. For example, the first release of Microsoft Access did not have a UNION operator because the function could not be represented graphically.
The GUI designer also gets to determine the order of execution by determining the order of presentation. If you have to go through several screens to get from function A to function B, you are not likely to jump immediately from function A to function B. It might look pretty on the screen or follow a pattern that the GUI designer likes, but is it what the programmer meant to do? Is it what the user needs?
Overall, the conference made me face my fears and brought to light some of the problems with product development. I will probably skip the Salt Lake City Olympics, but I think I might be back to Utah in the future. Next time I plan to come when it's warm and driving isn't a life or death situation.
Joe Celko (www.celko.com or 71062.1056@compuserve.com) works at Trilogy Software. His opinions are not necessarily those of his employers. He is the author of Joe Celko's SQL for Smarties: Advanced SQL Programming (Morgan Kaufmann Publishers, 1999).
|
|
|
| |||||||||||||||||||||||||||||||
