There seem to be two different sets of people writing posts on these topics:
The first set of people work for companies that have intentionally implemented standards for their work, be it CMM, ISO 9001, QS 9000, or any one of the numerous IEEE or ACM standards that are available to guide computer software development. To these people, these standards are just part of the background of everyday life, and are seen as necessary evils needed to get through the day.
The other set of people work for companies like mine: Anything goes. Sure we develop products, and sure we turn a profit, but could we do it next week, next month, or next year? No one really knows, because no one can describe how things get done.
Here is a personal example: We have some legacy software that needs modification. My list of questions are:
Is there a copy of the source code?
Who would have it?
Is the source anything like the compiled stuff we've been shipping for years?
Will the source code be one big anonymous 10,000-line main() function in C, without source comments?
And on and on it goes.. All I am trying to illustrate is that these management techniques serve to standardize and regiment how things are done. Now, if you are a cowboy programmer, that probably upsets you. However, if you are in programming for the long hall, the rational application of selected management techniques is golden.
There seem to be two different sets of people writing posts on these topics:
The first set of people work for companies that have intentionally implemented standards for their work, be it CMM, ISO 9001, QS 9000, or any one of the numerous IEEE or ACM standards that are available to guide computer software development. To these people, these standards are just part of the background of everyday life, and are seen as necessary evils needed to get through the day.
The other set of people work for companies like mine: Anything goes. Sure we develop products, and sure we turn a profit, but could we do it next week, next month, or next year? No one really knows, because no one can describe how things get done.
Here is a personal example: We have some legacy software that needs modification. My list of questions are:
And on and on it goes.. All I am trying to illustrate is that these management techniques serve to standardize and regiment how things are done. Now, if you are a cowboy programmer, that probably upsets you. However, if you are in programming for the long hall, the rational application of selected management techniques is golden.