Its incredible how many sources of information there are today. I must be on more than a dozen free magazine mailing lists (Oh excuuse me News & Review, controlled circulation publications). On top of these, I pay for half a dozen others. Between my magazines and my wife Jamie's garden magazines and clothing catalogs my mail carrier has asked for a hernia risk bonus. Seriously, he has told me we are consistently the largest mail pile on his route. Most months it is tough to even properly skim through all this incoming mail.

The catch banners on the cover of a magazine are often my primary clues to hot topics in the industry outside of Pick. With this in mind, I was really intrigued by the last teaser on this months BYTE cover, "The End of Programming — AGAIN". Before the programmers in the audience panic (or after they panic and go into denial) the table of contents teaser said "You'll never have to write another line of code ever again. Yeah. Right." This led me to suspect the article might have actually been written for the April issue and they didn't find space until now. It also guaranteed I'd read the article.

The topic of discussion was an approach called Rapid Application Development or RAD and the current crop of proprietary tools to support it. Although the word is never mentioned in the article, the concepts look a whole lot like what would have been called CASE tools a year or two ago. The article is reasonably well balanced and rather than my recounting it, you should go read it for yourself.

It did get my juices flowing once again for one of my pet peeves in the MultiValue community — the incredible willingness of many in upper management to blame "the programmers" or "the Pick environment" for their failures. Time after time I see otherwise intelligent and serious managers make utterly silly assumptions about the cause of the lack of success in the MIS area. I am reminded of some of the classic old-world sayings my dad was fond of when I was a lot younger. One in particular was "Only poor craftsmen blame their tools." Now that doesn't mean we don't want the best and most appropriate tools we can find, it just says if you know what you WANT to accomplish and you understand your tools, you know what you CAN accomplish.

I assume the old saw that "Nobody plans for failure" is an obvious truism. For some unknown reason it is not at all as obvious as it should be that the inverse of this is "Success takes planning." If you haven't specified what you want to accomplish, how are you even going to know if you succeed. You simply can't meet the expectations of your users if you lack formalism in the design of your application solutions. You won't get stable, reliable applications if the design is a constantly moving target. And high performance only comes from thinking about performance.

Tools such as RAD, CASE, and other prototyping solutions can be very beneficial in speeding up the visualization and validation of a computer project but it is vitally important to remember they are simply tools and we are the craftsman. We need to understand our business issues and goals before embarking on a automated solution. We need to design the human interface and understand its human and computing complexity and its performance issues up front, before we ever commit to a major project. Today, I find that all to often this happens halfway through a project when it is in deep trouble, or worse yet, not until the postmortem for an expensive failure. We may gain efficiency from eliminating programmers (or at least bad programmers), but we will gain successes from eliminating bad designs and lax management.

Many (but certainly not all) of the management failures I see revolve around upgrading existing systems rather than building new systems. I suspect the myopic view management takes of even major re-writes of existing systems must come from assumptions the original design was rational and addresses business needs. These assumptions are compounded by the fact most of the systems I see were implemented well before their current MIS management joined the company. Let me burst your bubble — it is generally not true these old applications had rational designs or even directly meet the organizations business needs! There are several historical reasons for this.

First, the Pick system is the original RAD prototyping tool. Its data model is so forgiving and flexible that most systems were NOT properly designed, they simply evolved. Secondly, many of the packages were developed by non-professionals for a single customer and then generalized for resale. Additionally, most of the early packages were visualized around much lower volumes and terminal counts than are typical today, so even the few which had a design pedigree are now of questionable validity.
Of course, I am not lobbying for you to through your current systems away. More than likely there is tremendous usefulness and productivity left in them, but you shouldn't simply assume they represent a good model of your business or a good model of Pick application design. Even (or perhaps especially) existing systems undergoing revision require a careful design review for business issues, human engineering and machine efficiency. Small, incremental, well thought out changes can often dramatically extend the useful life of your existing hardware and application investments.

In the cases where the only possible conclusion is to scrap the existing system and start over, the investment in understanding the current issues and designing solutions normally one hundred percent transferable to the new project, regardless of whether it is to be done in Pick, Oracle, or any of the increasing number of possible alternative visual development environments. Thorough planning is the alternative to what BYTE called the "prototyping death spiral" leading to "user dissatisfaction, wasted money, and a short life span for the application." Or paraphrasing my dad's old workshop proverb "Measure twice, cut once" into our environment becomes today's axiom "Design carefully, code and deploy once".