[ckan-discuss] Clear scoping of requirements
john.bywater at appropriatesoftware.net
Tue Sep 7 14:05:09 BST 2010
Personal view from me below...
Jo Walsh wrote:
> dear all,
> I was chatting to Paola di Maio about what i see of the work on CKAN,
> she had some interesting reflections.
> There is pressure from different directions to do a lot to CKAN, but if
> all the requirements are clearly set out, i don't know where that is.
> There is a risk that we (meaning OKF, and developers working on CKAN)
> assume the risk created by larger organisations depending on CKAN,
> because exactly what we are responsible for may not be clearly defined.
> "One needs to be clear what kind of responsibility one is accepting".
> This means there must be clear and complete deliverables and
> specifications for work on CKAN, included in the project documentation.
> This means individual contributors should also be very clear about the
> scope of exactly what they are responsible.
> I doubt anyone who is really familiar with the CKAN codebase will
> contradict me when i suggest that it needs re-engineering from the
> inside out. The sooner this happens, the less problems (to do with lack
> of modularity and compatible extensibility) will be happening in future.
> It should happen yesterday.
Whilst there is probably something of real concern within what you say,
I wondered most of all, have you ever "re-engineered something from the
inside out". I haven't. And I feel it would a mighty strange thing
suddenly to do to CKAN, given that it is (without question) working
In general, productive contributions tend to follow the tendencies in
the industry: for things to become increasingly open, incremental,
well-patterned, shared, supportive, and adequate. (Which is yours?)
Under such a tendential analysis, CKAN measures up very well. CKAN is
rapidly moving in the right direction along all of the right lines.
In contrast, you seem to be asserting what I feel is a common ignorance,
and one which often passes for a moral absolute, that "everything ought
to be made clear". People even try to do that to their lives!
However, the object of a life (or indeed of a software project) is
probably not to make everything clear. What counts is getting things
moving. The genius is the person who gets everything moving.
We certainly don't need to solve false problems, and believing we have a
problem that we don't have is one definition of neurosis. Unfortunately,
a proposal to undertake neurotic analysis may constitute a real problem.
Therefore, it is a neurotic analysis that requires all requirements to
be clear and complete. In reality, we require only an adequate
understanding of what customers (and the users they represent) want or
need to accomplish, coupled with an adequate means of processing that
understanding into working software. In order to sustain velocity, we
must be closed to neurotic analysis (and neurotic development, and
neurotic service provision, and neurotic collaborations, etc.).
And so if you would like commit more time to this project, I'm sure we
could hook you up to some real problems fast enough. :-)
More information about the ckan-discuss