If I had my druthers (continued)

As far as I can tell, the primary purposes of software programming methodologies are a) to reduce wasted time and effort, and b) to increase the overall quality of the product. (These are not, of course, truly separate concerns, but eh.)

1. The management of resource consumption consumes resources.

Most (if not all) software programming methodologies also involve large quantities of out-of-band information. This requires:

• additional effort on the part of developers to produce and maintain this information;
• the purchase and/or development of additional software for the purpose of collecting and organizing it; and
  
• analysis (which can only rarely be entirely automated) of this information by management.
  

All of these involve the expenditure of further resources which could have otherwise gone to features and bugfixes. If the effort and money spent on these is greater than the savings they afford, it's clearly not a good idea: and for small projects, there will only ever be a finite amount of room for improvement in the areas that a methodology can improve.

2. You cannot squeeze blood from a stone, nor quality from a poor programmer.

If a programmer who writes poor code is made to follow a given methodology, this will not improve their code — they will simply also produce poor sideband documentation and explanation of their actions. The project I work on has required people to document their changes and addition to the codebase for at least the past five years. My predecessors' comments have nonetheless often ... failed to shed sufficient light on the workings of their code, to put it politely.

This is in no way an argument against keeping documentation and properly commenting code — it's just that I don't think very good documentation or comments (or code) are likely to be written by the sort of person who wouldn't comment their code even if it weren't required.

I recognize that this is an argument from personal incredulity.