Software Reality Community After you've read the article, be sure to check out the accompanying message forum...

Development By Demo

By Leslie Mills
September 16, 2001

A lot has been said about the utility of making a demo for your customer, much of which is true. A demo helps give a visual representation of what the designer believes the customer wants, and gives the customer a basis for comparison.

However, if either management, marketing, or the customer demand a functional demo, be afraid. Be very afraid.

Functional Demos are nothing but a short-term attempt to get something they can sell as quickly as possible, with the inevitable (but seldom acknowledged) effect that the quality of the product suffers. It starts out reasonably well, since the term "demo" gives the programmers a false sense of security. The programmers, working under vague requirement specs, quickly deliver a simple first version. Management and Marketing (M&M) present the result to the customer, and everyone is happy.

At least, until the customer wants some changes. M&M gleefully inform the customer that his changes (based on what the customer saw) will be implemented in a few weeks.

Here is where the danger begins. The programmers are now faced with the choice: 1) build a new design from scratch, or 2) change the demo model. Given the short time limit, they change the demo. M&M then takes version 1.1 (or version 2.0) to the customer, and the cycle continues. The demo becomes the final product when the customer has all the features he wants, or until the cost/time of fixing the demo makes further tweaking impossible.

M&M have their own reasons to use a "development by demo" approach. Demos are a selling point, and functional demos allow the customer to take a copy home and use the product. Development can be cut short if the demo is close enough to the final product to keep the customer happy. Even better, since it is a demo, M&M can even convince the customer to test the product for them, reducing their own QA costs.

Unfortunately, they fail to recognize the disturbing underlying trends: each set of changes take longer and longer to implement. More errors appear in the product, and they become harder to debug. Programmers go into firefighting mode, patching problem symptoms rather than working on a coherent functionality.

How bad can it get? Here are a few of my own stories:

Example #1:
It was a VB program. The previous programmer evidently was learning the ropes, because each screen was a VB form, with its own copied navigation buttons. The content was impossible to alter unless you had VB yourself, and fixing one item of the navigation bar meant fixing every screen of every course. Because it was a "demo," I did not have the time to fix the design flaws, and instead had the joy of altering only one course, which in this case meant changing each and every screen of the 100 screen course.

Example #2:
Another demo, better designed than example #1 mainly because the programmers were more experienced. However, to speed development, the course content was still integrated with the course engine itself. When the possibility of delivering courses over the internet came up, it was effectively impossible to convert the course from its old system to a leaner format that could be quickly transmitted via modem.

Example #3:
This was truly a developer's and programmer's nightmare. While the course engine was separated from the course content, the course content was separated from itself. Each screen had their representations made by at least three files, with a twisted 8.3 file naming convention that screamed insanity. You could not see the results of your course writing until you compiled the course, and compiling the course was a buggy nightmare of mismatched procedures. Some of our programmers managed to talk to the designer of the monstrosity, who simply told them that all he did was make a demo.

A Demo's Legacy
The most destructive aspect of a functional demo is the fact that it tends to leave legacies once put in production. A quickly conceived and poorly designed database structure is going to haunt both programmers and users, mainly because the poor design is going to hold content the customer will not want to have to re-enter. While this can be partially addressed by designing an update system, the tight schedules assigned to making and fixing demos effectively prohibit this until the need becomes overwhelming. At that point the fix is a rushed product, leading to even more firefighting as programmers and developers try to patch damaged data and damaged code.

In the previous cases, the demos ran up to the problems of multiple users trying to access the course via a network. The initial database setup for them in most cases simply was not up to the task. Unfortunately, by the time this became apparent, the demo had already been installed on the client's system, and used. The client did not want to have his employees redo their work.

On one project, we had the opportunity to start fresh, because by then it became apparent that our previous engine simply was not designed to run over the internet. By then the team, consisting of veterans who had enough of demo, proposed a completely re-engineered product rather than trying to hack together a demo.

Management's response: "Could you build a Proof of Concept that such a program will work?"

Immediately this set off warning bells in the team's heads, since the concept of delivering code and data over the Internet had by then been pretty well established. Nonetheless, they slapped together a rather crippled "Proof of Concept."

Management's response: "This is all well and good, but can you set in more features, and speed it up a little in about 2 weeks?"

Team: "Why? This is a proof of concept. We can design a better, more flexible, product from scratch in a few months."

At that point, management tried to pass off a song and dance routine about wanting improvements to the "Proof of Concept". To the development team, this began to look and feel exactly the same as the demo cycle they had grown sick of. Management denied wanting to use a demo, just a working "Proof of Concept" which they would never show to marketing. When the team suggested modifying the "Proof of Concept," and then destroying the source code to ensure no further "development by demo" approach, management's rather panicked reaction confirmed the teams' worst fears.

75% of the team quit in one day, the remainder a few weeks later.

From that, I learned a few things.

1) Learn to identify requests for the functional demo
Note that management may not call it a functional demo, but try to change terms (marketing is particularly notorious for this). Still, you can identify the functional demo easily:

* Will the "demo" actually do a significant part of the job aside perhaps from the GUI?
* Will M&M allow you to scrap the source for the demo?
* After you give them the first demo (and have kept the source code), will they ask for modifications that include more functionality?

If the answers to the above questions are "Yes," then the odds are your demo will be shipped as final product, and you will continue to stretch the software to the breaking point.

2) Try to keep demos nonfunctional, save for perhaps the GUI
Demo software is like a cardboard model of a house to be built. It is perfectly reasonable to set the cardboard model to a reduced scale, and properly cut in doors and windows, and have the result look like a house. It is not reasonable to actually build a 1:1 scale cardboard model, installing plumbing and electricity, and expect someone to sit through a Canadian winter in it. The purpose of the demo is to give the customer an idea what the product will look like it would do. Anything more defeats its purpose.

3) Changing a demo is fine, as long as it remains a demo
This is difficult to do, as this involves keeping the source for the demo and hoping M&M will not try to use that as a base for a quick hack product. However, you can--and in a healthy environment you should--be able to make visual changes to the demo.

4) If you do build a functional demo, be ready to keep working on it
If you do build a functional demo, and it does become the final product, get ready to maintain that product for the rest of its life. Since most demos are undocumented (why document something you intended to throw away?), management will find the only ones who can maintain it are the people who originally built it. This is great for your short-term job security, but it also pins you firmly in one position in the company, and in the worst case it ties your future in the company with that of the product.

About the Author:

Leslie Mills became terminally addicted to programming while in high school. His condition worsened when he took Computer Science at the University of New Brunswick, graduating under questionable circumstances by 1991. Having jumped around several unsavory jobs, he is currently working as a programmer at NB Power.

He is too lazy to write a web page, so instead go to more tasteful content at:
http://www.montypython.net/

Message Forum - Have Your Say:

Post a new message

Good article
Dino Fancellu 

Like *Children*?
HadEnuf? (See the caffeine section at ThinkGeek, if you don´t get it.)

Post a new message

<< Back to Lifecycle