Re: Why is OO popular?

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

Date: Fri, 21 May 2004 20:40:28 GMT

Responding to Stern...

>>Are you talking about requirements analysis or OOA?
>
>
> An interesting question, but I will pass on it.
>
> The point is that requirements are not a specification.

I thought that was the second 'S' in SRS. B-)

Actually requirements are specifications:

Requirements -> OOA -> OOD -> OOP -> Object code -> Executable.

Everything to the left of Executable is a specification of the solution
on the immediate right. Similarly, everything to the right of
Requirements is an added-value solution to the specification on its
immediate left.

>
> Requirements are, "We need a new payroll system". Maybe that's the
> whole thing. Who does the next stage, "Well, we'll make a web-based
> thingy to give you flexible access and use our shop-standard tools,"
> and then research and design on what specific issues there are and
> page designs. There is just no place to draw a line between the
> tasks, no good place to have a wall. XP gets this sort of right.

I think there are pretty clear demarcations between the stages. The
difference between Requirments and OOA is that requirements define What
to do while an OOA model defines How to do it. Generally anyone with
experience developing requirements can identify solution pollution on
the Requirements side.

The difference between OOA and OOD is the sorts of requirements
addresses: functional for OOA and nonfunctional for OOD. Again
functional vs. nonfunctional requirements is usually a pretty clear
distinction.

The difference between OOD and OOP is the toughest one to draw because
it is really a matter of scale (i.e., strategic vs. tactical).
Dependency management is a good example of the blurring. The rules are
really distillations of OOD practices into cookbook guidelines for coding.

 From OOP to the right one has technical definitions that have become
reasonably standardized.

As far as your example is concerned, today being web-based is a
requirements decision that is based upon informed market decisions.
Page designs are the province of a UI designer, whose design becomes
requirements for the developers. An efficient, flexible implementation
using appropriate technologies is the developers' problem.

[I hope you're not going to argue that software developers should be
designing web sites. It only takes a few minutes of random surfing to
demonstrate why that is not a good idea. Busy pages w/ too many colors
and sections = developer site. Simple pages w/ intuitive color ques and
links = professional UI designer. I believe there is some genetic thing
that makes software developers use all 2b colors on every page just
because they are available.]

>
>
>>The developers have to interpret the SRS properly. That's true if it is
>>a 2000 page Word document or a verbal conversation the customer over
>>lunch. What this comes down to understanding the domain, even if it is
>>only to the extent of knowing what questions to ask.
>
>
> Disagree. If you have a 2000 page document, it is almost certainly
> detailed enough that you need no domain knowledge, just the ability to
> look for inconsistencies in the document, in its own terms. But such
> documents are seldom produced and even more seldom work, for all the
> familiar reasons. If you don't have all that detail, then sure, you
> want to have discussions - across the wall. Even in my best possible
> circumstances you do *some* of that, and hence you *do* want to have
> domain knowledge on both sides of the wall. The problem is the wall
> is still there. You'd like to have staff that can cross over, have
> those conversations one communications-link shorter. This is where we
> disagree, in principle more than in practice, perhaps, but even so.

I've dealt with SRSes in the 1K page range. Trust me, you probably need
more domain knowledge there than for hallway specs. The big problem is
sorting out the forest from the trees. The long-term software structure
needs to be built around the forest. But getting that from a huge SRS
is almost impossible. From hallway specs you can get the Big Picture in
a couple of whiteboard sessions by asking the right questions. But the
guys who wrote the 1K page SRS are probably long gone.

[In DoD where large SRSes are normal, the RFP process is such that one
is often prohibitied by statute from talking to the people who actually
wrote the spec. That's because the COTS vendor has to start building
stuff before the final contract is awarded and the law requires that
each competitor to have exactly the same information during the bidding
process. So no bidder gets to ask for clarifications individually.]

>
>
>>>You are not parsing my message very well. I advocate a balanced
>>>technology/marketing (out/in) view. I'm skeptical about separate
>>>responsibilities for analysis and design, but with teamwork, it can be
>>>done.
>>
>>When I speak of A&D I am talking about OOA/D, not requirements analysis.
>> Those are not separated among different people for traditional
>>elaboration. OTOH, determining product requirements requires entirely
>>different skills sets and processes than software development.
>
>
> Perhaps, but there is no law against one person having two skill sets.

True. But if you are a hiring manager during a boom, do you want to be
looking for one skill or a combination of skills? Which will be
cheaper: two people with a single skill each or two people with two
skills each? Software construction isn't the center of the business
universe, despite what advocates of some processes would like to
believe, and a lot of factors play in optimizing the process.

>
>
>>You seem
>>to be arguing that developers should be involved in requirements
>>analysis. To me that's like saying that OOPL compiler designers should
>>be involved in OOA/D.
>
>
> There may be development slots for techno-nerds who never leave the
> cubicle, but generally not in applications development, sez me. A few
> compiler guys, OS guys, database engine guys, comm stack guys, sure,
> but that's probably less than 1% of the developer population over all.

