In the 1980s, a decade in which it was impossible to tell the actors from the politicians, it was fitting that the Macintosh gave anyone with a little cash the ability to produce absolutely gorgeous documents with absolutely no content.
Now rapid software-development tools bring the same potential to developers. If you are quite reasonably looking to such tools to reduce your software backlogs, be careful: It’s as easy to abuse them as it is to use them well.
We’ve seen such abuses up close, and they’re scary. Here are a few of the symptoms. If you spot them in your developers, take action quickly.
All interface, no content. You may have seen this one before. The tool lends itself to creating graphical interfaces, so that’s what the developer does first. The interface looks great, but none of the underlying code is present.
This symptom is bearable if the developer knows the interface is just the start. It can even be good — if the developer plans to try out the interface on a few users before filling in the meat of the application.
The danger comes when the developer thinks the interface is the bulk of the job and the application logic is something to “touch up” or “plug in at the end.” When you hear those phrases, watch out: Your development cycle just got longer.
Baroque interfaces. Not every application’s interface has to push the edge of the human engineering envelope. If, for example, your application needs screens in which users must pick one choice from column A and one from column B, why do anything more complicated than that?
Failure to solve the problem at hand. Applications exist to help users automate business tasks or in other ways gain competitive advantages. As long as developers keep those goals in mind, you’re fine. Some tools, however, tend to seduce developers away from those goals and toward other ways of working.
Database front-end development tools, for example, are generally good at table creation and management, but not as good at incorporating programmatic logic. Developers caught up in the spirit of those tools can spend all their time designing complex data relationships that are not relevant to the task at hand. We’re all for future planning, but you can also plan so long that you never get any work done.
Failure to remember the problem at hand. This symptom is the next stage of the previous one. Sometimes developers get so caught up in their tools they completely forget what users want.
Let’s say you want to build a simple application to compare the profit-and-loss sheets of different divisions. Assume the data is in a database. Simple, right? Let users pick the divisions to compare, and then display the profit-and-loss data for those divisions side by side. Hard to mess up.
Unless, of course, your developers realize you have lots of divisions — too many to fit on a single screen. So they work for weeks to find clever graphical ways to show an unknown number of divisions at once. (They could pick a number and ask users if it’s OK, or scroll among many, but that would be cheating.) Meanwhile, the original problem remains unsolved.
None of these symptoms are inevitable. All applications, whether you’re building them with assembly language or Oracle Card, should be subject to periodic review. All developers should present their plans to user representatives for approval.
In short, most of the rules for smart development that have always made sense still make sense; you just have to deal with a faster pace now.
If you’re not being smart and careful about your application development, however, keep an eye out for these symptoms and nip the rapid-development disease before it spreads.