Re: how many programmers to change a lightbulb ?

Re: how many programmers to change a lightbulb ?

[Tom_Hargraves]

How to partition a project?

This is an 'age-old' problem in software engineering.

The dilemma used to be called bottom-up versus top-down design.
Whatever you call it, the problems are still the same.

A few advantages of the top-down approach are:

   1. Nice 'clean' looking interfaces between nicely partitioned functions.
   2. Management tasks which look like they can be controlled and split into
   separate groups.
   3. A hierarchical software structure which maps to hierarchical management
   structures.
   4. The user interface progresses quickly, and looks great.

In short, it looks great on paper, especially to managers.
BUT in practice you will find perhaps 10 to 20 groups who spend half their time
solving the same problems. At the lower levels you will have 10 to 20 versions
of the same software. If you've allowed unconstrained use of tasking you are
doomed in the integration phase. Think of it as building a 10 floor building
where each floor-designer is independently responsible for his/her percentage of
the building foundations. Integration is hell.

A few advantages of the bottom-up approach are:

   1. Common software is produced for all to use. There is only one hash-search
   package to debug. There is only one linked list hander. There is only one
   scheduler etc.
   2. There is one common interface to the plethora of user interfaces which
   must be supported over the lifetime of the project.
   3. Common functions are identified quickly and provided for all to use.
   4. Interfaces to COTS software are minimised and tightly controlled.

In short, it looks great from an efficiency and maintenance point of view.
BUT it's difficult to identify all the 'bottom' functions at day 1. Management
don't like it because it's 'fuzzy', there is no hierarchy to manage. On a large
project it could be months or years before the bottom-up approach shows tangible
evidence that the project is bearing fruit. The user interface groups are
delayed and delayed and end up calling X-windows/Win95 routines directly rather
than wait for the platform independent routines the common software group keep
failing to deliver in time...

In practice you need a mixture.
If it's a one-off project, small to medium size, with a short lifespan, then
bias towards top-down.
If it's a large project, which has an in-service life of 5 or more years and
will be the mainstay of the company, bias towards bottom up.

The key thing to remember is that it is the engineers who will turn this project
into reality. In my experience 99.999% want to do a good job, and will naturally
work hard in a supportive environment. Break it to them gently that they cannot
use all the Ada features they'd like to 'try'. Organise parties. Keep them happy
:-)

Regards,
Tom H.










Marin Condic <condicma@bogon.pwfl.com> on 11/18/99 08:32:03 AM

Please respond to comp.lang.ada@ada.eu.org
                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:      comp.lang.ada@ada.eu.org                            
                                                              
 cc:      (bcc: Tom Hargraves/RMD/Raytheon/CA)                
                                                              
                                                              
                                                              
 Subject: Re: how many programmers to change a lightbulb ?    
                                                              








G wrote:

> Things like - when someone designs a major software project (I have been
> looking
> at the documents on domain analysis and other things at SEI) - it
> appears as though the project is broken into teams - and each team need
> only know about as much about the other team's work as they do to know
> where what they are designing interacts with the other modules and
> components of the system, that is - what contracts are being resolved.
> As long as they return what is required to the system in the most
> efficacious manner, everyone is happy.
>
> Is that right (however simple it may be) ?  Won't there be problems with
> geographically remote teams of programmers doing things separately such
> that certain discontinuities might emerge with (the
> compatibility/interoperability issues of) the various modules they
> design ?

In my experience with large software development efforts in Ada, you
definitely get advantages in designing the interfaces between functional
groups early on. To a large extent, it does allow developers of different
subsystems to proceed independently. However, there is never a panacea which
is going to make everything run flawlessly. It all goes back to the Tower of
Babel. Or maybe Adam biting the apple.

Inevitably, as a project progresses, different groups are going to discover
things which make redesigning the interfaces necessary. Maybe just little
tweaks - sometimes major overhauls. Independent development gets disturbed
at that point. There will also come points in time when everybody has to
synchronize up because you have to pull the various pieces together and
subsystem A won't function correctly unless subsystem B is up and working as
well. So team A is dependent on team B finishing their work.

