It may seem preposterous to some of you, probably raise a few hackles no doubt. "Hey, not us. We stand for customer service." "We only want to help our accounting group do their jobs more easily." Yeah, as long as it fits into your idea of ease of use and your idea of what is important.

Priorities
One of the problems that we have as computer professionals is allowing our business users to determine our priorities. In my many years of working for a large energy concern, there were countless occasions to witness IT professionals - good ones - abandon the priorities of their business users because they thought they knew better. More often than not, our business users wanted more than anything else in the world for our software to remain stable. They did not mind improvements. They appreciated an optimized and faster-moving system. They even endured an entire industry trying to move them to the Web. But none of that mattered more than stability.

Our business users didn't want the systems to break down at all. They wanted to come into work in the morning, log on, and have their software do exactly what they needed it to do. Sometimes that meant that COBOL batch jobs ran at night on a large mainframe system, and their numbers were updated when they got there. Were the COBOL programs sexy? Not by the farthest stretch of the imagination. Were they elegant and well written? Not really. They were essentially wrappers for large stored procedures written by those who were not yet ready or able to abandon the COBOL and the hardware that they knew so well. Were there attempts to rewrite those systems and force newer, cleaner code on our users? Oh yes, countless attempts.

The problem with that clunky COBOL code was that it ran like a champ. It never broke down, it seldom got the numbers wrong, and it didn't disturb the middle of anyone's day. It ran at night, it ran quickly, and it moved pricing and volume data back and forth like the wind.

In spite of ourselves, we made numerous presentations and project suggestions to make it all thoroughly modern. We tried desperately to get in the way of good, sound business.

Just a Part - Not the Whole
Are you getting in the way? As strong a factor as IT is and has become in the business of doing business, it's only a piece of the pie. One of my parents' gifts to me as a child was a pictorial guide to the teachings of Buddha. It was really just a glorified comic book, but it told the story of the blind men who were asked to touch an elephant and describe it. One of them felt its tusk and described the elephant as smooth and hard, another as wrinkly, another as hairy. They each had a different perception of the elephant, but all described only a piece, none of them able to see the whole elephant because they were concentrating on a single part. The Buddha was telling all who would listen not to lose sight of the big picture.

Take a moment and look at the big picture if you can. Step back and ask yourself if you consider the software that you support or that you have written the most important piece of the business that you are trying to help succeed. The accounting software people will have no beans to count if there are no revenues coming in. The lights would not stay on long if accounting didn't pay the bills on time, and so it goes and so it goes. Our software is just a tool, a means to an end. Some software that you have written is just a tusk, a long beautiful lifting and fighting tool. Some of your software is a thick and powerful leg, supporting perhaps the very infrastructure of the business paradigm. It all works together.

The Rules Have to Benefit Everyone
Software managers, project managers, and developers can take on a somewhat Byzantine attitude toward the rules of development. Don't get me wrong, we have to have structure; we must have order. If you don't have good systems for checking software in and out, work will be lost. If we don't have versioning and tiered releases we can lose work. If we don't maintain order in our project steps, we can underanalyze, overtest, or start writing code without a blueprint or a compass to guide us.

But none of that is as important as creating what our users need in the timely fashion that they need it. There are times when a "quick and dirty" approach is the only one that will work for a given project. There is a quote from the movie And the Band Played On: "When a house is on fire, you don't wait for scientific proof, you grab the first hose and start putting out the fire." Sometimes our business users need a hose, and we have one here ready to go. You may see a better way, in fact, you may know there is a better way. Certainly a way that won't cost them dearly in the long run - and you probably have a responsibility to present them with viable options, but you can't stand in the way of the business if they say they need the hose.

Process is vital in our line of work, my friends. If we don't have any process available to us, we generally start developing before enough analysis has been done. We also tend to abandon the testing phases as well. But if we get too bogged down in analysis or testing, then it only hurts us and our users.

In the End
Listen to what your users have to say. They may not want to do the hippest or trendiest thing; they may not want a wireless, mini Java interface that will beam them up. Sometimes working in a stable environment can seem detrimental to your career. You may want to get them converted to PB9, and, in fact, they may need it badly. But if they have a fully functioning client/server system written in PB 6.5, you will be hard-pressed to convince them that converting it to a newer system is necessarily the best way. Support them to the best of your ability and cash your checks. There is no shame in keeping your users happy.