Announcing the FLUID Project
markjnorton at earthlink.net
Thu May 10 20:03:26 UTC 2007
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
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
> 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
> 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
More information about the fluid-work