Robelle Tech: Building Better Software

May 2001

Boosting Your e3000 Productivity

Building Better Software

By Bob Green

As long as there has been software, there has been a software quality problem. Software continues to be less reliable than hardware, and may even be getting worse, at least for PC and Web software. Good programmers seek solutions to making software more reliable and closer to what the users want.

In many HP 3000 environments, creating software in projects remains the primary way to introduce applications and enhance functionality. Knowing the rules for Building Better Software can save you time and money, and enhance your career as well as your software. This is the topic of the paper that I am presenting at this year’s HP World. (If you’re reading this in Chicago at the conference, the talk is Wednesday at 3:30 PM.)

Here are some extracts from my presentation. You can attend the full talk for much more, or email me at bgreen@robelle.com for a copy of the written paper.

Do You Have Shaky Foundations?

Most software engineering and quality papers assume that you have some sort of reasonably good architecture in place. What happens if you don’t?

What if you are at the point of making architecture decisions? Think of Web-enabling a big, old, badly-designed minicomputer application written in COBOL, with a proprietary database and screen interface. Developers need strategies for dealing with the real world where they must build on top of questionable architectures. How do you make quality decisions about the architecture, when it seems that it will be months to years until you can actually demonstrate it?

I know a smart, young software developer named Tyler Close. Tyler started his own software firm, using awards he won in Canada for engineering excellence as a student. When asked about the lure of year-plus projects to “really get things right,” his immediate response was:

“Never, ever, under any circumstances, go years without having something to demonstrate. It’s depressing for the developers, worrisome for the managers and fatal for investors. My rule of thumb is to plan to have something to show every four months and not let it slip to any more than eight. (Perhaps a habit left over from my Waterloo University co-op days, when you only had four months to work with.)”

One way to avoid year-long projects is to build on existing architectural elements with known behavior. In this way, aberrant results can be traced to a single new object. But what if the existing elements that you depend upon are badly designed, unreliable, and inconsistent?

Tyler Close suggested building a wall between you and the legacy system. Turn it into a black box, define your messages and responses, then test them and only use those messages:

“When selecting what functionality from the old system to use, be a minimalist. Avoid including stuff that might be nice to have but isn’t necessary for the project at hand. In software design, never build something until you have a pressing need for it, since if you don’t really need it, you don’t really know what the requirements are. If you don’t know what the requirements are, you won’t build something useful.”

Resist getting sucked into the complexity of the “bad software- It helps if you construct two object models of the existing system: one for how the system currently works, and another for how you would like it to work if you had the time and resources to rewrite it. Having this better model to program to is an aid in keeping the ugliness of the bad system from seeping through your wall.

Tyler suggests being humble enough to consider alternatives:

“Avoid hubris. It is very hard to look at a single, poorly designed system and generalize from that to a flexible, good design. The same way your eyes need at least two vantage points to see in 3D, your design intuition needs at least two examples to see the general design patterns in a complex system.”

Quality Is Different from Correctness

Quality is not the same thing as Correctness, which is producing a program that exactly implements the design specifications. What if the design does not specify what the customers need and want?

A creation can have engineering correctness and still fail. For example, I once programmed an accounts receivable system that matched the design specifications when done. The software was fast and reliable, and it produced detailed reports on who owed what. It was a correct system.

Unfortunately, the collections from customers went down instead of up after the software took over. We had overlooked one key element of the old manual system.

Our clerks would pencil small notes on the account cards to explain difficulties in matching payments to invoices. When the cards were copied and mailed as monthly statements, the recipient clerks would read those notes to iron out difficulties such as tax overcharges. We failed to reproduce these informal notes in our formal system, so the errors were not getting resolved. Communication had stopped. And it was the largest customers who had the most errors, and they used any excuse not to pay their bills.

Once we gave our clerks the ability to pen notes on any receivable item, the problem resolved itself. But it taught me a valuable lesson.

Who Is the Customer?

When I wanted a screensaver for my Anguilla News Web site (www.news.ai), I bought Slide Show Toolbox (www.midnightblue.com) to convert JPG photo files into a Windows screensaver.

I was the customer of the SST product, but the actual target users were the visitors to my Web site.

Therefore, the screensaver needed to be as small to download as possible, since the Web was the delivery method, not a CD. And installation had to be as simple and foolproof as possible, since many of my visitors were computer novices. My “design” called for an executable download that could install itself and become the active screensaver.

I used the tool to build an auto-install screensaver and I tested it on every computer I could find. The screensaver installed and ran fine on Win95, on WinNT 4.0, on an older Win95, and on a new Win98. But on a Win95 PC upgraded with Active Desktop (halfway to Win98), it aborted with a disturbing message and did not install the screen saver.

Since Web users get more conservative every month due to the vast numbers of new users with no previous computer experience, I decided against using the auto-install. Even though only a few users might run into the problem, my judgment was that they would be very upset. Instead, I wrote detailed installation instructions on how to do a manual installation. Several months later the tool vendor found a way around the problem in Windows, but it came too late for me.

Projects Must Be Grounded in Reality

For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled. — Richard Feynman

Physicist Richard Feynman was a member of the Presidential Commission that investigated the crash of the Challenger shuttle. He concluded that NASA management exaggerated the reliability of the shuttle to the point of fantasy, then regularly and subtly reduced safety criteria to maintain the published launch schedule.

Fantasy by top management has a devastating effect on employees. If your boss commits you to producing a new accounting system in six months that will actually take at least two years, there is no honest way to do your job. Such projects usually appear to be on schedule until the last second, then are delayed, and delayed again. Management’s concern often switches from the project itself to covering up the bad publicity about the delays.

Information from the bottom which is disagreeable is suppressed by big cheeses and middle managers ... Maybe they don’t say explicitly, “Don’t tell me,” but they discourage communication ... it’s a question of whether, when you do tell somebody about some problem, they’re delighted to hear about it. If you try once or twice to communicate and get pushed back, pretty soon you decide, “To hell with it.” — Richard Feynman

An objective project goal unleashes people’s minds to discover solutions and attain the goal. An irrational goal just short-circuits the best within them.

In software projects, the reality that cannot be ignored is that customers seldom know exactly what will help them and that programmers are fallible.