Re: Why is OO popular?

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 05/18/04 

Date: Mon, 17 May 2004 22:57:45 GMT

Responding to Stern...

>>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.

Quite the opposite. I am saying the developers need to understand the
problem space to keep whoever is writing the SRS honest. Back in the
'70s I was one of those Systems Analysts who talked to the Customer,
wrote up the requirements, and tossed them over the wall to the
developers. It doesn't work; the developers /must/ remove the wall by
understanding the problem space.

>
>
>>[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?

The short answer is that the conventional wisdom holds that writing code
is the Important Thing, so all the effort goes into improving the way
that's done. Fortunately that era is drawing to a close as the
computing space gets automated and the boffins can start looking at
other problems.

>>>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.

There are much better ways to do it than surveys.

>>>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.

While UML itself has a lot to be desired as a whole, the MDA profiles
used for OOA modeling are very rigorously defined.

>
>
>>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.

I don't see the problem. The innovation _from the customer's view_
exists in the requirements for the product. That is the responsibility
of whoever defines the product requirements, which certainly should not
be the developers. The innovation _from the developer's view_ lies in
technical elegance of the solution, which the customer never directly sees.

>
>
>> 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!

For in-house development there will still be somebody tasked with
defining the requirements for larger (enterprise) projects. Whether
there is a formal Systems Engineering group on the organization chart or
it is done by cross-fucntional teams for individual projects, somebody
is tasked with determining providing requirements as an in-house
surrogate for Marketing. For in-house work that group is likely to have
a heavier sprinkling of development people, but they will still be
specially qualified by virtue of their problem space experience (e.g.,
with as job title like System Architect) and they won't be writing a lot
of code.

>>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.

I am skeptical at the object level. Such objects would have to serve
too many masters in too many contexts. The one-size-fits-all just
hasn't worked for class level reuse.

OTOH, large scale reuse at the subject matter level has been rather
successful. Look at the core IT financial systems -- Payroll, General
Ledger, Accounts Payable, Inventory control, etc.. Today most companies
use OTS packages or outsource it to somebody else who have a generic
package. One reason is that the requirements are already pretty much
defined for big chunks of the content by FASB, IRS, and other Big Brothers.

Same for scientific applications. Who writes their own statistical
package or network algorithm package today? We also see it in
development environments. Who sits around cobbling together MFC for a
GUI or writing HTML for a web site when they have OTS builders to
automate it?

>>>>[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!

I'll still take that track record compared to those who are doing it
right and getting themselves outsourced for their trouble.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
(888)-OOA-PATH

Relevant Pages

  • Re: So lets build a router
    ... >You have a small hardware, software, and marketing group. ... Building conjoined hardware and software systems is something I ... >and that someone is very often developers along ... >responsibility for the entire system. ...
    (comp.object)
  • Re: Attitude to defects
    ... By paying attention to these lists when scheduling ... Developers don't need to distinguish though: ... Don't waste effort on separating the sheep and goats, ... Customers don't care _why_ something doesn't work, ...
    (comp.software.testing)
  • Re: Just wondering... EvilOgre.com
    ... personally would love to see developers use my Encephalon components in their products and sell on EvilOgre.com. ... source from our personal source server if you plan to continue to sell and support the product elsewhere. ... I would like to be clearly distinguished as the original author, as long as your rebranding doesn't confuse the customers, I'm fine with it. ... When someone comes to see Encephalon components, ...
    (borland.public.delphi.non-technical)
  • Re: Programmer (or A Techinical person) in a Tester ...
    ... And then you report it ... And then if the bug happens again, boom - the developers have two ... Imagine the cook who just makes food or imagines his/her customers ... worse skills, nicht wahr? ...
    (comp.software.testing)
  • Re: Delphi Vista for 2007 too?
    ... upgrade pricing to sway those who have migrated to other IDEs/developer ... I'm sure those developers will find a time when they need to upgrade, ... is, however, not a good strategy for most of your customers, IMHO, cause ... they would prefer to pay for actual quality releases and added features ...
    (borland.public.delphi.non-technical)