Troubleshooting Professional

Back IssuesVolume 2, Issue 8, September 1998Back to Troubleshooters.Com
Copyright (C) 1998 by Steve Litt


Editors Desk
Letters to the Editor
What is RAD
That Zany World of DLLs
The Magic Bullet, Part 1
The Magic Bullet, Part 2
The Magic Bullet, Part 3
RAD Reality: The Challenge is in the Choice
RAD Myth: It bails you out of trouble
How to Submit an Article
URLs Mentioned in this Issue

Editors Desk

By Steve Litt
Doesn't it seem like more and more of our Troubleshooting efforts involve software? Is the software a Cadillac or a Yugo. Will troubleshooting involve tracing a single root cause, or will it require constant tweaking and wizardly incantations?

How is the software manufactured? Is quality designed in, or are defects inspected out? Are the raw materials manufactured or bought? How are they chosen? How is their quality evaluated?

What kind of machinery is used to manufacture the software? Of course, there's no drill press or stamping machine, but the computer language or development environment definitely fills the same function.

How is the assembly line set up? Is there a source control mechanism? Is everything scheduled correctly?

How about the engineering department? Do they model and normalize data, or just wing it? Do they (correctly) use modeling tools? Do they talk to the customers (users) and the manufacturing department (coders), or are functional requirements "thrown over the cubicle wall"?

Are skilled personnel used, or the cheapest personnel, or any warm body?

This month's Troubleshooting Professional discusses software manufacturing equipment (otherwise known as "development environments"), specifically those environments said to be Rapid Application Development (RAD) environments. The development environment influences all the other components of quality -- manufacturing, personnel, engineering, assembly line, raw materials (VBX's, OCX's, COM's, class libraries, third party products, etc.), quality by design or inspection. The software manufacturing process will, to a great degree, determine how things go for us as Troubleshooters.

So kick back, relax, and read this issue. And remember, if you're a Troubleshooter, this is your magazine. Enjoy!

Steve Litt can be reached at Steve Litt's email address.

What is RAD

By Steve Litt
Mention RAD to the man on the street and he'll tell you it stands for Rapid Application Development and involves drag-and-drop development of the user interface. He'll tell of the hours-long adjust/compile/link/view process old-time programmers put in just to get a screen right, and how drag-and-drop saves those hours.

His better informed cousin will add that the real saving comes from the environment's design time knowledge of the underlying database. Drop the field on a form, go through a couple right-click menus, and you've synchronized that on-screen field with a database column. Drop in a picklist or VCR control and you have a row navigator. It saves weeks.

The cousin's buddy, who's been a programmer since 1983, will tell you both cousins are right, and it goes even further. In the old days, if you got stumped, you'd scan the manual and hope your eye caught the appropriate information. Maybe you'd call a couple buddies. If you came up blank you'd do an obscene, time consuming workaround.

Now you get on the 'net, search for somebody who's already done it, and follow his or her technique. Often you can cut and paste it right off the net, then modify it to your needs. Manuals are now in PDF format, and you can F1 on a word to get help on it. You can electronically search an entire PDF manual to find what you might have missed scanning paper. Cut and paste from a PDF manual or a help file and you'll minimize the chance of transfer errors.

Here's the point, says the cousin's buddy. Today, if the information exists, you'll find it and transfer it accurately to your code in minutes or hours, instead of months.

The buddy's friend from Silicon Valley agrees with all of this, with one addition:

"If you use it right".

Steve Litt can be reached at Steve Litt's email address.

That Zany World of DLLs

Imagine a world where replacing your car's muffler causes your television to break. Welcome to the zany world of DLL's.

DLL stands for "Dynamic Linked Library", and is simply a file containing an executable image of subroutines, functions, data, objects, etc. At runtime, any program can call or refer to these subroutines, functions, data, objects, etc. A useful function can be placed in a DLL and tested to perfection. Then that debugged and proven subroutine can be called by many programs, written in many development environments, by many vendors. COOL!

But not without its problems. Imagine you download a cool little tool off the net. You install it. But the installation program isn't smart enough to check DLL versions, so it replaces a DLL used by the mail-merge function of your word processor with an older version. A few weeks later you discover your word processor GPF's when you try a mail-merge. A tad difficult to track down.

Will the real VBRun400.DLL Please Stand Up

Here's a nice Troubleshooting challenge. Applications CoolApp and MyWP use the same DLL. The version installed by CoolApp, in the c:\windows\system directory, is older and will GPF MyWP. The MyWP version of the DLL is installed in the C:\MyWP\DLL directory.

The symptom is "MyWP GPF's".