That's not the point. To do their job, a compiler designer does not
have to understand the OOA/D of particular applications to be developed
using that compiler. That's because the processes and skill sets are
vastly different between compiler design and application development.
The differences in processes and skills required for requirements
development are vastly different from those for /any/ software development.

>>And that is exactly why it requires a different skill set and different
>>processes than software development. My job on those week-long junkets
>>was Shut Up And Listen. That is, I was there solely to clarify
>>technical customer issues for the Marketeers. So for a typical week of
>>20-30 face-to-face hours my total contributions were usually on the
>>order of ten minutes. I provided that same perspective during
>>subsequent requirements analysis, but in the end it was a pure Marketing
>>show and I had no direct contribution the determination of the final
>>requirements.
>
>
> Can't speak to your situation. Perhaps your marketeers have enough
> skills to speak 80% of the time for the development side.

They don't don't speak for the development side at all. Their job was
to extract and prioritize requirements from customers. Once that was
done there was a cost negotiation with the development side to determine
the best mix of requirements that could actually be delivered for
Marketing's target date. Once the product was agreed, the developers
took over implementating it and Sales took over selling it.

>
>
>>>I'm taking issue with the word "rigor", if you want it to be any more
>>>than marketing noise. The C compiler is rigorous, and so what, it
>>>does not extend to what you do with it. Ditto any other alphabet soup
>>>you want to throw on the table. The suggested "rigor" is just not
>>>there.
>>
>>I've been using such methodologies for a whole lot of years. Hundreds
>>of applications across dozens of shops have been developed, many in the
>>MLOC range. It works because the methodologies do have sufficient rigor.
>>
>>As it happens the biggest single bar to using translation today lies in
>>the skill set. The developers will fail if they develop OOA models with
>>the same lack of rigor that one commonly sees today in OO applications.
>> To be successful the shop must undergo what amounts to a
>>methodological sea change in the way it develops software.
>
>
> That's two very different uses of the term "rigor" in two paragraphs,
> and it's probably inappropriate in both.

I meant rigor to mean precise, complete, and unambiguous specification
in both paragraphs. How was that usage innappropiate to the context?

>
>
>>FORTRAN and COBOL were developed in the late '50s and they really didn't
>>get out of the lab until 1960. But by '68 BAL was almost never used for
>>new development outside R-T/E.
>
>
> Still used for O/S through the 1970s at least.

An OS is R-T/E, especially in that era; it directly controls the
hardware. It was only in the '80s when OSes began to bloat up with web
browsers, window managers, and calculators that they mostly left R-T/E.

>
>
>>Codd originally published in '68 but his
>>main work was published in '70. By '75 most Fortunate 500s had RDBs in
>>place.
>
>
> Tiny ones. RDB's weren't practical for single-thread systems until
> the mid-80s, multi-thread pretty much mid-90s. Before those dates the
> software was primitive and the hardware insufficient.

I have to disagree. I worked at two Fortune 500s in the mid-'70s and
all their core accounting systems -- general ledger, payroll, accounts
payable, accounts receiveable -- were RDBs. By 1980 the half acre of
tape drives were long gone along with all the CODASYL and ISAM stuff.

I agree that in the '70s all the processing was done with batched
transaction processing as if everything was still being done with
punched cards. But by the early '80s full online multi-user access was
common. Among other things airline reservations systems were fully
computerized for POS by 1980. By the mid-'80s full client/server models
were in place.

BTW, I'm talking about mainframe implementations, not PCs.

>
>
>>It really doesn't matter much what the state of MDA semantics is. The
>>technology has been available since well before even OMG. All MDA is
>>doing is providing standardization for existing technology. As long as
>>that act is together within a couple of more years, there is no problem.
>
>
> So it's already been fifteen years, but it's JUST ABOUT TO TAKE OFF.
> Doubt it.

It took nearly a decade for C compilers to provide optimization
comparable to FORTRAN's when C started out. As I already pointed out,
it took a decade plus to get a handle on optimization so that
translation could provide adequate performance for general computing.

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

  • Job openings in Maryland
    ... automating UI test cases, defining test plans and test specifications, ... Following project milestones, you'll design, ... Preferred skills: ... supporting critical customer applications to creating new components in our ...
    (php.general)
  • Jobs in Frederick, MD
    ... automating UI test cases, defining test plans and test specifications, ... Following project milestones, you'll design, ... Preferred skills: ... supporting critical customer applications to creating new components in our ...
    (php.general)
  • Opening for Sr Java Developer at White Plains, NY
    ... Kindly check if you are comfortable with the skills mentioned below. ... Duration: 1+ year ... business requirements that drive the analysis and design of quality ... direction and supervision of senior applications staff and management. ...
    (comp.lang.java.programmer)
  • Lead ,Team SCM ( Perforce,PVCS, Clear Case,PVCS, CVS ) urgently needed for MNC at Bangalore
    ... client located at Bangalore. ... Skills Required: ... Excellent design and programming skills ... Exposure to various optimization techniques for CODECS is desirable. ...
    (uk.jobs.offered)
  • Re: transition from programmer to developer
    ... Applied Object Oriented Analysis and Design Using UML", ... Effective Java Programming Language Guide / Joshua Bloch ...
    (comp.lang.java.programmer)