Announcing the FLUID Project
michelle.dsouza at utoronto.ca
Thu May 10 18:08:09 UTC 2007
Hi Mark, this is an interesting conversation - I'm glad that we are
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
> 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
> 3. Create an initial architecture
> 4. Test this architecture by building models and prototypes of
> 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
> However, the first approach, there is the danger that the ordering of
> component development will have a radical impact on the architcture
> 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.
Software Developer, FLUID Project
Adaptive Technology Resource Centre
University of Toronto
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work