cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject [RT] Cubist WebApp Team Organization (was Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition))
Date Sat, 02 Aug 2003 11:06:20 GMT
Hi again :-)

just adding some more phylosofical notes on webapp design and 
modelling (it is week-end after all, hope you all don't mind me 
getting into the meta levels of things)

<snip />

>> as explained my feeling is that woody's model should be as decoupled 
>> from the 'template' as it is from the 'backend-model' 
> Agree. But the date-with-3-fields use case if the perfect example where 
> GUI decisions (using these 3 fields instead of a single input) have an 
> impact on the Woody model.

of course.
However it is my strong believe that they _should_.

I didn't want to guarantee full decoupling!
but rather equal or at least balanced decoupling/influence

That is where the phone-number example comes around of course...
there you have the db-admin decision to split up over different 
fields instead of just one...

On the grounds of datatype-checking and validity (ie the service 
Woody wants to offer for easier back-end integration) we seem to 
be comfortable with adding it to the model?

 From that POV, Woody should not feel any unease in supporting 
some of the features brought on the table by the front-end design 


Actually we are touching the subject of how to organise the 
webapp project team more then anything else, and I'm really 
afraid there is not ONE best strategy to do so..
(but we both feel that some technical decision in one way or the 
other will have a social impact on how the team will end up 
working together so we keep feeling the urge to defend our view)

Actually it's quite nice to see how we both are understanding 
each others view, and are just adding more people to the show to 
stress a bit our own nuance on the subject...

you: focus on template-designer
RE me: stressing model-designer
RE RE you: yes, but: layout-designer
RE RE RE me: sure, but equally: db-admin (back-end specialist)

Playing the honest scientist from both sides we are likely to end 
up seeing that the number of responsibilities is reaching 
infinity and ranging them on a linear scale results in a 
continuum of stages smeared out into each other.

The hard task of defining the SoC is all about *sampling* this 
responsability domain (i.e. mapping the continuum onto sensible 
discrete layers)


I understand that this domain is not linear at all, but has a lot 
of dimensions (aspects to be taken into account), however the 
linear view is one that we people tend to like a lot when 
thinking about projects in general and the technical setup of the 
web is somewhat inforcing that view:

- indeed: a drawing of a web-request being processed tends to 
result in an arrow-line starting at the browser, and passing 
whatever set of layers end up at the back-end logic (and vice 
versa for building up the response) (this applies for close to 
all software solutions I think, maybe inference engines escape 
this when looked upon from high enough)

- from a planning POV all projects tend to be measured against 
the universal linear dimension that is ruling our human lifes 
more then just a bit: TIME

By mapping this eternal linear dimension onto the team 
organization we are bound to fall into the waterfall: this has to 
be ready, for that to be started, etc etc (we like this cause it 
appeals to our human built-in cause-consequence thinking and 
really allows for a rather easy milestone management of the project)


No matter where you 'start' to tackle the problem, taking the 
linear view is likely to leave you with the so called 

This is a story I once heard from a person making educational and 
entertainment cd-roms in C++ (this is back quite some time: I was 
doing perl cgi's at the time and fealt some high match level)
In his industry the typical approach would be to let conceptual 
people (story-board authors) think up something that was smashed 
into great drawings and sketches making up the 'visual 
He compared this to a boa with a very flexible mounth that can 
stretch so far as to the moment where it could actually swallow 
an elephant (at this time you should take your copy of 'le petit 
prince' and look at the first two drawings ;-)

The catch of his comparison was this: the actual C++ development 
team was completely at the end of the digestion-process: the 
complete elephant needed to pass there (ouch)

Reversing the chain is not a real help: then you end up with 
frustrated front-end designers that are tied down enormously by 
everything that has been technically/formally streamlined with 
totally different goals then the ones they want to achieve.


I'm afraid I'm falsy leading the reader to this point:
   "Please tell us: How to escape the linear thinking?"

I honestly think the goal is a false one: we can't go by at our 
human nature: we think in cause-consequence and our very 
existence is measured in terms of elapsed time and endured 
change-cause-consequence-more_change over that time.

IMO even strategies like RUP's iterative development and XP's 
refactoring are (while being most valuable) only touching the 
surface, and can't go by at this baked-in fundamental human 
common sense: such and such needs to be before such and such can 

So we are doomed either way?
Sure: the law of constant misery is not to be set asside (not 
without more misery at least :-))

However while I used the 'touching the surface' in a very 
disrespectful manner, there is in fact something that it can achieve:

Let us read 'touching the surface' as 'agreeing upon the 
contracts' and 'defining the interfaces' and we see how this can 
result in something real (the interface) that can launch two 
parallel development tracks to escape the boa-digestion (into two 
smaller ones)

So no more development process that jots down the concepts on one 
side of the chain.

concepts --> front-end-designers --> back-end-engineers

front-end-designers <-- back-end-engineers <-- concepts

but rather:
       ( discussed, aggreed,
     and maintained by both parties)
            /     \
          |/_     _\|
    front-end     back-end
     design      development

Q: Will this approach guarantee a shorter (time) trajectory to 
completion for my project?
A: The introduced parallelism suggests this, but I wouldn't bet 
on it. (a bit like the discussions on XP's pair programming model?)

The main advantage I see brought in by this approach is that the 
introduced moment of contract-negotiation and (re-negotiation) is 
a formal point where the requests and needs from the both sides 
can collide and come to a consensus.

This of course assumes that both parties are prepared, have the 
time, and the knowledge(!) to enter as peers into this discussion.

I find this discussion-as-peers-process something that very 
naturally goes about in OSS communities, but are often hidden 
away in a dedicated architectural team in large corporations: 
thus defeating the actual COMMUNICATION goal and getting us back 
into a strictly linear model. (and honestly: I disliked the 
'architect' character in the Matrix Reloaded right away :-))


Coming back to the discussion at hand the above reasoning would 
lead me to sustain to the model-designer role that Woody 
introduced, but urge us all to map it not onto one specific 
person but see it as the result of the team-effort to actively 
understand both sides of the issue.

IMO, SoC is more about colaboration then it is about separation?
SoC == CoS: Colaboration of Specialists?


General disclaimer:
I enjoyed dumping my current state of brain here (introduced by 
our thread), still hoping to achieve more then just my personal 
Being my own personal view of the moment I tend to use a wording 
that tries to persuade, the reality is that I'm always in doubth :-)

<on the side>
I agree on leaving out the technical decisions for now on the 
'date' stuff (however: we kind of do need the (already existing 
in woody) reciprocal 'phone' thing on short notice)
</on the side>

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message