The Leap From Demo to Reality
Many software development managers fail to understand the
de-motivating 
effect and
ridiculous scheduling pressure the foolish perception a "demo"
can create, and they erroneously allow an environment where such
perceptions go uncorrected and undeterred. This inevitably leads to
a project death march as those higher up the food chain start
imposing negative pressures on the project (because of a belief
that it's either almost done, or so easy that it should have long
since been done: No matter what the troops in the trenches do
they're a disappointment), and the actual developers involved on
the project feel very little motivation because they know that
their hard work and technical ingenuity is overshadowed by a belief
that what they're doing is so simple it's unworthy of praise.
This situation often occurs due to two very common
scenarios:
-
The developer is asked to throw together a quick and
dirty demo to allow management to visualize the product. Despite
the fact that in the real application the GUI is merely the front
end on an extremely complex set of interoperations and black boxed
functionality, and despite the developers' plea that they audience
understand that it's just a quick and dirty example, perceptions
will be formed that the project is basically almost done, or that
it can be accomplished in so little time it can be quickly
"finished". Throw an edit box on a form and a couple of radio
buttons and input boxes and you can convince people that you've
written a word processor...the trouble is that often they believe
it.
-
A jealous or very unskilled co-worker with access to VB and
Microsoft Paint, upon seeing that real projects take actual
planning and diligence (i.e. time), throws together an "example"
form with a couple of controls (i.e. to a real developer about 20
seconds of "work") and then parades this to coworkers as comparable
to the real thing. This is pretty much the same as 1, however
instead of unintentional misinterpretations, it's malice and
degradation by someone who hoping to score some political points
where possible. This is fairly common, especially in shops where
the software development team is heavily relied upon, and hence
often despised.
In either instance the net effect is the same: The foolish
perceptions and misunderstanding of the difference between a
quickly thrown together demo and an actual software product blur
non-developer's (as well as naive developers) understanding to the
point where they believe that the addition of buttons on a form is
the real work, and the implementation that achieves the
functionality of said button is the easy part (i.e. drop a button
that says "Spell Check!" aside your edit box and you're 9/10ths of
the way to having an integral spell checker!). Nothing could be
further from the truth. This same misunderstanding is why RAD tools
are seen as the silver bullet that revolutionize software
development (despite massive evidence to the contrary): In actual
reality the most certainly unRADish tool Visual C++ is responsible
for the vast majority of successfully implemented, large scale
software products, yet most people still presume that Visual Basic
would be the successful candidate given it's ease of use and quick
0 to demo time. They fail to realize that the short
term productivity gains are insignificant over the longer term in
an actual full-scale product, and often the abstraction that some
RAD tools offer as a "benefit" ends up taking more time over the
project scope than going to the metal from the start. As a fan of
Borland's Delphi I've seen this paradox many times, so I carefully
integrate both Visual C++ for the "hard" work, and Delphi for the
container GUI work. Unfortunately many developers have yet to
realize that there isn't always a silver bullet for every
requirement and they still clutch to the idea that there is single
solutions for every need.
The point of all of this is this: Managers and salespeople have
to understand that in the vast majority of the application the
"what you see" GUI represents a minute tiny fraction of the work
that entails a shippable product. Developers need to be extremely
vigilant to press this point home, and even though your manager
might seem impressed at what you've "accomplished" in the short
term (hence you might avoid pointing out the infantile status of
the development), it will quickly turn to disappointment when you
fail to morph it into a well crafted retail package even a year
later.