Re: The Impossible Project: not so funny... (Was: what's wrong)

[Tim Ottinger <tottinge@dave-world.net>]

Kazimir Majorinc wrote:
> 
> \x1eTansel Ersavas (tansel@deep.net) wrote:
> 
> : 1. "The cancelled projects with money down the drain" is not a part of
> : the OO problem, but a general IS one. I know two 100 million projects
> : cancelled after 5 years of great hopes, money and sweat, and they
> : weren't OO projects. Every year, hundreds of BILLIONS of dollars are
> 
> Ubelievable. For that money I could do anything they want. Simulation of
> whole world economy? No problem! Programming language more complicated than
> C++? No problem! I do not understand? I can not imagine problem which can not
> be solved with that money, except if it comes from mathematical world.

I added up all of the reasons I've seen things fall apart, and put them
into a single nightmare scenario, to show how you can fail even with
great, steaming wads of cash.

After all, it's my assertion that very few projects fail for reasons of
technology.  There are so many more reasons.

Even with OO, IE, or SA/SD, or any magic bullet methodology in the
world,
the only answer to this one is to walk away and save the $M.

                              :-(  :-(

The customer has absolutely no idea how they want
to use the system, or what it should do, or how they'll run their newly
formed business.  They're inventing business processes as they go. 
Every
requirement may be changed or scrapped since they've never actually
done the work they're gearing up for.

But the software must automate all of their processes, and must be
intuitive enough that it can be operated expertly by 10th grade 
students (not honor students) with less than one day of training.

You'll be supporting three customers in three different markets,
who will use the system different ways.  These way's haven't been
decided yet.  

It must be accurate to the 9th decimal place (right side).

Your staff has never programmed in the language and environment that is
mandated by the customer.  They've also never worked in this domain
before.  You are similarly clueless.  You are not allowed to buy tools
or libraries.  Only salaries are acceptable.

The hardware acquisition cycle runs about 14 months.  The software
acquisition cycle runs 10.  Acquisition cycle for hiring is 8 months.
The company requires all applicants have a business degree.

You will not be allowed to interview the client directly.  Instead 
you will be expected to work through a  mediator.  The average 
turn-around for a question will be about three weeks.

The database you'll be using is also mandated, and doesn't work yet.

The system must control yet-unspecified equipment in realtime, but
provide online reporting which is up-to-the-second in an RDBMS that
is hosted on Windows NT box which is to be completed in two years,
and the OS will be ready in three.  Unless it doesn't work or
the client changes their mind about the platform.

			:-) :-) :-)

Okay, I'm being silly, but there is nothing a good or even an excellent
developer can do with total uncertainty and ambiguity, especially
when the customer is hostile or unapproachable.  If requirements are
not determined, and the users refuse to settle you are likewise in
a position where you probably can't make much success.

Now any small set of these problems are present in every single 
project.  Hopefully, we can educate our users and customers so that
we don't have too many at once.

In this case, it isn't OO that fails, it's the decision to try an
build a project that can't work.