Announcing the FLUID Project

[Mark Norton]

Michelle D'Souza wrote:

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

A minor contribution, surely.  :)

> The only difference that I see between the two scenarios is step 
> number one - "Look at some use cases" versus "Gather all use cases".

Even I wouldn't presume to suggest that Fluid "Gather all use cases".  
Rather, I was hoping that a sufficient number of them already exists, or 
at least representative samples.  My suggestion is to consider them as a 
whole (first) to suggest an architecture.

> 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.

Hmm.  I have a nagging doubt about that.  Oh, likely you're right:  
Moodle, Sakai, uPortal, etc. all change from month to month.  On the 
other hand, do the requirements really change? Isn't it the case that 
these projects and their predecessors have all be trying to do the same 
things, but that advancing technology enables better solutions?  Can you 
give me an example of a requirement that's new -- say within the past 
six months?  Feature requests don't count unless they call for genuinely 
new UI concepts.

Speaking as someone who's been involved with eLearning for more than 15 
years, we are still trying to solve the problems that I was up against 
in 1995.  Not that there is anything wrong with that.  As I say, new 
technologies enable new solutions to old problems.  Sadly, much of the 
earlier work may be lost in terms of use cases, scenarios, and 
requirements.  That would mean duplicating work that could be better 
spent on solutions, IMO.

> 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.

It is just my opinion, but making small incremental improvements to 
existing tools, however useful, will not lead to an innovative 
architecture.  How will small improvements (even radical ones) suggest a 
new architecture?

> The intention is to build a foundation that is extendable rather then 
> requiring a complete redesign and rebuild. 

A classic problem with respect to good architectural design.  Too much 
flexiblity is not a good thing.  It doesn't promote good practice or 
lead to standards.  The trick is to the "just the right amount" of 
flexibility.  That is very difficult to achieve until a sound 
understanding of the problem is ready.  Consider:  we will express all 
re-usable components in XML.  XML is very extensible, so we won't have 
to worry about adding to it later.  Do you see the problem with this?

> 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.

Well, regression testing is just as much of a moving target if the 
architecture changes constantly.  Besides, the whole point of my 
argument is that Fluid needs to extract, document, and understand the 
requirments of what they are trying to build.  I would argue that 
regression testing is pretty much a waste of time unless you have said 
requirements.

> 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.

We are, Michelle.  I'm just trying to point out some things that (I 
believe) will make it go smoother and increase the chances of success.

- Mark Norton