EPP/PEP Sugested task list

[Trent Shipley]

On Saturday 2005-03-26 01:01, Alan Dayley wrote:
> This list is interesting.  I have inserted a few comments with some of the
> list quoted for context.  Take them or leave them.
>
> On Friday 25 March 2005 09:06 pm, Trent Shipley wrote:
> > [NBB!  This plan, with contributions by Bryan, Derek, and Trent
> > iterates over customers or sub-projects rather than Joseph's preference
> > for the outer iteration loop over a master architectural plan.]
>
> I don't understand the distinction here between this plan and Joseph's but
> I did not read every email in the discussions over the past week or so.
> Maybe I missed it but I'll go back and read for myself.

At the risk of putting words in Joseph's mouth, here is my understanding of 
previous discussions.


I advocate iterating over smallish, customer centric projects in the domain 
space.  Furthermore, you would do so much the way a commercial firm using 
agile methodology would.  

For example (take to an extreme of purity), if everything Installfest wanted 
could be done by a little PostNuke extension, then that is what you would do.

Then you move on to the Mega-Installfest.  If the Installfest work turned out 
to be a dead-end in terms of software architecture with regard to 
Mega-Installfest, you chuck the Installfest work and do not look back.

I call this iterating over cases or customers.  (This is akin to an outer 
loop.  Obviously you also iterate within each project.)

Iterating over cases has the advantage that you do not have to have in-depth 
understanding of the broader domain.  Another advantage is that everything is 
just the right size.  Disadvantages are lots of unsupported legacy code, 
architectural dead-ends, and avoidable reinvention.


Joseph wants to iterate inside a comprehensive software architecture (also an 
outer loop).

For example, in the case we are talking about he seems to want some sort of 
comprehensive Event software integration to be the backbone of the product 
life cycle.  Clean, stable, unified software architecture is critical so we 
need top-down software design combined with emergent bottom-up agile coding.

Stretching the example to the greatest extent we would locate the largest 
events available.  Suppose these were the Summer Olympics and FIFA World Cup.  
We would analyze these enormous events on the not unreasonable assumption 
that all other events must be a functional sub-set.  With the first returns 
from our research on mega-events we would begin our efforts at software 
architecture.  After a few iterative refinements between research, analysis, 
and high level design we would start work on a smallish event software 
integration problem, like Installfest automation.

The model itself is not static.  It is amended based on knowledge gained from 
project experience.  Nevertheless, it is assumed that resulting changes do 
not turn the model into the sort of dead-end snarl of legacy architecture, 
APIs and features that are known to occur when you iterate over cases.

There is dispute about how much domain uncertainty can exist for iteration 
within a comprehensive model to be a viable approach.  Theoretically, 
iteration within a comprehensive model should result in minimal dead-ending, 
legacy code, or need for reinvention.  If you like, the product is tailored 
to one case; that case is the entire domain at its maximum extent.

=================

So one side says research Installfest, analyze Installfest, design 
Installfest, build Installfest, END.

The other says research Olympics, analyze Olympics, design Olympics, build 
Installfest, Mega-Installfest, .. , Olympics, END.

There are more practical compromises and intermediate positions, but only the 
ideal poles have been staked out.  Work on practicalities and real-world 
compromise approaches has yet to begin.