Path: utzoo!attcan!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.software-eng
Subject: Re: CASE - The Emperor has no clothes on!
Keywords: Software ENGINEERING, Software Development Management
Message-ID: <55235@microsoft.UUCP>
Date: 14 Jun 90 18:11:36 GMT
References: <37538@genrad.UUCP> <55137@microsoft.UUCP> <1990Jun13.070649.14929@caen.engin.umich.edu>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 112

In article <1990Jun13.070649.14929@caen.engin.umich.edu> zarnuk@caen.engin.umich.edu writes:
|
|>>(Jim Adcock) rants :-) 

I wasn't ranting, I was being heretical.  I try to contain my madness in a 
quiet sort of way...

|>>  ... The traditional approach tends to be management heavy --
|
|But that's exactly the goal of Software Engineering -- to make the
|software development process more MANAGABLE.  How can management
|make intelligent decisions about allocating resources if nobody
|can answer the most fundamental questions about what resources
|will be necessary and what benefits can be expected for/from a
|software development project?  

This paragraph makes all kinds of assumptions: 1) software engineering
makes the software development process more managable 2) being more managable
is good 3) management can make intelligent decisions if people could answer
some fundamental questions 4) software engineering helps answer those 
fundamental questions.

My last dozen years in the software industry contradicts these assumptions.
Fundamentally, what ultimately matters is the final success or failure of 
a project, not how managable or predictable it is.  Make enough money off
a project and nothing else matters.  Make no money off a project and nothing
else matters.  Most projects [in my experience] tend to fall towards one or
the other of these extremes.  Managability only matter on projects that fall
in the middle between these two extremes.

|The traditional approach is management heavy, because that is where
|the real problems are in software development.  The problems with
|software development are not technical, they are managerial (or 
|sadly enough, political).   

I agree with your problem statement, however I believe we are disagreeing
on the ordering of cause and effect here.

|However, I'd say that the scope of most CASE tools and Software
|Engineering methodologies in general place far too much emphasis
|on the actual development of software to the shameful neglect of 
|MANAGING the process.  Little or no attention is paid to deciding
|which projects to pursue, or calculating the cost/benefits of 
|pursuing/abandoning projects.  There is certainly not enough 
|attention paid to TRAINING MANAGEMENT to make decisions that 
|will promote the strategic goals of an organization.  

Agreed, except I believe companies would do well also to direct that 
strategic decision making training down to the lowest levels of a company.
To be able to do this, companies have to trust low level managers, and
lowest level employees, to work for the good of the company, and give those
people a fair margin of security.  The problem becomes that low level employees
and managers can't say: "Hey, what we're doing here makes no sense, lets do
something else."  Because they will be dinged and/or fired for it.

|There are still problems with developing software, but if management
|is willing to COMMIT themselves to pursuing the projects that will
|promote their organization -- anything can be built.  Things may 
|get rocky in the design and development arena occasionally, but they
|get solved with patience and plodding.  When management is perpetually
|pursuing the "instant buck" and flipping and flopping between which
|projects they have a "hard on" for today -- nothing gets built.  

Agreed.  But we better be willing to admit that the amount of time and
money necessary to pursue these longer term projects is very unpredictable.
Unpredictability need not be bad.  A basketball team can start out losing,
lose keys players, have their prime draft choice turn into a flake, and still
go on to win.  Its the final results that count.

|>>  ... Everything done is documented on paper.
|
|Ever been stuck trying to maintain undocumented systems?  

Yes, and its hellish.  So the trick is to spend money carefully, putting 
documentation effort into areas where it counts -- such as documenting
what is necessary for maintainability -- or better yet, writing code
for maintainability in the first place, by striving for strict encapsulation
of design.  Trying to document *everything* is destructive and dissapative --
no project can afford it, and the effort leads from project delays
to eventual project collapse.

|>>I claim OOP is quite different than this.  It is not naturally a top-down
|>>approach, but rather a topless approach ...
|
|I agree that OOP is not amenable to the standard Top-Down Structured Design
|approach.  I also believe that OOP is "the next step" to generating higher
|quality code more quickly, but saying that OOP is topless is nothing more
|than saying that you are an anarchist (no prejorative intended).  When I 
|design OOP systems, I start out by identifying objects and their various
|domains of responsibility.  The boundaries "float" somewhat once development
|gets under way, but the project starts out with a design!  Yes, development
|proceeds in a "bottom-up" manner, but there's nothing new in that -- many
|developers design "top-down" then implement "bottom-up".  Ultimately, even
|OO systems require some action-oriented control sections (notably at the
|top!).  

I disagree, in general.  Toplessness need not be anarchy.  It just requires
good citizenship, and good team players.  When people carefully craft classes
to match a particular design hierarchy, then they end up with classes that
are not reusable -- they automatically get "tuned" for their present place
in the design hierarchy.  Ultimately, then, top-down designed code becomes
throw-away code -- the design is just too immutable.  As we head towards
more and more complicated software, concepts of "top", "bottom", "edge" 
code, etc, become meaningless -- because the vast majority of software
developers are in the middle of the project somewhere.  These developers
have to do their design and coding based on the requirements and constraints
of their neighboring programmers, people who are producers of classes this
class needs, or consumers of this class.  The important thing is to strive
to encapsulate each design, so that each software developer only has a half
dozen interrelated producer/consumers to interact with.  When you don't have
design encapsulation, but rather have dozens of people whose needs/constraints
you must meet, then life becomes hell.