Re: OO Design induces an existential crisis

Nick Malik [Microsoft] wrote:
> "topmind" <topmind@xxxxxxxxxxxxxxxx> wrote in message
> news:1121550324.682122.32490@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > I don't necessarily even disagree with them.
>
> It is hard to believe that you would consider agreeing with the principles
> of OO design, when you have made such a spirited case for calling them
> pointless.

I meant in the context of the examples (sys. software and device
drivers).

>
> Some of the most innovative ideas in software development have come from
> examining a set of principles, in detail, and challenging one of them (while
> leaving the rest). I would suggest that one of the driving points for the
> creation of XP was Beck's decision to challenge the long-held notion that
> "the longer you wait to change a requirement, the more expensive it becomes
> to change." He didn't challenge the rest. Just that one. He shows that if
> you challenge that one assumption, you can completely change the
> conversation about software development.
>
> I ask you to find the single OO principle that you disagree with. "if OO
> purists would abandon _this_ one, then their code would be more
> realistic/understandable/useful/agile... whatever..."

They generally need to be considered case-by-case. I have found some
issues with "Open-Closed" principle in a nearby message, mainly
regarding it being unevenly applied.

>
> > I just cannot evaluate the
> > change pattern frequencies assumed in the articles because I have
> > insufficient experience with that domain.
>
> I don't buy that. You call yourself an experienced business applications
> developer. If you have that experience, then you've seen an application go
> from "great new idea" to "a place to add features" to "the yucky job you
> give to the new guy." If you deny the existence of code decay, then I would
> challenge your experience in a business setting. Ask others around you
> about their experience with applications that lasted more than 5 years of
> continuous "improvement".

I mean for systems software, not business software. The patterns of
change appear to be different in the two it seems. What is good
medicine for system softare may not be good for biz domain.

>
> > Good. Show it improve the change-handling of *business* examples then.
>
> EDRA
> http://www.gotdotnet.com/workspaces/workspace.aspx?id=9c29a963-594e-4e7a-9c45-576198df8058

It looks like a discussion group. Anything specific you want me to see?

>
> This is a framework, developed on top of Microsoft .Net technologies (but
> could just as easily be developed on Java) for web service integration
> points that creates a place to put logic, and different place to put
> "cross-cutting concerns" like logging, authentication, and routing. This
> allows these concepts to be changed independently of one another in a way
> that is pretty good for meeting the principles of both OO design and SOA
> architecture.

Does it compare the design to non-OO versions?

Here is some info about non-OO authentication techniques:

http://www.geocities.com/tablizer/struc.htm#accessexamp

http://www.c2.com/cgi/wiki?AccessControlList

>
> > There must be a good reason why OO training examples roughly have a
> > ratio of 25-to-1 in favor of sys software examples over biz examples
>
> Sure... most of the people who add these features to a language work in the
> field of writing languages... e.g. system software, so they explain it from
> their viewpoint. Once the business developers learned OO, they looked
> around and said "the way I learned it is from these sources, so they are
> good enough for someone else to learn it..." so they didn't create new
> sources of info. It's a bit of a vicous cycle.

Well, if the lessons are applicable, I just don't see where they
are common. In custom biz apps you don't build 20 different
implementations of the identical interface. That would be a
waste of money for something that is "custom". And things
that have variations on a theme generally don't fit
into nice hierarhcial taxonomies. The granularity
and effector of such variations are more chaotic than OOP
seems to assume.

>
> The book I quoted attempts to break this cycle. It was written by a
> business user who learned OO and then became an architect and now runs a
> company that trains people on how to use OO. The man's name is Alan
> Shalloway. His company is Net Objectives. The book is "Design Patterns
> Explained" but he doesn't just explain design patterns. He explains the
> transition he made from procedural to bad-OO to good-OO.

Does he give comparative examples?

>
> > The ambiguity is in the change patterns they assume and test. You
> > cannot hide from probability. I can even give change scenarios that is
> > more code rework in the device driver examples.
>
> Change is hard and often unpredictable. Other times, it is completely
> predictable. The reason that folks like to use the "device driver" as an
> example is that everyone understands the notion of a bit of software that
> helps the operating system deal with change (in devices). It is a shared
> concept that an author can build on. It has nothing to do with system
> software as the only domain for OO problems.

I disagree. It appears not to extrapolate into other domains as
described above. If it does, I just don't see it. Even some
OO fans have agreed that device-driver patterns are not appropriate
to biz apps. But their suggested OO alternatives are fairly messy.

>
> When I write an article (which I do often), I don't have time or space to
> define every term. I need to rely on concepts that already exist in the
> reader's mind.