Detailed investigation shows that MyWP worked the last time it was used -- about a month ago. Now it doesn't.

Here's what's happening. MyWP won't work with the DLL version in c:\windows\system, installed by CoolApp a month ago. We can prove this by running ..\MyWP.exe from the C:\MyWP\DLL directory, in which case it runs perfectly.

CoolApp's installation program can't be blamed -- it had no way of knowing a newer copy of the DLL was already in c:\MyWP\DLL. It looks in the System directory, the Windows directory, and the path.

The solution here is to place the newest version in c:\windows\system, where it's available to all programs needing it, and delete it from the c:\MyWP\DLL directory.

The documentation for the LoadLibrary() API function is:

HINSTANCE LoadLibrary(LPCTSTR lpLibFileName);
The documentation says that if the path is left off lpLibFileName (the filename of the DLL to be loaded), LoadLibrary() will search for the DLL in this order: Note this implies that if you *really* want different dll versions for different apps, put em in the same directory as the executables. Otherwise, best place to put them is the system directory (usually c:\windows\system), and nowhere else.

Environmental Pollution

Most modern development environments (including the RADs) place their API or framework or whatever in a DLL available to any executable developed in that environment. In practice that means that every third program (the ones written in VB) requires VBRun300 or VBRun400 or whatever. If there's a version conflict or multiple but different copies, it's bug time.

A Troubleshooter's Land of Milk and Honey

It's the ultimate job security for Troubleshooters. Each install risks creating a bug too esoteric for the average technical person to find. Using tools that show what DLL's are in memory, and what versions are on disk, and various other techniques, the advanced Troubleshooter cures the problem and collects his salary.

Nor are DLL's the only shared resource that can cross-polute applications. OCX's (components) and the Registry do it too. So can ODBC.

Until application modularity is returned to Windows, the Troubleshooter who can quickly dispatch a DLL problem will have all the work his heart desires.

Steve Litt can be reached at Steve Litt's email address.

The Magic Bullet, Part 1

By Steve Litt


They had been industry leaders in the early 80's, due in no small part to their best of breed software. But years of patches and neglect had taken a toll -- a rewrite was needed if they were to regain their preeminent position. For the past year they'd thrashed around, trying this and trying that, in pursuit of a quick rewrite. All attempts failed.

I submitted a plan for a nine month rewrite, using our current personnel and the Pascal language we'd used for years. The company's owners said that was out of the question -- they needed the rewrite in two months max!

The development manager found the magic bullet -- let's call it SharpShooter. It had been recommended by consultants, the trades, and his fellow managers in other companies. Built-in database connectivity, screen painter, RAD. The development manager bought it and put it through a two week feasibility, conducted by his programmers. The results were less than promising, but the development manager found a SharpShooter consultant who promised that yes, SharpShooter was the answer. Our programmers just needed SharpShooter training and an experienced SharpShooter lead programmer. The SharpShooter consultant became the lead programmer, and we rolled up our sleeves and went to work.


SharpShooter failed. It produced a slow and bug-ridden product. SharpShooter couldn't format our complex reports. And the convoluted workarounds necessary to get it working devoured quadruple the time saved by the screen painting and database connectivity.

Next, the development manager found an obscure RAD (call it Relativity) to get the job done in two months. Programmers were trained -- development begun. The shop went supernova, its huge flame visible to the naked eye of every headhunter and want-ad peruser in 1987 and early 88. The development staff tripled in size, even while their experienced programmers were leaving. I left mid-year.

The project slogged on, month after month, staffed by a tired young crew with little programming experience no industry knowledge.


I came back for a visit. The development manager was long gone. The programmers were gone. The supernova was a burned out, dark star.

Two employees populated the large development center, trying to sell the almost completed program for pennies on the dollar.

Two months?

Steve Litt can be reached at Steve Litt's email address.

The Magic Bullet, Part 2

By Steve Litt


My client, a large worldwide law firm, needed a timesheet system, so one of their employees and I created it. For the batch processes and communication we used C and C++. For data connectivity and user interface we used Clarion 2.1.

Clarion 2.1 was the best RAD of its day. It not only supported database and screen painting, but it would construct an input screen and/or a picklist and/or report based on the structure of the table involved. To eliminate bug-prone workarounds, it came with a quality programming language. On data driven user interfaces, it cut development time by a factor of four or more.

Development and deployment were done in steps over the course of a year, the whole project costing less than 2 programmer years. The timesheet front-end took a month or two. We were hailed as heroes.


