relational for what? [was: Design Principles Behind Smalltalk, Revisited]

Peter Crowther Peter at ozzard.org
Tue Jan 2 23:35:05 UTC 2007


> From: Howard Stearns
> Peter Crowther wrote:
> lots of good comments. (Thanks.)

Thanks for the response - didn't know how they'd be taken.

> But the other side of the coin is that so many projects in this "easy
> problem" world are failures. A higher failure rate than the
clean-slate
> hard problem world!

Yup.  Because the (technically) "easy problems"	are organisational
nightmares, with vendor/customer politics, sales/tech politics, many
stakeholders at the client who are using the system for political
infighting and empire-building, and (in general) at least one key
stakeholder who will do his/her best to sabotage the project as it's to
their personal advantage to have it fail.  And that's in a *small*
project.

By contrast, the clean-slate projects typically have a few key
stakeholders, clear and non-conflicting requirements, and less in the
way of internal politics.

Consider the following (typical) example of an "easy" problem:
- The client invites tenders for a specified system;
- The salesperson wants their bonus, so deliberately tenders for less
than they know the system will cost to develop;
- The developing company wins the bid;
- The salesperson gets their bonus, and moves on to the next sale;
- The project *cannot* be a win for both remaining sides, as it is not
possible to bring it in with all features and within budget - and that's
ignoring requirements creep;
- Somebody loses.  Probably both sides lose: there's no profit in the
job, and the end system doesn't do what the client wants.

Unless you consider the systems angle, you don't see the full system.
The *full* system includes all the humans who interact to produce it,
and therein lies a large chunk of the problem.

> I want to understand why the three-tier projects
> fail. And how to avoid that. I know that there are people who can make
> them succeed despite the math, using leadership and operations
research
> and charm and ruthlessness and lots of money, or whatever. But that's
> not my domain. I may not have the choice to always pick the right tool
> for the job, but I do want to try to understand what makes something
> the right (or wrong) tool.

>From observation (perhaps with charcoal-tinted spectacles), I think
you're looking at the end of the problem that can make a few percent of
difference.  If, instead, you look at all the messy leadership, charm,
ruthlessness and money side, I think you're looking at the side where
most of the difference in the success of a project is *actually* made.
It's possible to do so, but you need to apply the principles of systems
analysis... and competition, of course.  Even if your company is
sensible and bids at a level where they can do the job, they'll be
undercut by a lying salestoad from a company who (eventually) can't.

Cynical?  Moi? :-)

		- Peter



More information about the Squeak-dev mailing list