CMSCD3005

[ Home | Contents | Search | Post | Reply | Next | Previous | Up ]

For a minute there....

From: J
Email: cmsjeast@livjm.ac.uk
Remote Name: 150.204.50.59

Comments

...I thought I might be insane. Then I stumbled across this article examining the relevance of traditional development methodologies in Open Source projects which agrees with me entirley and is backed up by actual research!: -

<heavy research, the conclusion of which, could just have easily been reached by wandering around in a caffeine/nicotine induced trance state, apparently>

"CONCLUSIONS <here's what we want>

The purpose of this paper was to identify the development methodology used in open- source software development projects, using widely known software development meth- odologies as a starting point in our analysis of the projects presented in our case study.

Open-source software development is not governed by the principles outlined in the life- cycle, prototyping or spiral model paradigms. The spring-point that makes these projects not fit those paradigms are that they don't face the same kind of managerial and eco- nomic problems as traditional in-house software development projects -- as contributions to open-source software projects are done on basis of will rather than duty, they don't adhere to traditional rules of pay-for-code development efforts.

The methodology used in open-source software development is best described using the theories of evolutionary software development, and particularly well defined using the versioning model presented by Budde et al. [BUD92], which illustrates the software system as an evolving entity in a system of user and developer communities."

So what does this mean? Firstly, that I am superior. Secondly, that evaluation of methods and methodologies MUST take into account context - the point I have been trying to make by drawing attention to exmaples that disprove the general rule "method(ologie)s improve software".

Having established that methodological approaches are not a pre-requisite of quality software, we must ask the question "In what circumstances ARE these approaches useful, and what does that tell us about the circumstances (should we change them?)themselves and the value of the method (is it optimal in the given context)?"

This would seem to me to be a more honest and productive way of evaluating individual method(ologie)s and the subject as a whole. In other words, ask how, given the situation/people etc an approach can be beneficial - is it even necessary?

Just MHO(?) ...and remember folks, "common sense is what tells you the earth is flat".

Last changed: October 05, 2001