Volume
2, Issue 8, September 1998
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!
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".
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.
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:
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.
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.
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.
Two employees populated the large development center, trying to sell the almost completed program for pennies on the dollar.
Two months?
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.
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.
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.
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.
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.
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!
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.
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):