Message-ID: <32D32AA7.6B5B@dave-world.net>
Date: Tue, 07 Jan 1997 23:03:35 -0600
From: Tim Ottinger <tottinge@dave-world.net>
Reply-To: tottinge@dave-world.net
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.object,comp.lang.java,comp.software-eng
Subject: Re: What is the cost of Bad Classification
References: <32CABBDB.41C67EA6@dcs.shef.ac.uk> <rmartin-0201971207480001@pool11-018.wwa.com> <5aqtf0$6ns@nntp.interaccess.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: m3cmi.dave-world.net
Lines: 63
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!news.tc.cornell.edu!news3.cac.psu.edu!howland.erols.net!newsfeed.internetmci.com!nt.dave-world.net!m3cmi.dave-world.net
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:238990 comp.lang.smalltalk:48740 comp.object:59518 comp.software-eng:52258

Thaddeus L. Olczyk wrote:
> 
> rmartin@oma.com (Robert C. Martin) wrote:
> 
> >> What is the cost of bad classification..?
> 
> >The loss of all the benefits of OO.  i.e. maintainability, flexibility,
> >reusability.
> 
> The cost is actually grater. Not only do you not get the benifits of
> OO, but you also lose the extra effort you expended use
> an OO approach in the first place.

Or it can just be the cost of refactoring and reworking your code.
As bad as it is to classify poorly or naively, it's much worse to
continue to use it when you know it's bad.  

A focus of mine lately is to look for 'enabler' and 'disabler' 
features in software. We find that there are some well-thought-out
frameworks and classes which enable maintenance and expansion, and
there are little functional bits which enable a lot of business to
be done.  Likewise, there are features of programs which make it
hard to do work (clunky UI features, poorly designed innards, hacks,
hard-coded procedures).  *Every* release should add some new enablers
and remove some disablers.

"Disablers" in a system may be necessary, but they're never something
you strive to include.

I think you can survive having some sub-optimal bits in your software
system, temporarily.  You can probably even survive having a few pieces
"slam dunked" to make a date. But you can't stand to leave those bits
in place to erode your tactical and strategic software situation for
all future times.

In summary, the cost of having a bad classification which worked anyway:
   1) The cost of reworking it (refactor/redesign/retest/re-release)
   2) The opportunity cost of not building features on the bad bits
   3) The opportunity cost of not building other cool things because
      you're busy reworking the bad bits.
   4) The emotional impact of having "crud" in your code.
   5) The temptation to leave it that way even though it sucks, because
      it actually runs and was tested.
   6) The liklihood that you might be convinced to add new code onto
      the bad bits.

The 5th item, if one succumbs, means that you get to skip the first 
and second costs, but you'll continue paying for the others for the 
life of the product.

The nice thing about most engineer-types I know is that they are usually
thrilled at the opportunity to redo something which really needs to be
redone. 

Finally, you might actaully have added so many disablers that you can
no longer keep your software product at all and must start over. This
is usually the result of following #5 far too long.
-- 
Tim
-------------------------------------------------------------
Tim Ottinger      | Object Mentor Inc. | OOA/D, C++, more.. 
tottinge@oma.com  | http://www.oma.com | Training/Consulting
-------------------------------------------------------------
