relational for what? [was: Design Principles Behind Smalltalk,
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
> 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*
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
> 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? :-)
More information about the Squeak-dev