[ckan-discuss] Clear scoping of requirements

[John Bywater]

Hi Jo,

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

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

Best wishes,

John.


> 
> jo
> -- 
>