While you might conceivably have some valid points, the fact that you're apparently unable to express yourself in a coherent way suggests that, by-and-large, you are wrong. The paranoid, who cannot write decent documentation or do the things that should be done as they should be done will always cry foul: since you're unable to follow the processes of careful engineering, they must be a cynical method by which to protect one's own job.
I find it quite strange that the same engineers who espouse the virtues of good implementation, software engineering, CS degrees and so forth one minute seem always to criticize such practices the next, particularly when they're suggested by the ever-evil management. Honestly, half of the previous post is mere ranting and, from where I'm standing, it seems that it's Sinsterian him/herself who is the more concerned with "power (Job Security). Without wishing to be too much of a language nazi, somebody making such horrendous grammatical and spelling errors isn't likely to be the best person to design or document a project in a meticulous manner. There's a vast arrogance amongst many hard-core coders who think they're the only people who have any true understanding of how a project should be designed, and that their methods are inherently superior to any more formal methodologies.
I once had the pleasure of holding a long conversation with a woman who led a team of testers on various fairly high-profile government projects. She made the point that most developers don't _want_ to document and test; they merely want to write code. She also made the point that this kind of attitude is death for any project of a significant size. The OSS movement seems at first glance to give the lie to this argument, but in reality a number of OSS projects are far more rigourously controlled and managed by their proprietary counterparts; because the individuals concerned generally have a very real desire for the success of their product, though, and because they're often very talented coders, things get done in a fairly decent way. Contrast this with designers/programmers who are the "only people who really know the code", and who (it would seem) have no interest in getting the code documented properly -- this is a disastrous situation.
I work as part of a small team of engineers, most of whom have no formal training. While I enjoy and appreciate the relatively relaxed nature of the development, my (admittedly rather lax) years at University studying a CS degree have led me to be a regular advocate of doing things in a more structured manner, especially as the size of our development team grows and project complexity grows.
As always, there's an obvious tradeoff between the demands of rigourous project management and getting code written quickly and in a decent atmosphere. The issue of how best to scale a project is one that is often addressed: for the small project, certainly, there's no need for elaborate management methodologies and indeed such practices would only detract from the success of the project. Anyone who has worked with a project on a long-term basis, though, will understand the need for a greater degree of control: individual liberties needs must be subsumed for the good of the project as a whole. The greatest danger for any project is the renegade coder who, talented as he might be, refuses to comply with accepted practices because he thinks his way is "better".
Introducing such methodologies is a whole other issue, of course, and I'm not experienced enough to pretend that I have any perfect answers. I would caution, though, against bracketing all consultants as inept, money-hungry vultures without true experience or knowledge. Such types exist, of course, but so do very knowledgeable, very intelligent consultants who can provide a unique, very valuable perspective -- and, indeed, third-party review is almost essential to any large project in which in-house developers may be too closely involved to see alternatives, problems, or incorrect assumptions made by their internal process. I'd argue that this factor is one of the chief benefits of the open source movement -- independent review is often carried out by many diverse people, each of whom may bring his or her own insights even if they're not directly involved in development.
So, think a little harder before knocking methodologies that you probably don't understand and that could probably do you a lot of good if you'd only spend the time in getting them right. You're not always the best person to judge how a project should progress, even (or perhaps especially) if it's something you've been involved in from the start.
Slashdot Mirror
I find it quite strange that the same engineers who espouse the virtues of good implementation, software engineering, CS degrees and so forth one minute seem always to criticize such practices the next, particularly when they're suggested by the ever-evil management. Honestly, half of the previous post is mere ranting and, from where I'm standing, it seems that it's Sinsterian him/herself who is the more concerned with "power (Job Security). Without wishing to be too much of a language nazi, somebody making such horrendous grammatical and spelling errors isn't likely to be the best person to design or document a project in a meticulous manner. There's a vast arrogance amongst many hard-core coders who think they're the only people who have any true understanding of how a project should be designed, and that their methods are inherently superior to any more formal methodologies.
I once had the pleasure of holding a long conversation with a woman who led a team of testers on various fairly high-profile government projects. She made the point that most developers don't _want_ to document and test; they merely want to write code. She also made the point that this kind of attitude is death for any project of a significant size. The OSS movement seems at first glance to give the lie to this argument, but in reality a number of OSS projects are far more rigourously controlled and managed by their proprietary counterparts; because the individuals concerned generally have a very real desire for the success of their product, though, and because they're often very talented coders, things get done in a fairly decent way. Contrast this with designers/programmers who are the "only people who really know the code", and who (it would seem) have no interest in getting the code documented properly -- this is a disastrous situation.
I work as part of a small team of engineers, most of whom have no formal training. While I enjoy and appreciate the relatively relaxed nature of the development, my (admittedly rather lax) years at University studying a CS degree have led me to be a regular advocate of doing things in a more structured manner, especially as the size of our development team grows and project complexity grows.
As always, there's an obvious tradeoff between the demands of rigourous project management and getting code written quickly and in a decent atmosphere. The issue of how best to scale a project is one that is often addressed: for the small project, certainly, there's no need for elaborate management methodologies and indeed such practices would only detract from the success of the project. Anyone who has worked with a project on a long-term basis, though, will understand the need for a greater degree of control: individual liberties needs must be subsumed for the good of the project as a whole. The greatest danger for any project is the renegade coder who, talented as he might be, refuses to comply with accepted practices because he thinks his way is "better".
Introducing such methodologies is a whole other issue, of course, and I'm not experienced enough to pretend that I have any perfect answers. I would caution, though, against bracketing all consultants as inept, money-hungry vultures without true experience or knowledge. Such types exist, of course, but so do very knowledgeable, very intelligent consultants who can provide a unique, very valuable perspective -- and, indeed, third-party review is almost essential to any large project in which in-house developers may be too closely involved to see alternatives, problems, or incorrect assumptions made by their internal process. I'd argue that this factor is one of the chief benefits of the open source movement -- independent review is often carried out by many diverse people, each of whom may bring his or her own insights even if they're not directly involved in development.
So, think a little harder before knocking methodologies that you probably don't understand and that could probably do you a lot of good if you'd only spend the time in getting them right. You're not always the best person to judge how a project should progress, even (or perhaps especially) if it's something you've been involved in from the start.