His second example seems to be closer to reality than the first one. In reality you are likely to have a set of programmers (more than two) with varying levels

His second example seems to be closer to reality than the first one. In reality you are likely to have a set of programmers (more than two) with varying levels and communication skills. Added to that as somebody else mentioned, this is just a "job" to most people and you are likely to have a team change over time (people move on or get laid off etc). Given this scenario it is more beneficial to have - Well defined initial requirements - Every item speced out - Proper class diagrams - Functional requirements - So much detail that even X can code it (where X is a current/future employee with a variable technical and communication skill and interest level). He additionally cites the case where he has personally observed "100 person companies" that manages to hire Group 1's. I am more interested in hearing about this case rather than read about his personal principles. "My personal principle is that if you’re not smart enough to be able to communicate well and produce good code without a strict formal process, I don’t want to be working with you." I am still trying to figure out how somebody could use a strict formal process to overcome the disability to produce good code.