October 21, 2009
When people learn that I had been working with the database product “Progress” since it was first introduced (more than twenty five years ago!), they put me in the “technical” box. Indeed, with my graduate degree in computer science, they might assume that I have a full grasp of this product.
Ten or fifteen years ago, they might have been right. I could design and build systems, install Progress and my application, tune the whole system for great performance, work with staff to ensure that the system is well utilized, and enhance it so that it better serves its purpose.
But the world now is more complex. Now I do only some of these things — particularly those focusing on interface, usability, and integration into the creative organization. Meanwhile, some of my colleagues focus just on the technical performance issues — everything from configuring the right disk drives and data paths, to stitching together databases that have somehow become corrupted. I refer to these friends as my “database anesthesiologists” — doctors who carefully monitor the vital signs, and keep the patient alive.
I don’t know why they dislike this name. It’s a sign of respect to me. In fact, I’ve an allergy to general anesthesia that could easily be fatal if an incident occurs. I know that I’m putting my life in the hands of anesthesiologists every time I go into the hospital for elective or emergency surgery! (The condition is called “malignant hyperthermia”, and I’ve already had one episode).
In this paradigm, I call myself a “database psychiatrist”. My job is to keep systems communicating effectively and efficiently, and functioning as part of a social team with people and with other technology. Systems need to be easy to use, hard to mis-use, and they need to do right things with the data they handle. They also need to come with realistic and helpful expectations. For example, systems designed to help forecast or plan may be invaluable tools to help staff understand the implications of a model, and of the data that fed into it. But where the assumptions of the model break down, or where the data is not realistic, the validity of its projections need to be questioned. I call work in this area “computer assertiveness training”. It’s about learning when to (figuratively) turn the computer off, or put it in its place.
Today I’m much more than the “database psychiatrist” described above. Much of my time is spent listening to other kinds of management issues — typically involving such things as communication and values within organizations, marketing strategy, management of creativity, and general problem solving. I also spend time “coaching” (I prefer to call it “clarifying”"), where I’m offering a helpful process, and not a solution. But one thing I’m not — the database anesthesiologist!
October 16, 2009
The following query appeared on a technical programming e-mail list to which I subscribe. My response, which I’ve printed below, is really a discussion about the importance of dance, and about the design process.
We are testing out a product which sits over our character product and give it a GUI [Graphic User Interface] look and feel as well as most of the important GUI functionality. Has anybody had experience in doing this and , if so, what are the pitfalls I should be looking for.
So far the results are phenomenal. With very little change to our character code we have been able to generate a gui application that does not kill the network resources. Instead of looking at one – two years of development to get our software . . . we are looking at one – two months. . . .
Tell me I’m dreaming!!
You are dreaming. Definitely.
You can certainly get products that will put GUI objects on the screen. People may take a quick look, and say that you’ve a “GUI” application. But conversion to GUI is much more than just GUI objects! It means enabling different kinds of work flows, allowing users to move through the screens in different ways. It means providing parallel tracks, so that most applications can be run either by mouse or by keystroke commands. It means conforming to well accepted GUI standards, so that users accustomed to products like Microsoft Word and Excel will find themselves at home in your application. The result should include more efficient use, easier training, higher accuracy, less user stress.
Also, the process of moving to GUI can be a time of re-thinking how your product enables users to do their jobs better, and to re-think some of the core functionality. A plug in product that transforms the visual appearance of screens does not invite that important re-design step.
So dream on … or invest in a constructive process of really transforming your application. (Or … re-think what advantage you believe GUI offers. If it’s just marketing — being able to say, “We’re GUI” without being better for it in any way — then the whitewash product may be just what you need!).
. . .
I use the word “Design” in the new subject line above in its broadest sense. Design starts with listening to users, and includes building mockups, having real users test and critique them, re-working the interface to accommodate this user feedback, and iterating on this process. “Design” does not just mean drawing pretty pictures or screen layouts!
October 11, 2009
My tolerance for complexity — in all things — seems to be decreasing with age. And I don’t believe it’s the onset of dementia. Quite the contrary, I attribute it to wisdom gained with considerable experience
Brian Kernighan, one of the authors of the ‘Unix’ computer language, wrote:
Debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?
Computer programs always have some degree and complexity, and usually are not exactly correct. They are born with “bugs”, and the task of debugging is about finding those flaws of logic that lead to wrong behavior in certain — perhaps unusual — cases. If the program is written in a clear straightforward manner, with visible structure, and an appropriate number of explanatory comments, the debugging process will be much easier. But if the program is written with clever tricks — perhaps taking advantage of some esoteric facts about the number system — debugging will be difficult or, as Kernighan suggests, impossible.
I used to travel widely, delivering to computer programmer audiences a talk entitled “On being lazy, absent minded, and a great system developer”. I explained that being lazy meant that once I’d developed some code that worked, I’d take time to document it carefully, and package it so that it could be re-used in other larger programs in a natural way. Thus I would do something well, once. Being absent minded meant that I’d often lose track of where I was in the coding or development process. To compensate, I’d have to write a plan first, and document any changes to that plan as I proceeded.
With these definitions, all the developers and analysts in my audiences could affirm that my qualities of laziness and absent-mindedness — as I compensated for them — were excellent qualities! In fact, what I’d spelled out are two best practices for writing code. A program consisting largely of well written and already debugged small sub-programs will almost always be more reliable than one written as a new mass of virgin code, and intelligent comments are an important compliment to the code itself.
I asked my audiences for a show of hands, how many spent much or most of their time debugging or updating other people’s code. Most raised their hands. Then I asked how many found that code to be unclear, unstructured, hard to read, and difficult to modify in a safe reliable fashion. Again, most hands went up. Finally, I asked how many were rewarded in their performance review for writing such high quality code — instead of just for writing lots of lines of code that seemed to work. This time the hands stayed down.
Evidently, although we recognize that complexity is almost unmanageable, we’re too often unwilling to invest in simplicity. And simplicity is the product of good design. I believe that the underlying issue is our reluctance to understand the importance of design.
I’ll have more to say about this in future posts on this blog.