Eventually, you have to integrate everything and clearly defined interfaces
help to make this less painful. But there is always functionality behind the
interfaces and that requires coordination - thus making teams less
independent. Just because the plug and the socket match, doesn't mean that
you get the voltage you expected! :-)

MDC
--
Marin David Condic
If you hurry you can, for a short time only, still find me at:
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/



_______________________________________________
comp.lang.ada mailing list
comp.lang.ada@ada.eu.org
http://ada.eu.org/cgi-bin/mailman/listinfo/comp.lang.ada

how many programmers to change a lightbulb ?

[G]

Not really... but I thought that would get someone's attention.
I wrote some code and asked for advice, I guess the code was ridiculous
coz I got none.

I have lots of questions to ask.  These are on-topic.

Things like - when someone designs a major software project (I have been
looking
at the documents on domain analysis and other things at SEI) - it
appears as though the project is broken into teams - and each team need
only know about as much about the other team's work as they do to know
where what they are designing interacts with the other modules and
components of the system, that is - what contracts are being resolved.
As long as they return what is required to the system in the most
efficacious manner, everyone is happy.

Is that right (however simple it may be) ?  Won't there be problems with
geographically remote teams of programmers doing things separately such
that certain discontinuities might emerge with (the
compatibility/interoperability issues of) the various modules they
design ?


Also - I read something about a language called durra.  It is very
erudite and complex.
This is a design language ?  Not something which is itself compiled ?
But then why is there a durra compiler and then does this compile durra
systems into ada systems.
I couldn't work out if durra was an extension of Ada - it certainly
looked that way.

Anyways, doesn't matter... I am broadening my general knowledge on these
matters.

Thanks to anyone who knows anything about this stuff and responds.
:-)

-Graeme
Australia

*insert appropriately witty/relevant socially satirical quote here*

Re: how many programmers to change a lightbulb ?

[Ted Dennison]

3

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: how many programmers to change a lightbulb ?

[Marin Condic]

G wrote:

> Things like - when someone designs a major software project (I have been
> looking
> at the documents on domain analysis and other things at SEI) - it
> appears as though the project is broken into teams - and each team need
> only know about as much about the other team's work as they do to know
> where what they are designing interacts with the other modules and
> components of the system, that is - what contracts are being resolved.
> As long as they return what is required to the system in the most
> efficacious manner, everyone is happy.
>
> Is that right (however simple it may be) ?  Won't there be problems with
> geographically remote teams of programmers doing things separately such
> that certain discontinuities might emerge with (the
> compatibility/interoperability issues of) the various modules they
> design ?

In my experience with large software development efforts in Ada, you
definitely get advantages in designing the interfaces between functional
groups early on. To a large extent, it does allow developers of different
subsystems to proceed independently. However, there is never a panacea which
is going to make everything run flawlessly. It all goes back to the Tower of
Babel. Or maybe Adam biting the apple.

Inevitably, as a project progresses, different groups are going to discover
things which make redesigning the interfaces necessary. Maybe just little
tweaks - sometimes major overhauls. Independent development gets disturbed
at that point. There will also come points in time when everybody has to
synchronize up because you have to pull the various pieces together and
subsystem A won't function correctly unless subsystem B is up and working as
well. So team A is dependent on team B finishing their work.

Eventually, you have to integrate everything and clearly defined interfaces
help to make this less painful. But there is always functionality behind the
interfaces and that requires coordination - thus making teams less
independent. Just because the plug and the socket match, doesn't mean that
you get the voltage you expected! :-)

MDC
--
Marin David Condic
If you hurry you can, for a short time only, still find me at:
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: how many programmers to change a lightbulb ?

[Nick Roberts]

Ted Dennison wrote:
> 
> 3

Er ... okay ...

(1) the systems analyst, who writes a 27-page indexed report on the
problem, 

(2) the programmer, who works out what really has to be done (and does
it), and then

(3) the external consultant, who writes another 27-page report - glossy
bound - for senior management to approve the budget* for next year?

-- 
Nick Roberts
Computer Consultant (UK)
http://www.adapower.com/lab/adaos


*$1.20 for the bulb, $65 for the programmer, $950 for the analyst, and
finally $6000 for the consultant.

:-)