Would you believe they're still using it? The back end accounting package has changed, the operating system has changed -- everything's changed except that timesheet system. They'd love to replace it with a modern GUI, but none of the available packages has the time-saving features in our 1990 program.

In the past 8 years, that timesheet system easily handled well over a billion dollars revenue, with little programmer intervention or tech support. It takes a licking and keeps on ticking.

Steve Litt is president of American Troublebusters and Troubleshooters.Com, and editor of Troubleshooting Professional Magazine. He's also an application developer and technical writer. He can be reached at Steve Litt's email address.

The Magic Bullet, Part 3

By Steve Litt


I couldn't pass up the opportunity. A good front-end for Concordance (that's the premier litigation support database) can double input speed and cut errors by a factor of 10. Without going through the arithmetic, such a front-end can save a law firm or service bureau $2000.00 per week, assuming they have 10 people inputting the data. Many shops have more. Since each law case is different, front-ends are created on a per-case basis. That means only a law firm or service bureau with an on-staff programmer can have a front end. At least that's how it was until I created EasyCoder.

EasyCoder is a completely configurable front end to the Concordance database. A non-technical person can set up a new case in a half hour. It has by-function and by-coder security, picklists, freeforms, standard input fields, Concordance database creation and upload, coder Bates range assignment, configurable field definition, tab order and upload order, and Bates overlap checking. Installation is a simple as copying a few files. I developed EasyCoder in three weeks.

EasyCoder was not work-for-hire. I budgeted a month of my own time to create it. To accomplish that, I needed to go RAD. Trouble is, which RAD?

A year ago my first thought would have been Delphi. But I've been disappointed with version 3 of C++ Builder and JBuilder -- GPF's, hard to follow interface, and worst of all, a help system you can't Alt-Tab to.

Powerbuilder would have been my next choice. Easy, powerful, ultra-quick development. But deployment is a nightmare, with DLL after DLL. And the ODBC configuration?! I'm the sole tech support for this product, so it had to be simple and work every time, in a wide variety of environments over which I have no control. Powerbuilder was out.

VB would have been a good choice. Ultra-quick development, and the most corporationally-correct development environment on the planet. With VB the job might have taken as little as two weeks. But unless I was willing to go back to slow-as-molassis version 3, I'd have the same deployment problems as Powerbuilder.

Java would have deployed just fine, but it's runtime is a little too slow for an app whose sole justification is speeding input.

I picked Clarion 4.0 for Windows. Once you define the database, it builds forms and picklists. It sports a rich, robust language for "off road" programming. A nice event model. A very nice, completely OOP application framework, augmented by code-generating "templates", and at the highest level, wizards.

Deployment? ODBC not needed on non-client-server apps, and the entire executable can be placed in a single, native .EXE. A compiler option can make a 16 bit and 32 bit version that are functionally identical. The finished product is rock solid.

I've demo'ed the product for several industry professionals, all of whom were enthusiastic in their praise. I'm now in the process of recruiting representatives to market EasyCoder.

Three weeks.

Steve Litt is president of American Troublebusters and Troubleshooters.Com, and editor of Troubleshooting Professional Magazine. He's also an application developer and technical writer. He can be reached at Steve Litt's email address.

RAD Reality: The Challenge is in the Choice

