Eliezer S. Yudkowsky wrote:
> The interesting question is whether the benefits come from "disciplined
> practices" that are incompatible with open source (why can't
> open-sourcers be "disciplined"?), or the engineering CASE tools that go
> along with being the sort of company that engages in disciplined
> practices.
The evidence is already in on this one. Other things being equal, simply
adopting CASE tools can be expected to yield only a modest improvement in
productivity. You might get a factor of two or three if your tool is
especially well suited to the work you do, but most companies see much
smaller effects. It is not at all uncommon for productivity to actually
decline after CASE tools are adopted, and the same is true for just about
any other technological fix.
Efficient software creation requires an organization to have a methodical,
long-term effort to improve the way it creates programs. This includes
systematic testing and defect tracking, standardized coding practices,
quantitative estimation methods, risk management, change management, and
professional project management. It means you have long-term in-house
efforts to find better ways of organizing your development teams, to write
custom software that supports your development process, and to find and
eliminate sources of defects in your software. Finally, if you want the
effort to succeed it means having a stable group of staff members who can
accumulate a lasting body of knowledge about your development process.
Now, the reason why I don't think open source development can effectively
use this approach has nothing to do with the character of the developers
involved (though I will note, in passing, that IMHO open source enthusiasts
tend to be very hostile to the idea of any kind of centralized management of
the development process). The problem is that each developer can only
organize his own efforts, and the supervisory group has neither the
resources nor the ability to impose much order on the resulting chaos. Why
not? Because (limited funding) x (more people working fewer hours each) x
(no financial stake for the developers) x (no means of enforcing decisions)
x (little or no personal contact between anyone involved) inevitable yields
a huge increase in the effort required to exert any control at all over the
development process.
Consequently, I expect that open source efforts will be limited to the few
process improvements that can be implemented by automated systems (i.e.
version control, elementary bug tracking). Meanwhile, conventional
organizations can pursue a program of substantial progressive improvements
that (at least so far) has no known upper limit.
E. William Brown V, MCSD
bbrown@transcient.com
P.S. I'm sure most of us are aware that software development becomes
progressively less and less efficient as the size of a project increases.
Large organizations therefore estimate the effort required for a given
project with formulae like:
Effort = X * KLOC^Y
Where X and Y are derived from performance data for similar projects in the
past. Y is typically around 1.15 for large organizations which do this sort
of record keeping, so you can see that programming effort per KLOC becomes
prohibitive beyond a certain point. It is therefore encouraging to note
that NASA's SEL (Software Engineering Laboratory) has recently achieved
Y=0.986.
This archive was generated by hypermail 2b29 : Thu Jul 27 2000 - 14:02:17 MDT