Announcing the FLUID Project

[Michelle D'Souza]

Hi Mark, this is an interesting conversation - I'm glad that we are  
having it.

On 9-May-07, at 10:57 AM, Mark Norton wrote:

>
> I sincerely hope you understand what you trying to design before  
> you set
> out to do that.  Consenus on abstract requirements early on will  
> save a
> lot of debate later.
>
>> I think we're on the same page here in terms of architecture. My plan
>> is to define a general shape for our technical model, create
>> components to solve key usability and accessibility problems, and at
>> each stage in the development process take the time to refine the
>> architecture from a top-down and bottom-up approach.
>
> Well, this is just my opinion, but I think you are setting yourself up
> for a lot of extra work by taking this approach.  Consider:
>
> 1.  Look at some use cases.
> 2.  Create a component to solve this problem.
> 3.  Change the architecture to encompass this solution.
> 4.  Modify all previously created components to fit the new  
> architecture.
> 5.  Look at new use cases and iterate.
>
> It's that forth step that you left out of your statement above that
> creates the extra work.
> Consider instead:
>
> 1.  Gather all use cases (etc).
> 2.  Create a broad set of requirements the define what much be  
> accomplished.
> 3.  Create an initial architecture
> 4.  Test this architecture by building models and prototypes of  
> components
> 5.  Iterate and refine both models and architecture
> 6.  As models and architecture settle out, create tests based on
> requirments for components
>
> Now in both cases, the architeture is successively changed and  
> refined.
> However, the first approach, there is the danger that the ordering of
> component development will have a radical impact on the architcture  
> and
> design later on.  In the second approach, the initial design takes a
> much broader view.  In my mind, this reduces risk, because I'm not
> focused too closely on one aspect of a much larger problem (as defined
> by the requirements).  The chances of get it "close to right" are
> higher.  The subsequent changes to the architecture are likely to  
> have a
> reduced impact on existing models and implementations.
>

The only difference that I see between the two scenarios is step  
number one - "Look at some use cases" versus "Gather all use cases".  
In a world where software is not so soft that it can change I would  
certainly want to gather all the use cases up front. However, in a  
dynamic open source project such as Fluid that must deal with the  
features and requirements of many other projects we must be prepared  
for change. So while the Fluid design team is taking a holistic view  
of the projects and determining overall pain points and requirements,  
they are also taking a focussed view of actual tools and portlets  
that are in use. The plan is for the Fluid development team to make  
improvements to these tools and portlets thereby improving the user  
experience immediately. That is not to say that we won't do any up  
front architecture. Certainly we all know from experience the value  
of thinking through a problem and modeling a solution.

The intention is to build a foundation that is extendable rather then  
requiring a complete redesign and rebuild.  At the same time we will  
ensure that we have the necessary tools to refactor when it is  
necessary.  One of the most useful tools for this job is a full  
regression test bucket. While test driven development has many other  
benefits, providing the security required to refactor is one of my  
favourites. As you mentioned, good software doesn't just emerge - it  
requires design and refinement. It sounds to me like we are saying  
the same things.

Michelle



------------------------------------------------------
Michelle D'Souza
Software Developer, FLUID Project
Adaptive Technology Resource Centre
University of Toronto



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070510/060df6e9/attachment.htm>