By Steve Litt
Clarion 4.0 was the ideal choice for a guy needing a high quality, reliable, easy to deploy network app in three programmer weeks. It would have been a lousy choice for a large shop -- too hard to find Clarion programmers or expertise (I hope that changes -- Clarion is the quickest and most reliable environment I've found).

VB's a great choice for easy Client-Server apps. Every college graduate has VB training, and former mainframers learn it easily. But it's not OOP, there's not much framework, and it doesn't scale well. For a big app you'd choose something more like Powerbuilder.

Powerbuilder is built from the ground up for data integration and quick development of large, centralized enterprise systems. It lets you code where you want to code, SQL where you want to SQL, and drag and drop where you want to drag and drop. It's faithfully OOP, and very easy to create, inherit and use new classes. Its Datawindow objects are the envy of the industry. But deployment is a DLL nightmare (at least in versions 3, 4 and 5). It's practical only if you control the target desktop or network, meaning in-house apps only. And it's particularly unforgiving of certain bad programming practices, such as incorrectly adjusting the menus at runtime. Such programming practices are the source of Powerbuilder's undeserved reputation as "GPFBuilder".

In reality, RAD is a spectrum, not a state. Some environments develop more rapidly than others, and yet they're all more rapid than editor based C++. Some generate simple apps in 5 minutes but take months or years to adapt to complex user requirements. Others are slow at the start but cross the finish line first on complex projects. Thus the title of fastest development environment can hinge on the flexibility or inflexibility of the user requirements.

The smart organization thinks long and hard before changing development environments. If the present environment is producing decent apps in a reasonable timeframe, and it's adequately supported by its vendor, why change? There's a huge investment in the programming staff and their training -- why throw it out. Development environment changes carry morale consequences -- not desirable during a programmer shortage.

There is no "best" RAD environment. Most are useful in the right circumstances. The trick is to match the environment to the organization, end product, and situation.

Steve Litt is president of American Troublebusters and Troubleshooters.Com, and editor of Troubleshooting Professional Magazine. He's also an application developer and technical writer. He can be reached at Steve Litt's email address.

RAD Myth: It bails you out of trouble

By Steve Litt

The Promise

You say you've changed development environments three times in three years? And never finished a product? And your angry developers have their resumes on the net? And with the programmer shortage, it's hard to get more? And Y2K's fifteen months away, but the only functional version of your product was written in 1984? And you lost the source code? Don't despair. AwesomeRad II will save you.

AwesomeRad II is a completely drag and drop, intuitive, multi-tier, web-enabled, non-coding enterprise development environment with complete object model connectivity and full open-system third-party support. It's won awards from Development Times, Enterprise Engineer, and Modern CIO magazines. It's used in all the Fortune 500 companies.

AwesomeRad II saves a fortune in programmer salaries. You can get rid of your whiny, overpriced and obsolete C++ programmers. Hire entry level programmers who haven't been polluted by the old technology. Give em a week's training in AwesomeRad II, and they'll give you a completed app before you can say Y2K. I guarantee it!

The Real Deal

A properly selected RAD tool, with adequate training and a reasonable timeline, given to a skilled, well managed and functional development organization, can work miracles.

But it can't heal the sick. RAD can't erase mismanagement or the morale problems it causes. It can't make a green programmer perform like an experienced one. It doesn't replace industry knowledge or data architecture awareness. In the hands of an inexperienced, mismanaged or dysfunctional development crew, it produces garbage.

Everybody knows this. But all too often desperate technology management will reach for a new RAD to undue prior mistakes, much like a drowning man will grasp at a straw.

Steve Litt is president of American Troublebusters and Troubleshooters.Com, and editor of Troubleshooting Professional Magazine. He's also an application developer and technical writer. He can be reached at Steve Litt's email address.

Letters to the Editor

All letters become the property of the publisher (Steve Litt), and may be edited for clarity or brevity. We especially welcome additions, clarifications, corrections or flames from vendors whose products have been reviewed in this magazine. We reserve the right to not publish letters we deem in bad taste (bad language, obscenity, hate, lewd, violence, etc.).
Submit letters to the editor to Steve Litt's email address, and be sure the subject reads "Letter to the Editor". We regret that we cannot return your letter, so please make a copy of it for future reference.

How to Submit an Article -- NOTE BETTER POLICY

We anticipate two to five articles per issue, with issues coming out monthly. We look for articles that pertain to the Troubleshooting Process, or articles on tools, equipment or systems with a Troubleshooting slant. This can be done as an essay, with humor, with a case study, or some other literary device. A Troubleshooting poem would be nice. Submissions may mention a specific product, but must be useful without the purchase of that product. Content must greatly overpower advertising. Submissions should be between 250 and 2000 words long.

By submitting content, you give Troubleshooters.Com the non-exclusive, perpetual right to publish it on Troubleshooters.Com or any A3B3 website. Other than that, you retain the copyright and sole right to sell or give it away elsewhere. Troubleshooters.Com will acknowledge you as the author and, if you request, will display your copyright notice and/or a "reprinted by permission of author" notice. Obviously, you must be the copyright holder and must be legally able to grant us this perpetual right. We do not currently pay for articles.

Troubleshooters.Com reserves the right to edit any submission for clarity or brevity. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com. Authors: please understand we can't place hyperlinks inside articles. If we did, only the first article would be read, and we can't place every article first.

Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):

I (your name), am submitting this article for possible publication in Troubleshooters.Com. I understand that by submitting this article I am giving the publisher, Steve Litt, perpetual license to publish this article on Troubleshooters.Com or any other A3B3 website. Other than the preceding sentence, I understand that I retain the copyright and full, complete and exclusive right to sell or give away this article. I acknowledge that Steve Litt reserves the right to edit my submission for clarity or brevity. I certify that I wrote this submission and no part of it is owned by, written by or copyrighted by others.
After that paragraph, write the title, text of the article, and a two sentence description of the author.

URLs Mentioned in this Issue