Re: Why is OO popular?

From: JXStern (JXSternChangeX2R_at_gte.net)
Date: 05/14/04 

Date: Fri, 14 May 2004 18:12:10 GMT

On Fri, 14 May 2004 16:08:03 GMT, "H. S. Lahman"
<h.lahman@verizon.net> wrote:
>I think customer biases are more of an issue for requirements
>elicitation. What the customers initially think they want is sometimes
>not what they actually need. Also, customers try to be helpful by
>providing solutions they think will be easier to implement. Overcoming
>that sort of stuff makes requirements elicitation something of an art form.
>
>OTOH, software developers are <hopefully> not concerned with that. If
>the developers can look at the SRS and say they understand Why each of
>those requirements is there in terms of domain rules, policies, and
>practices, then the odds are pretty good they understand the problem
>space itself well enough to implement a solution for the requirements.

Wow.

Do you really see this wall between requirements elicitation and
software developers? Suddenly we're back to 1978. Deja vu all over
again.

>[Unfortunately for our industry high quality SRSes are about as rare as
>Pandas and the tools supporting requirements gathering are utterly
>primitive compared to other IDEs. So far the solution is to either (a)
>make the developers write the SRS or (b) have the customer hold the
>developers' hands on an operational basis. Neither of which works well,
>IMO. But that's yet another side issue.]

No, it can't be a side issue, it's the main issue, it's the ONLY
issue. SRS are never good, never have been, never will be, that's why
you have iterative methodologies. Then, the curious mind starts
asking, WHY are SRS never any good?

>> Isn't all this talk of what the customer wants, thread drift away from
>> why OO is popular/
>
>This is a surprise in a thread more than a half dozen responses deep
>because...? B-)

I didn't know we were going to talk about why or whether OO was
popular with non-developers, and frankly, ...

>> I've heard this described as marketing-driven versus
>> technology-driven, if you have a reference where they use this in/out
>> terminology, I'd be curious to see it.
>
>It's a standard view in TQM. [See "A New American TQM" by Shiba,
>Graham, and Walden, 1993, Productivity Press, ISBN: 1-56327-032-3, pg.
>35-36 and 196-198.] I see both marketing-driven and technology-driven
>as Product Out views because the vendor is creating a product based on
>new technology and then depending on Marketing to convince the customers
>they need it.

No, that's not what marketing-driven means, it means taking a survey
of your (potential) customers to estimate the market and come up with
requirements. The major problem being, that 99% of what you get, is
simply a list of what your competitors have on the market already that
you lack, which is usually something you know going in.

>[Historical aside... TQM and other process improvement frameworks went
>through four distinct phases:
>
>Fitness to Standard: Ca. 1950. This was the classic quality control of
>Deming and Jurand. The process was monitored in terms of whether the
>quality met a predefined standard. This was the driving force that
>eventually moved stuff like memory chip manufacturing to the PacRim.
>
>Fitness to use: Ca. 1960. The product was monitored in terms of how
>well it fit the usage needs of the customer. This involved classic
>methods like QFD matrices for determining product requirements. This is
>what got enough features into the cars to make them marketable in the
>'70s and '80s. It effectively moved traditional consumer electronics to
>the PacRim.
>
>Fitness to cost: Ca. 1950 but refined ca 1970. Initially this was
>expressed in terms of unfit product ("bonepiles" in the electronic
>industry) that represented wasted resources. However, in the '70s it
>incorporated more sophisticated economic models in the process monitoring.
>
>Fitness to latent requirement: Ca. 1980. Basically these were
>techniques and processes supporting innovation. The basic idea was to
>systematically seek out paradigm shifts. It was this sort of stuff that
>resulted in things like Sony Walkmans.
>
>Note that the last fitness expressly addresses your issue about about
>excitement features. The "funnel" I referred to in my previous message
>is actually a formal process artifact for dealing with this sort of
>thing. If you are interested, there is an entire book basically on
>this: "Revolutionizing Product Development" by Wheelwright and Clark,
>1992, Simon & Shuster, ISBN: 0-02-905515-6.]

Sounds a bit retrospective, but interesting for all that.

>> Finally, I don't see software development in general, that is, bespoke
>> application development, as following these paradigms at all. At
>> least, the current discussion of whether OO models the world or the
>> human thought process or whatever, is a separate discussion from what
>> the customer wants. Or, I suggest it should be a separate discussion,
>> but several people seem to think these things overlap, even in theory.
>> I cannot agree.
>
>For the record, I don't think OO reflects the way people think; in fact
>I don't find it very intuitive. OTOH, providing a rigorous mapping of
>the problem is space is a fundamental OO tenet, especially at the OOA level.

