|
Developing Rapids:
Effective examples of how to drown your software development schedules
-- Jonathan T. Ng
There has been a lot of talk these days about Rapid Application Development. With the
advent of development tools such as Visual Basic, Delphi and C++ Builder, companies are
continually promised the hope of developing bigger and better software in less time.
Furthermore, customers are equally excited about their new software arriving months ahead
of schedule. Reality however, is often very different. In today's world, as our companies
continue to strive to meet the false expectations of their own marketing departments and
customers, software engineers are stuck having to make ends meet on the technical side of
things.
How bad can it be, you might ask? As a recent graduate of a software engineering
program at SFU, and having the chance to experience an array of different working
environments, it is most unfortunate that far too many companies are jumping on the Rapid
Development bandwagon without realizing what this entails.
Done correctly, Rapid Application Development (RAD) is possible, as author Steve
McConnell points out readily in his book titled Rapid Development [McConnell, 1996].
However, McConnell is also very quick to point out that not every company can achieve
this, and that more often than not, estimating software schedules is much like building a
house without a clear floor plan. In my personal experiences, I have found this readily to
be the case. I haven't yet found the perfect environment in which the delicate balance of
satisfying customer demands vs. budget constraints has been achieved, but I certainly have
found many examples in which this was attempted, but failed.
Here, therefore are my two biggest pet peeves. (I've listed some other ones too without
examples) If you wish to ruin your software schedule, be sure to follow in the footsteps
of some of these examples.
1. Staff your project with incompetent people
RAD requires proper staffing. According to McConnell, developing software in the
shortest amount of time possible requires a team chosen from the top 10 percent of the
talent pool. Even efficient and nominal schedules require at least the top 25% and 50% of
the talent pool respectively. In one of my recent projects, I had the privilege to work in
the role of a database administrator for a Y2K assessment and upgrade project.
The project essentially involved taking inventory of over 2500 PCs and Macintosh
desktop workstations in a relatively hostile health care environment. I was told upon
joining the project that we were already behind schedule and that I had only "a few
days" to complete a prototype database in Microsoft Access that would be able to
catalogue every piece of information about these workstations. This included hardware
configuration, serial numbers, software, room numbers, and even user drive mappings! Seems
simple enough of a task, I thought, although I promptly objected to the time schedule and
platform. With my objections noted, I told my project manager that I would try my best to
get the database done in time for the entry forms to arrive.
Along with a team of helpers, a map of the system was created using a simple
entity-relationship diagram. By day four, we had already inputted the results of our fast
prototype design into the database with some sample data and forms. Swell! Armed with
this, I approached the project team with the prototype database design. This is when I
began to notice the incompetent staff. Our database design was correct, but the paper
forms used to collect the information had no resemblance to the electronic database. The
designer somehow had the idea that repeating one set of information 3 times would be a
good idea. I cringed at the thought of being a data entry person having to enter all the
2500+ paper forms when the forms were clearly not normalized!
The project did not cease to have incompetence problems. The day before we were due to
arrive on the client site to begin our inventory, we were abruptly held back. Why? The
management of the team had forgotten to purchase the 1600 licenses of an inventory program
required to help assess each machine! Let's do some math. That's 1600 x $10 US a piece.
That's over $25 000 CDN unaccounted for in the budget! It gets worse.
Among the team of explorers (people who actually went to inventory the workstations),
the majority consisted of intern MCSEs (Microsoft Certified Systems Engineers) who
essentially were fresh out of a series of career retraining courses. Most of these team
members used to do other things, and now switched to IT as part of a career change.
Although most of them performed adequately on the job, a few were completely dumbfounded
when they encountered a Macintosh for the first time in their lives! Not only had they
never seen such beasts, they were unable to figure out how to use them given the obviously
biased knowledge they had learned from their MCSE course.
As a result of these and other mishaps in the project, the customer took advantage of
our incompetence and tried to find every loophole in the contract to try to get us to do
more than we had bargained for in the original Y2K assessment contract. Not only did this
bring undue schedule pressure to an already overscheduled project, it brought undue stress
to all team members involved. Within two weeks, 5 people (of 13) had left the project.
2. Methodology?! What's that?
A successful project always has methodology. This methodology may not be an established
software methodology, but it must be one that works. A couple of years ago, I was working
for the federal government on a biometrics research project. I was to help design a new
product that would essentially bridge the interfaces between two numerical analysis
programs. As I always do in my private consulting, I recommended that we hold a design
meeting. Never had I been met with such opposition and surprise.
It wasn't until much later did I fully understand the strange "methodology"
that they wanted to apply to the project. Being research scientists (and having heard the
glories of rapid prototyping), my team thought we would go about doing this application by
experimentation! When I asked them what their requirements were - I was told - "we
really don't know yet, code us something, and we'll tell you if it sounds right!".
Gotta love it, eh? These customers not only had false expectations, but they expected us
to do our jobs in less time, without any methodology, and without solid requirements.
The project never got completed. As far as I understand, almost every developer since
then who has attempted this has failed, because of the (nearly impossible) work
requirements!
Well, there you have it. My two pet peeves about software engineering. Here are some
more, but I will leave them to future months to elaborate.
3. Get managers who are over worked and only care about the bottom line.
4. Use the cheapest tools available. Also, if it comes from a big reputable software
company - it must be good!
5. Your manager's schedule is always right.
Conclusion
The moral of the story is don't buy into the Rapid Development hype. Rapid development
is possible, and when done correctly can be quite a miracle to watch. However, if you're a
company or a team wanting to design a product or implement something for a customer,
please save yourself some grief, and plan it correctly the old fashioned way! Chances are,
if you've got one of the factors mentioned above, you're better off using old fashioned
conservative schedule estimates and come out on budget than guestimate a "rapid
development" schedule without the proper knowledge of what it entails.
References
[McConnell 1996] McConnell, Steve: "Rapid Development,
Taming Wild Software Schedules", Microsoft Press, 1996
|