Because software tends to be a virtual world, sometimes that
is a problematic assumption. I have been in long debates over
the meaning of "separate". The concept of separation is
fairly clear in the real world, but means little in a database
where closeness is virtual, dynamically controllable, and
perhaps meaningless.


> I do not know my reader, but I know some things about them.
> If they are reading one of my articles, they are probably a developer
> familiar with the Windows environment. Therefore, they already know what a
> device driver is. So I can use that. I don't have to. I could use
> something else, but I'd have to take time and space to explain it. That is
> one more reason that device drivers are cited so frequently. It has nothing
> to do with that being the only domain for OO.

But analogies that don't extrapolate well are perhaps poor
analogies. It is similar to my complaints about trees:
they are easy for most educated humans to relate to,
but just don't scale well in most cases.

>
> Seperately, I would posit that probability has very little to do with the
> concepts of OO or how best to apply them.
>
> You don't create the "interface" only at the points where change will occur,
> because, as you know, change often occurs somewhere else. You put interface
> points between *concepts* because concepts change at different rates.

Concepts often interweave in non-trivial applications. If biz apps
had clear-cut "sections" with thin interfaces, then we could
use a lego-block-like approach to building them. But it does
not work that way in most cases despite years of trying by
wealthy companies. What are "separate concerns" tends to be
*relative* to needs. OO tends to seek One Right
Taxonomy/Classification of concepts, which is the wrong
approach. Biz apps need a "relativity engine".

>
> When a new "boss" comes into the project and changes things around, the
> things they change will nearly always line up with one or two concepts.

No. They may view the world very differently than the old boss.
Their mental model may be composed of concepts that don't
translate one-to-one with the old ones. Thus, it is not
merely a matter of changing implementation but keeping
interfaces the same.

> Therefore, you can change the code for those concepts seperately from the
> code for the rest of the system.

The biggest part of managing biz apps is managing the interweaving
connections inherent in them. One cannot hide them away, they
must manage them.

>
> For example: In my car, it is fairly easy to get to the battery. It is less
> easy to get to the alternator. It is downright difficult to get to the air
> conditioner compressor. Why? It is because this is the order of the
> frequency that a repair person needs to get to these parts. However, each
> of these parts can be removed and replaced without messing with too many
> other parts. You don't have to dismantle the engine to replace the
> alternator. There is no probability in that notion.

Well, I am not sure a car engine is entirely a good model for
biz apps either.

>
> Sure, we could guess that it is more likely that we would need to replace
> the alternator over the engine... we could even cite statistics to support
> the notion. But it is less important than it appears. The fact is that the
> repair of the alternator would usually happen at a different RATE than the
> repair of the engine. Therefore, there needs to be a way to get at one
> without causing complications with the other.

Sounds great on paper, now lets see it applied to biz apps.

>
> Now, in many cars (mine included), you may have to move the alternator out
> of the way if you are servicing the engine. You don't have to move the
> engine out of the way to service the alternator. This is where you could
> use probability to improve the efficiency of your operations. However, the
> interface exists, regardless of the statistics, because the RATE is
> different.
>
> While you cannot tell what will change first, being familiar with the
> business domain will quickly give you a respect for the things that change
> at different rates.
>
> > The ambiguity is in the change patterns they assume and test. You
> > cannot hide from probability. I can even give change scenarios that is
> > more code rework in the device driver examples.
> >
> > Nobody has questioned that in such debates that I remember. In other
> > words, nobody has ever disagreed with the suggestion that a given
> > design cannot weather ALL changes better than the competition.
>
> What does "more rework" mean? Is cost a factor of the lines of code? Being
> a function point counter and a cost wonk, I would emphatically disagree.
> Cost is a factor of complexity of the requirements. If you shear a design
> to go from less compex to more complex, there will be changes in many lines
> of code. This happens regardless of whether you are in the OO or Procedural
> space. No design can (readably) create an interface for all change,
> especially change that crosses this complexity boundary.

Example?

>
> I would state that, on average, OO code tends to require fewer lines of code
> to add a feature than procedural. That is anecdotal at best, and you have
> every right to doubt that statement. I cannot put science behind that
> statement.

At least provide some representative examples. Mass studies would be
nice,
but observable code scenarios may be the next best.

>
> However, I would also suggest that the sheer number of lines of code changed
> is a poor measurement of the cost of a feature.

I have proposed a combination of total lines, total blocks, and total
"named units" (routines, methods). These can perhaps be averaged
together.

> It is entirely possible to
> change three lines of code in a procedural application, and then require a
> full regression test of the system and all integration points,

I would be curious to see an example. We might learn something from
such an extreme example, perhaps forming another principle or
rule of thumb.

