Goals vs. Methods

09/13/2004

In response to my recent posting on my Imaginate article in IEEE Software magazine and Pete’s magical application framework, reader George Rappolt wrote:

However, your “lessons learned” were all about goals and attitudes—not methods. “Users like results. They don’t care about the technology.” Wouldn’t we all like to be able to show them results? “Users like to be involved.” If we could all produce examples of what users wanted while they watched, so that they could give that immediate feedback, we’d see a lot more user involvement. “Reuse is great, but use is better.” This is an exhortation to solve real problems (which requires knowing what the real problems are). “Tools should support rapid development with feedback.” Does anyone disagree with this?

Actually, yes, people do disagree with that—at least in the actions if not in their hearts. Let me explain.

First, the major point of the article is that one can get good results by the proper application of technology, not by any virtue of the technology itself. After all, Pete’s using Cobol! That’s got to be the equivalent of performing a challenging Paganini violin solo on a kazoo.

Wouldn’t we all like to be able to show them results?

You’d think so, but unfortunately that’s not entirely true. A goodly number of programmers—and even managers—become overly enamored of technology for its own sake, and quite easily lose sight of any results-oriented goals. A simple and continual refocussing on producing business-value results is tremendously valuable.

Tools should support rapid development with feedback. Does anyone disagree with this?

Not in theory, but certainly in practice. Look how many teams react to feedback from end-users: they dread it so much that they put whole teams of other people in place just to filter it out and try to keep it from reaching them.

Unit testing is feedback as well, and many programmers simply don’t want any part of that at all. So yes, many people act as if they disagree with the statement above—they really don’t want feedback because it confirms that there’s a problem. Ignorance is bliss, after all.

George continues:

I’d really like to know more about how “Pete” did it. I’ll go out on a limb, and guess that what he did isn’t very generalizable. “Pete” has been doing this since 1973, so he’s an expert—not just in software, but in whatever application domain he works in. After all that time, he knows what the real problems are—for his customers. He has probably designed a system that allows for exactly the kinds of flexibility they need, and not one bit more. He has probably used coding techniques that are exactly suited to what he needs to do, but not particularly useful in unrelated contexts.

None the less, I’m really curious to know how he did it, and I suspect other readers are, as well. If my guesses are correct, “Pete” needn’t worry much about other programmers stealing his intellectual property, because it is based on a depth of domain knowledge no one will acquire without years of work. None the less, we could probably profit from a description of the basic architecture and functionality of his system (if he’d be willing to supply it).

Pete did share some of his architecture with me, and from a high-enough level it’s not all that specific to his domain. It’s seems to be just general, everyday business stuff.

Are you interested in reading more about Pete and his approach? If so, please e-mail me directly at andy@pragmaticprogrammer.com. Ask your friends and associates to e-mail me as well; the more responses I get the more likely we’ll write something up about Pete and his magical methods.

After all, if Pete can do it in Cobol, imaginate what you could do.