Posted by
Raymond Martin-2 on
Dec 14, 2009; 11:27pm
URL: http://imagej.273.s1.nabble.com/Re-Laseray-contributions-ImageJ-tp3690010p3690026.html
On December 14, 2009 04:33:27 pm Jim Quinn wrote:
>
[hidden email] re: 100% backwards compatibility
>
> As a lurker and enduser for many years, I would like
> to see very high (99%+) backward compatibility.
>
> Evolution, not revolution, is what got NIHImage and ImageJ
> to the high utility that it enjoys today.
That is an empty idea. With all due respect to the previous work put into
ImageJ, if it were completely applicable then the program would not need this
massive re-design it is slated to go through. It would have already evolved
the functionality you desire, by having small revolutions along the way that
facilitate it, and only minor evolutionary changes would be necessary moving
forward. But a revolution is what this re-design is, no matter how you want to
look at it. So the idea does not match up with reality.
What needs to be understood by end users who do not have professional
experience doing software development is that there is a well-known
issue with users not understanding the requirements necessary to achieve
certain aims. It is very common in software engineering R&D during the
requirements gathering phase for users to ask for all sorts of capabilities
that are just impossible to implement within the constraints of the technology
or development/financial resources. On the other side of things, end users may
not know of pre-existing functionality that is relatively easy to put in
place.
As you can imagine this is a source of confusion, complaints, resistance, and
other problems that make the job all that more difficult.
I have had this experience before where users demand some functionality
and it is just not doable. They end up blaming the developers and years
later the functionality still is not there.
What is needed in this sort of situation is a balance between what the
software professionals can do on one side and what help the users, the domain
experts, can provide on the other to achieve realistic goals. This has to be
done in an ongoing consultation, where the domain experts are made aware of
the limitations of what they desire to be done.
No amount of demanding 100% backwards compatibility along with extensibility
will work if the resources cannot support it. Measuring, experimenting,
introducing releases with certain phases of support will eventually lead to a
determination of whether it is achievable or not. Those things have not
happened yet, so there seems to be a little bit of put the cart in front of
the horse here.
I wish I could instantly get across these well-know ideas from real-world
software development, but that just is not going to happen. It is not
the domain of expertise of the majority of users of the program. Try
to keep open minds about good things happening with the program,
but not necessarily unfolding in exactly the initial way imagined.
If people start closing off possibilities by just blunted stating no to
ideas that come from those who understand software I cannot imagine
how the program will get as far as it could.
Raymond