> while I have
> seen situations where a developer changed the fundamental structure of part
> of an OO application and it required only the simplest
> build-verification-test to validate that the code was sound. This is just
> one (extreme) example that shows that any measurement for capturing the
> notion of cost must include more variables than the KLOC count.

Again, I would like to see an example. Perhaps such extremes average
out such that the line/block/named approach is good enough.

>
> >
> > If you agree with this, then you must agree with me that probability
> > plays a role. That is, we pick the design that reduces the change
> > impact of the (estimated) most *common* changes.
>
> Nope. I do not agree. Any time I ask for justification for code
> interfaces, and the comment comes back as "I am reducing the impact of
> change", I do my level best not to break out in laughter. As I said before,
> a good design captures the connections between the "concepts", not the
> points where a developer (in his "infinite" wisdom) expects change.


Why focus on "concepts"? Is the goal to reduce maintenence
labor or some kind of psychological satisfaction? I am
fuzzy on what you are getting at.


> To say
> that we know where to expect change is nuts.


Estimate, not expect. Measuring change impact is one of the
few metrics that most seem to agree on WRT design comparisons.
It is fairly objective. If you have others, the please clarify
it/them.

I see no reason to abondon it or greatly modify it yet.
I have not seen cases where most would agree its producing
poor results. I would like to see some of the worse-case
failings of it that you anecdotally mention above.


> We aren't the business users,
> so we don't have the appropriate context. Besides, the average developer
> isn't smart enough to predict that change. We just need to predict
> different rates of change. That part is a good bit easier to do.

Even if we assume random patterns of change, non-OO techniques appear
to do no worse.

>
> > It seems that OO'ers tend to be bad proceduralists/DB'ers. Thus,
> > perhaps they are abandoning p/r because they suck at it, not because of
> > any inharent fault in it.
>
> I could levy the same comment at those who write procedural code. Let's see
> if we can avoid these little tidbits, OK? They only serve to lower the tone
> of the discussion.

I really meant to hilight why anecdotes are nearly useless in
"I've seen procedural go bad a lot" kinds of statements. One
cannot know for sure whether it is the paradigm as born, or
just bad coders/designers in action until they see the code.

>
> >> > Are there any OO gurus out there who want to take on custom business
> >> > applications? Any?
>
> You asked if there were any gurus out there working in the business apps
> space.

No, I meant writing about them.

> I replied yes (although I wouldn't apply the term "guru" to myself.
> That is a religious term). You didn't appear to want to take that anywhere.
> I'm not sure why you asked the question. Are you interested in seeing how a
> business app can be solved with OO code? There are literally thousands of
> examples in articles for dozens of magazines.

I want to see how OO makes better code than the alternatives (usually
procedural with RDBMS) for custom biz apps. It generally would
require a comparison. Actually, I can supply the procedural side
if you first find a biz example that OO gurus seem to concensusly
beleive is a good example.

>
> It appears that you are interested in a comparison of the costs of using OO
> to solve a problem and the costs of using procedural code to solve the same
> problem. This wouldn't come from a guru. It would come from a researcher.

Are you saying the guru can't describe why with examples? Like I said
above, a sample size of a thousand would be nice, but we may have to
settle for a few apps first.

>
> I would posit that a comparison can be done, but it would have to take years
> to study, because you would want to solve the same problem of sufficient
> complexity, with both mechanisms, and then add changes, over time to both
> code bases, using a mix of experienced and new developers, in a controlled
> turn-over environment.

That would be nice, but as a consolation each side could produce
several change scenarios. We may disagree over the probabilities of
each scenario, but at least we could identify where our
differences lay. In other words, at least find the pivotable
variables so we can document the givens each side uses to
make their conclusion.

It would be like two different Mars probe designs before the
first landing; one assuming a thick Martian atmosphere
and one assuming a thin one. One could then say, "assuming
a thin atmosphere, my lander design appears the best".

>
> To be fair, the experiment would have to be structured this way because the
> benefit of one over the other may not be realized during initial
> implementation. Benefits may only show up during long term maintenance of
> the code. This could go either way.
>
> That is why few studies exist. They are expensive and time-consuming.

But I described a reasonable alternative.

> Without a requirement in legislation, or an edict from the board of
> directors, no one has the reason to spend the money for this kind of study.
>
> However, the anecdotal evidence is so powerful that most folks who write
> code today do so in an object-oriented language.


I disagree. Even in OOP languages such as Java, much of the production
code tends to be procedural in nature. Even many OO proponents complain
about the lack of OO use in practice.

OO gets more lip service than code.


