World class software organizations and the MultiValue community -- do these belong in the same sentence? That depends on your outlook and your definition of both terms. World class software organizations appears to be the easy one to define. They are the organizations that can not only deliver software on time and within budget, but who deliver software that is robust and with very low bug rates. Sometimes overlooked, but equally important is the expectation that they are also delivering software that fulfills a specific need and advances their organization in the world marketplace. In other words, they are the winners! They are also few and far between.
That is the view promoted by many in the trade press, and I agree with them up to a point. Just to put a name to "them", I would mention Edward Yourdon, author of the Decline & Fall of the American Programmer. This is an interesting book on the subject of why and how to begin becoming a world class organization yourself. Since I'm still in the first third of the book, I'll wait to give you a final review but so far its thought provoking. The WHY is obviously global competition. This is certainly a reality, but the timing of it in individual fields and business is uncertain. The HOW is a little less clear. Mr. Yourdon denies any single "silver bullet" as a solution, but points to a series of techniques worth exploring. These include better languages, better people, better tools, better design techniques, prototyping, structured techniques, object oriented methods, and software reusability and re-engineering.
Without trying to address each of these points, the MultiValue community has historically faired quite well. Pick Basic has been a great advantage in terms of a high level language that has been updated to deal with newer problems and newer technology. It has had a very good set of debugging tools. The Pick system is also excellent for prototyping, in fact, perhaps its too good -- often the prototypes are put into production rather than used to re-engineer the system. While not much for structure, the typeless data and single record format are more "object-oriented" than most systems of its generation. And talk about reusability! Ninety percent of the operating system and ninety nine percent of most applications have been reused on the last five or six generations of hardware, often preserving code and applications that were not worth preserving.
Where do we need to go from here? Today, the traditional Pick system certainly lacks the sophisticated tool set that other systems have or are rapidly acquiring. Tools are certainly necessary for improved productivity and reduced errors, and it is important for the Pick vendors to work harder (and together?) to fill this gap. As I have pointed out in the past, most of the Pick-like systems have seen the handwriting and have a better story to tell in these areas. You need to provide tools for your staff by any means possible. Ask your vendor why he doesn't offer the tools you need, but don't stop there. Many interesting and productivity enhancing tools are available in the third party market, and more will be there if there is more of a market for them. Certainly in the last resort you can build tools locally. Your people probably already have them in "private stock" -- encourage and reward them to share these with the whole organization.
While tools can double your productivity, people issues can yield a ten-fold improvement. One of my major points for the last year, and Mr. Yourdon's point (if I can extrapolate from one third of his book), is the organization that neglects either will suffer in the long run. If you are to compete in the global markets of the future, if your company is to survive, it must make better use of its information technology. How do you screen and hire programmers, analysts, and top MIS management? How much energy do you spend to train them once they are on board? These are NOT idle questions -- studies have repetitively shown there are 20 to 1 differences in individual productivity!
Do you track problems to the source and fix the sources? This means finding the way errors are introduced in the design and programming cycle and working to educate and re-train people to prevent future problems before they happen. Empower all your people to ask questions. Many problems are introduced because the specs are unclear and the programmer assumes the "obvious" (but wrong) answer, either because he is isolated from the designer, or lacks the time to resolve the problem, or doesn't want to appear "dumb" by asking questions.
Given that the typical MIS organization now spends well over half of its budget maintaining existing code, sustaining engineering is a must. Budget for and empower a person or group to find and fix the causes of your biggest maintenance headaches. Recovering the data, rebuilding the transactions, etc, is of little value if you expect to have to do it again next week -- to be more productive, you need to find the cause of the problem.
Programmers -- if your management isn't pushing you to think, question specs, build tools, providing training for you, asking you to solve the real problems, or encouraging teamwork, do it on you own. If you don't, you'll be stuck running in circles over and over again. Being the only one who can finesse that old broken down system into running may provide a limited kind of job security, but that kind of job security isn't worth much when your company goes out of business!
Managers -- work on the list above from you perspective. If you aren't providing the training and environment for productivity, your people will eventually find someone who is. Each one of us needs to take an interest in being truly productive and solving the real business problems or we will see our jobs going overseas like the autoworkers of the 80's.