Posted by smontgom
on March 31, 2004 at 5:03 PM PST
Subtle changes to the software process might greatly improve the foundation of public code in niche domains without creating too many headaches.
The goal of research is to evaluate a new idea and create a body of work
that can improve the methods of scientific inquiry, either by simplifying
the process or by uncovering new knowledge. When research-driven software
exists in the public domain it is serving this very purpose. However, it
is too common to download a new algorithm or API and find it sparsely
documented in terms of overall readability. Standards like the JCP have
it right for community development: a strict sense of the requirements and
direction are captured early in the process. It is unfortunately very
difficult to get small software development groups who are targeting niche domains
to remember that when they develop code for the community, they should be
writing software for people first and computers second (as Steve McConnell
might put it). Implementing a community process amongst these groups is
likely to be as easy as getting IBM and Sun to agree on a direction for
Eclipse (was that one too easy?). Competing funding, (do I dare say)
personalities, and the impending deadlines created by various
goal-oriented parts of our psyche all counterbalance the investment in
processes and standards. I agree that no one wants to spend their
research money on the time it might take to implement an architecturally-correct
solution and no one should be expected to. What we need to
agree on is when an open-source application becomes an open-source
contribution. At this point, architectural items need to be revisited.
While some are up to the challenge, for others the incentives are too few, as funding is regularly associated to novelty,
journals/review boards impose no restrictions in general, and it may just
not be as fun as that next idea you have been thinking about. The latter
we can obviously do nothing about (nor would anyone recommend that it is a
problem) and recommending changes to the process of funding and peer-review
is at best controversial. Maybe as Java developers we need to be thinking
more about how we can individually implement subtle standards that change
the standard practice of software development in our own projects and
amongst the greater pool of developers. I have jotted down a few that
came to mind that might start us off. Is it possible to create an ideal
set of standards that wed want to have implemented?
- Package-level comments in source. (Whenever a new package is created,
prompt to create a metadata description of it).
Tutorials on IDE development (i.e. how to create a project) should try
to mention the mental activities that occur between starting the IDE and
opening the editor.
Tools to rapidly identify classes that may have missed commenting (have
high method to documentation ratios).
Default warnings for public single-letter member variables. (Or would
this bother anyone implementing a Point class). Or maybe we could also
identify SLOCs with a high-density of single-letter variables.