There are two kinds of people in the world, according to a tired joke: Those who divide the world into two kinds of people and those who don’t. I’m one of those who do. I divide the world into engineers and everyone else.

Being an engineer isn’t a matter of training or expertise, or at least not the way I use the term. Engineers look at every problem as a puzzle they can solve, so long as they’re smart, systematic, and ingenious enough and look at it from the right angle.

The rest of the world looks at problems as, well, as problems. Things that make their lives worse. Obstacles. Barriers. Something you call an engineer to take care of for you.

Engineers have a hard time working with non-engineers because of how much time and emotional energy the non-engineers expend bemoaning their fate and how hard it all is. Non-engineers have an even harder time working with engineers because the engineers display so little empathy.

There’s room in the world for both. For the non-engineers, I figure we should reserve the Aleutian Islands.

Correspondence from an IS Survivalist brought this to mind. Following my suggestions on how IS can improve its relationship with the rest of the business, this scarred veteran described a situation that’s all too common: End-users who are all too willing to complain, but who aren’t willing figure out what they really need.

How do we deal with them, Mr. Know-it-all Consultant?

Some problems require more extreme solutions than others. When asked how to fix the acoustics at Northrup Auditorium, for example, the great conductor Eugene Ormandy had a one-word answer: “Dynamite.” Recalcitrant end-users also call for extreme solutions, although not as extreme as Ormandy’s. Here are some possibilities:

Extreme Technique #1: Make sure you aren’t the problem. Because it’s so easy to blame the users, ask a couple of the best analysts you know to review the situation with you. See if they can offer any suggestions or point out flaws in your technique.

Extreme Technique #2: Ping pong. In every meeting tell the complainers, “Here’s what I need from you. As soon as I get it, I’ll build it into the prototype.” Every time they hit the ball back to you, put it back on their side of the table again. Use prototyping tools so you can do your part at great speed. Every time they’re late send a reminder on e-mail, copying your boss and the project’s sponsor.

Extreme Technique #3: Assign a leader. According to legend (most of which he apparently authored himself) Wyatt Earp once faced down a mob by appointing a leader, pointing a gun at him and saying, “Get these people out of here.”

Look the biggest trouble-maker in the eye and say, “It’s clear not everyone wants the same thing in this system. Fred, you seem to have strong opinions about it so I’d like you to be my point of contact.” Then, ask Fred, every step of the way, “If I build it this way will it be what you need?”

Not only will Fred will have a hard time complaining, he’ll be on the receiving end of everyone else’s complaints – after all, you built it to his specifications and he was supposed to coordinate with everyone else.

Extreme Technique #4: Escalate. There comes a time when the CIO has to explain the facts of life to his counterpart in the end-user organization. “For us to build the system you need, we need someone from your organization to take responsibility for its design, and we need you to sponsor the project so there’s someone with enough authority to resolve issues and priorities. Otherwise, we’ll just have to guess, and there’s no way we can get it right that way.”

And then there’s the last and most extreme technique: Look the complainers dead in the eye and speak the following words: “You have two choices: You can complain, or you can design. Pick one.”

I was sitting with Moe, Larry, and Curly at lunch the other day (not their real names but I feel an obligation to protect the guilty) when the conversation turned to information technology.

My colleagues (we’ll call them S3 for short) recently left the military, so their perspective on IT is a bit broader than that of most IS professionals. Moe led off with a mention of genetic algorithms. Here’s how these amazing things work: You feed the computer any old airplane wing design (for example) and a definition of what it means for a wing to be optimal. Let the computer churn for a day or two, and just as an automatic bread-maker magically produces bread, it will pop out an aerodynamically perfect wing design.

The algorithm is called “genetic” because it mimics evolution, randomly mutating the design in small increments and accepting those mutations that improve the design. Very cool stuff. If you support an engineering design group, this technology is in your future.

From there, Curly somehow got to artificial intelligence, and in particular the AI golf caddy. Apparently, these little robots actually exist, following you around the golf course and recommending the perfect club for every shot. Larry pointed out the hazards of combining the AI caddy with Y2K: “Carnage on the course,” he called it.

If you haven’t noticed, people are doing amazing things with computers these days. So why is it that most IS departments, in most projects, can’t seem to design a database, create data-entry and transaction-entry screens for it, design and code a bunch of useful reports, and hook it all to the legacy environment without the project going in the ditch?

When I started in this business, a typical big project needed 25 people for three years and was completed about a year after the deadline — if it got completed at all. Compared with the simple compilers we had when I started programming, our integrated development environments should easily make us 100 times more productive. So why is it that as I write this column, a typical big project needs 25 people for three years and is completed about a year after the deadline — if at all?

Do the math, people. One programmer should complete everything in nine months. What’s the problem?

It isn’t, of course, quite that simple. It also isn’t that complicated. Try this: Start with a small but useful subset of the problem. Then, understand the data and design the database. Create edit programs for each table. Work with end-users to jointly figure out what the update transactions are, and design transaction entry screens for each of them. Design a navigation screen that gets you to the edit and transaction screens. Build a simple batch interface to the legacy environment. Do it as fast as you can. Don’t worry about being sloppy — you’re building Quonset huts, not skyscrapers.

Put it all into production with a pilot group of end-users for a month. Turn your programming team into end-users for that period so they experience their system in action first-hand. At the end of the month, start over and do it all again, this time building the system around how the pilot group wants to work. After a month with the new system they’ll have all kinds of ideas on what a system should do for them.

Build Version 2 more carefully, but not too much more carefully because you’re going to loop through the process one more time before you’re done. In parallel with Version 2, though, start building the infrastructure — real-time legacy interfaces, partitioned business logic and so on — that you’ll need for Version 3, the production application that needs a solid n-tier internal architecture and production-grade code.

Does this process work? It has to — it’s just a manual version of a genetic algorithm. I’ve used it on small-scale projects where it’s been very successful, but haven’t yet found anyone willing to risk it on something bigger. Given the risks of traditional methodologies, though (by most estimates, more than 70 percent of all IS projects fail) it almost has to be an improvement.