> Millions of developers are
> improving their skills on OO development every day, because they've seen the
> benefit of doing so. Sure... some of that it top-down. Your boss tells you
> to write in Java or C#. However, your boss can dictate the language, but
> not the technique. The improvement in technique is because smart people are
> discussing principles and ideas, and that leads to innovation. This is
> happening, but it takes time.
>
> In this climate, there is very little motivation to perform this kind of
> study.
>
> >> You have convinced me of one thing: you have never seen OO done
> >> correctly.
> >> Therefore you are convinced that it cannot be done.
> >
> > No! I am only saying that public evidence does not exist.
>
> Are you saying that you *have* seen a business OO application that was well
> constructed and met its objectives of keeping costs low? In that case, your
> viewpoint is even more perplexing.

Huh? How did you get that out of that text? I never said "cannot".
I am only saying the evidence for it is weak so far. OO appears
overhyped.

>
> > Yet companies
> > are spending zillions on OO. So quick to spend without any real science
> > or comparative analysis?
>
> Are companies really spending zillions on OO? Companies are spending
> zillions on customer software development. That is the problem. They
> should write far less code than they do. For most companies, they don't
> give a hoot if the technology under the covers is OO or PP or QQ. They care
> about results.
>
> This is why the study may have limited value.

Well, if long-term results is not valued by businesses, then
why are you suggesting using OO which allegedly is best
at the long term? You might be selling refrigerators
to eskimos.

Investment theory (Time Value of Money) generally expects a
payback of roughly around 18 months, not 10 years.
Perhaps long-term maintenence is the wrong goal
(regardless of the best paradigm for it).


> It is a technical choice, not
> a business one. To be honest, even if a study did come out, I'd be
> surprised if it showed there to be a huge cost difference. Probably only
> about 10% of the cost of coding would be gained or lost either way.


Then why force OO down people's throats? Obviously many are not
comfortable with it as the author of this topic demonstrates.
They might be retirement age by the
time they "get it" (if there is such a point). That is not
economical.

Torture developers over 50%, not 10%.


> Considering the fact that coding makes up only about a third of the cost of
> custom software, we are haggling over 3% to 4% of the budget. Worth
> haggling over, but not so much that business even cares. They can eat 20%
> of their costs in poor requirements gathering, 25% in poor project
> management, and 20% in poor testing. 3% is not even on the radar.
>
>
> > The format should look something like:
> >
> > Here is the OO code:
> >
> > blah blah blah...
> >
> > Here is the procedural/relational equiv. code:
> >
> > blah blah blah...
> >
> > Here are 5 change scenarios:
> >
> > 1. asdfasf...
> > 2. adfasdfasdfsd...
> > 3. asdssdf.....
> > 4....
> > 5....
> > (with possible frequency estimates)
> >
> > Here are the scores for each scenario:
> >
> > Number of lines changed: ...
> > Number of blocks changed: ...
> > Number of named-units changed: ...
> >
> > Got Science?
>
> Got time? I don't. I have a job to do.
>
> Why not write up your experiment ideas and send them to college computer
> science departments around the world. Someone will bite, I assure you.
> Every year, graduate students are desperately seeking an interesting topic
> for their thesis. I'm sure that some of them would love to take this on.

I shall consider it. There are some "toy" examples at my website
I would like to see OO objectively improve, BTW.

>
> --
> --- Nick Malik [Microsoft]

-T-
oop.ismad.com

.

Relevant Pages

  • Re: Another argument for disk brakes?
    ... >> people Jim Beam is pursuing with a vendetta. ... believe there is a design problem. ... You may disagree with certain aspects of the analysis, ... primary means of holding an axle in place. ...
    (rec.bicycles.tech)
  • Re: Build your own Forth for Microchip PIC: the nature of metacompilation
    ... pure Jeff Fox. ... One of the beauties of the RfD process for me is the challenges it throws up. ... And that's an area where I disagree with Jeff: he wants a Forth for elite programmers. ... Forget Forth 94 and tell me how you'd design a Forth that could attract users with real problems to solve, ...
    (comp.lang.forth)
  • Re: Whats this inductor doin?
    ... dollars each for software with a reputation of unreliability? ... years doing electronics design as a consultant. ... colleages at Tektronix and other companies used SPICE very often. ... When the experts disagree, ...
    (sci.electronics.basics)
  • Re: Please participate in a non-profit academic research
    ... get someone with the requisite skill to design the questions. ... "Using hybrid cars could save 50% fossil fuel on general driving, ... slightly disagree ... the "disregard" questions certain surveys need to contain, ...
    (alt.usage.english)
  • Re: I really hate .NET especially inside Delphi
    ... But I would rather have my customers, ... We can just agree to disagree then. ... I dont consider project/make symantecs design. ... there are principles that guide design in many different areas. ...
    (borland.public.delphi.non-technical)