I'm not sure the "rigorous" description has ever really been
discussed, it was assumed that any good description is a rigorous one,
and that may not follow - pragmatic does not have to equate to full or
even technically correct.

>You seem to be concerned with providing innovative products from the
>customer's view. My position here is that doing that isn't a direct
>software developer responsibility.

That disclaimer makes my head spin.

> The innovation the developer
>provides lies in designing a solution for existing requirements. OTOH,
>that does not preclude developers from participating in the processes
>that deal with product definition and, in fact, the processes associated
>with fitness to latent requirement provide explicitly for that sort of
>feedback. However, the main responsibility for product definition still
>resides with Marketing.

For enterprise apps there is no "marketing" as such, so what then?
You probably still want to pass off the responsibility as a
non-development issue. Like I said, it sounds to me like we've
time-warped back to the 1970s, or 1960s, maybe. Kewl, get out those
50khz, 16kb RAM, punched-card machines, and let's party!

>As a translationist I am inclined to agree up to a point. I got sick of
>moving bits from one pile to another in the early '90s and I regard
>writing 3GL code as thoroughly boring.

I see the current OO languages as 3GL and, for that matter,
indistinguishable from procedural languages from Cobol to Algol to
plain C.

>OTOH, the customer's problem has to be solved somehow at some level.
>That A&D still requires considerable creativity and experience from the
>developer. I would liken the problem to linear programming: one has a
>gazillion constraints (requirements) and one needs to find an optimal
>feasible surface (solution) to fit those constraints. The difference is
>that in the software case there is no single deterministic algorithm for
>doing so; one has to make do with generic methodologies.

The idea of having generic domain objects, say a set of
standards-approved objects for banking, would lead to some kind of
constraint programming within domains. Frankly, I think that is the
medium-term future for software development. It's mildly surprising
it hasn't taken hold already.

>While I agree that eliciting requirements is necessarily a creative and
>experience-dependent activity, I don't think software developers have to
>go there for fulfillment.

I'm not worried about fulfillment, just total project cost and
success. Well, that's where I find fulfillment, I guess.

> In addition, mapping explicitly to the
>problem space is simply an OO technique for attaining its goal of
>long-term maintainability. But I don't think the mapping to the problem
>space itself is particularly OO. SA/SD also mapped to the problem space
>in a quite difference way. IOW, OO just has a unique and more rigorous
>way of providing that mapping through abstraction.

Again, I deny that rigour is involved. I think the language approach
makes it a bit more convenient, is all - but that's enough.

>>>[Caveat. This does not preclude sanctioned R&D. Nor does it preclude
>>>some developer coming up with a bright idea. But those ideas go into
>>>the same Marketing funnel as the rest of the requirements for
>>>evaluation. If it reappears in an SRS, fine; the developers build it.
>>>But if it doesn't the developers stick to the SRS.]
>>
>> Horrible. With an attitude like that by US developers, no wonder
>> development gets outsourced to India. Or, is it US developers trying
>> to copy the subservient attitude by outsourcers (domestic and
>> offshore), that so many US execs just love to see?
>
>Well, I worked for a company that militantly practiced that. In the
>twenty years I was there it went from $200M/yr to become the largest
>supplier of capital test equipment in the world with more than half its
>sales going outside the US while all engineering and manufacturing
>stayed onshore.

Imagine how much better they could have done if they did things right!

(this same thought often occurs to me re Microsoft, they could have
eaten all of IBM by now, if they cleaned up their act just a little)

J.

Relevant Pages

  • Re: implementing roles in OOP......
    ... Developers should never make a process change unless they can justify ... objective data on frequency, effort, and customer cost will reveal. ... collecting data is less important than getting product out the door is ... collaborations among problem space entities. ...
    (comp.object)
  • Re: Why is OO popular?
    ... I think customer biases are more of an issue for requirements ... software developers are not concerned with that. ... new technology and then depending on Marketing to convince the customers ... incorporated more sophisticated economic models in the process monitoring. ...
    (comp.object)
  • Re: XP Requirement Analysis?
    ... >go wouldn't it be best to train up developers on the business domain before ... What XP says is that you should capture your requirements in short ... That you should have the customer (i.e. the domain ... analyzing, documenting, and signing the requirements isn't going to ...
    (comp.object)
  • Re: Why is OO popular?
    ... >>enough about the problem space to be confident there would never be ... >>adding Horse properties to Cows. ... > might already be aware of, possibly beyond what the customer would eve ... If it reappears in an SRS, fine; the developers build it. ...
    (comp.object)
  • Re: My take on DTG->CodeGear and future
    ... don't cost a lot to support? ... Where I work if a large customer says ... I do, however, have big questions on marketing. ... Application server enabling technology for developers ...
    (borland.public.delphi.non-technical)