Re: Development: A Structured Problem Area?

Edmund Schweppe wrote (in response to Andy Hunt):

>> Programs with highly-coupled,
>> interacting pieces may begin to show emergence by accident (and not
>> on the happy end).
>
> Yep. Things like disks, files, networks, the Windows Registry, ... :-(

This is a very important point.  Typical software projects (i.e., where 
implementation is quite far along while the requirements are still in 
flux) are often described using analogies from building construction:  
"It's like starting to build a building when you don't even know how 
many stories it's supposed to be!"

My response recently has been, "No, it's much worse than that."

Actually, it's like starting to build a building when you don't know 
how many stories it's supposed to be, or the size of the site, or its 
slope and other physical features, or the quality of the soil, or the 
depth of the bedrock ...

We build software in the space between two things that are not 
perfectly knowable -- the requirements that we must build up to, and 
the platform that we rest upon.  Almost every project I've ever worked 
on has had to deal with changes, during construction, from two 
different sources:

* Changing (or gradually emerging, or entirely new) requirements
* Changing (or gradually emerging, or entirely new) understanding of 
some aspects of the platform, development environment, operating 
system, operational environment, etc., upon which the system is built.

Usually the first set of issues is more disruptive than the second, but 
not always.

How many times have you heard things like this from developers?

* "I didn't know we could do that!"
* "I didn't know we *had* to do that."
* "It just doesn't work.  We'll have to find a workaround."
* "We're gonna have to rethink our approach to this."
* or even ... nothing at all, as the look of horror spreads across 
their faces with the slowly dawning realization that they made a deeply 
flawed architectural decision at an early stage of the project, and 
that flaw is just now being exposed by some hitherto unknown (or 
unconsidered) restriction or requirement of the environment.

I believe that this problem can be reduced (although I don't foresee 
most teams moving in good directions anytime soon) but it can't be 
eliminated.  Even the simplest development platforms (I'm using that 
term to describe the entire technical environment in which an 
application exists) available today are very complex, and rife with 
bugs, puzzling interactions between layers and components, leaky 
abstractions, and arbitrary requirements and restrictions.  No 
development team *can* understand them all.  Any tool that purports to 
hide all of that from you comes with its own baggage of similar 
problems.

This is a major -- but too frequently ignored -- part of the milieu of 
software development that contributes to the inherent non-linearity 
that Andy has described so nicely.

---Glenn



------------------------ Yahoo! Groups Sponsor --------------------~--> 
Yahoo! Domains - Claim yours for only $14.70
http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/pragprog/

<*> To unsubscribe from this group, send an email to:
     pragprog-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/