Under Construction

I am updating an old paper of mine on 'Improving Software Quality', adding newer examples and seeing if I still agree with it in the Internet age. Since I have temporarily run low of "treehouse" links to post, I am switching to the topic of software quality until this paper is rewritten. If you don't care about software, visit my Treehouse Archive where you will find dozens of fun stories and links about adventure and treehouses.

Note: editing the paper in the Pitas environment was too slow and cumbersome. An experiment that failed. Therefore, I am going to archive this work in progress, go back to editing with a real text editor, and return the Treehouse page to treehouses!

The idea that inspired my approach to software was Step By Step, a method created by a French IT manager.

Below are the main headings of the original paper. I will be filling in ideas and links under each as I explore whether they are still good suggestions and whether are any major new suggestions that must be added.

Under Construction

What the software cost you to make does not matter. How long and hard you worked on it doesn't matter. How few bugs there are doesn't really matter either.

What matters is the value to a living, breathing person.

What about the need for speed? The PC revolution reduced project deadlines from years to 6 months and now the Internet revolution has reduced them again to weeks.

Under Construction

By involve, I mean "involve in the actual software generation process", not just "interview for needs". If the first time the user touches some actual software is when the project is complete, you can be confident the project will fail.

Under Construction

Harvard Business Review recently published an article on a similar concept: Rapid Prototyping:

But the real power of rapid prototyping comes less from the technical momentum it generates than from the human interactions it facilitates. It isn’t “show and tell,” it’s “show and ask.” It creates conversations between people that would not otherwise take place.

Cyber Rules: pg 176. How Cisco became a web-based company where the customer can obtain self-service for most questions? They started small.

The first agent we put on the Net was the status agent. It allowed you to go on the Internet, enter a P.O. number to find out what the status of your order was, and if it was shipped, hotlink directly to FedEx or UPS and get the exact location. ... Because [this] was successful, we started introducing new agents every three months, approximately. The pricing agent, the lead time agent, the configuration agent, the order-placement agent, the invoice agent, the service order agent, and the service contract agent.

Under Construction. Don't get sidetracked on perfect infrastructure. Use object oriented techniques to isolate the infrastructure from the application logic, so you can go back and replace the infrastructure.

All technological solutions approximately follow the Inside the Tornado bell curve. That is, they start with a few keen pioneers and early adopters, grow into the mainstream, then decline. What should be the different quality measures at different points on the curve? For example, our client server product is still trying to "cross the chasm" from adventurous pioneers to practical mainstream, and that's where most of the resources need to go. So how much effort should be put on more minor quality details?

Bowling alley strategy for making this leap involves a "whole product" for a specific market. That is, you solve some actual problem, completely. Rather than 60% of a bigger abstract problem.

Under Construction

It is very hard to know what the user of a software program or web site really "wants" or how easily they find it with your creation.

If value to the client is the heart of "quality", then your efforts must adapt as the client's values adapt. This is especially important in the "life cycle" of a software product (or any technology product), where the values of the pioneering first customers are quite different from those of the final conservative customers before the software is dropped.

Usability testing is one option:

Jakob Nielsen's Useit.com has numerous articles on usability of software and web sites:

• Voodoo Usability: how NOT to measure usability
• Cost of User Testing a Site

Who is the Client? I was creating a screensaver for visitors to one of my web sites and purchased a tool that would convert a list of JPG image files into a screensaver for Windows. I was the client of that tool, but the actual users were the people who visited 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. What I thought would be best for my users was an executable download that would automatically expand the screensaver, install it on the hard drive in the proper directory, and make it the active screensaver.

Shortly after I purchased the tool, the vendor upgraded it to include an auto-install option. Great! I created an auto install screensaver and it worked great on my Win95 PC. But I decided I better try it on some other configurations. It worked on Win NT 4.0, an older Win95, a new Win98, but on a desktop with Win95 plus the Active Desktop the install aborted with an ugly message and did not install the screen saver.

Web users get more conservative ever month, on average, due to the fast numbers of newbies with no previous computer experience.

Under Construction

Article on Bugs that I referenced in Shift magazine: Click Here. This paper highlights the divergence in bug tolerance from IT dept server software of the past and the Windows-based PC software of today.

Is W2K still okay with 64k "bugs": Register story link.

Regression Testing. Program modification risks introducing bugs or even re-introducing old bugs (at least with the current state of software tools). Therefore, it is essential to do regression testing on each new revision of the software.

Working on a Shakey Foundation

Most of our software engineering and quality talks 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 ugly minicomputer app written in COBOL, with a proprietary database and screen interface). How do you make quality decisions about the architecture when it will be months to years until you can actually demonstrate it?

Both of these questions must balance long-term needs against shorter-term views of quality. Reconciling these in terms of resource management is difficult. Step-by-step method doesn't work very well when you are in a major architecture change, since at that point you are in the middle of a revolution and not an evolution.

Under construction

Forbes opinion piece: We have quality, need time. But is quality really a fixed attribute like "hardness"?

Software Research Institute Quality Hotlist

Software Quality Institute

Software quality week

Kaner, quality training and writing

Quality Links