4 ms·

The authors paints with a brush that is entirely too wide for the canvas. He's a student with no real world experience in putting together a system. Because of

by bprater 18y ago

The authors paints with a brush that is entirely too wide for the canvas. He's a student with no real world experience in putting together a system. Because of that, it's easy to conclude that drones create software from reams of paperwork and ninjas wing it and hack it out in a few days with Coca-cola and Ramen. The real reality is that neither extremes is useful or done exclusively. Sitting down and putting at least some of the architecture down on paper can be useful. If you have a team larger than two people, it might be necessary to document some of the process so that people know what part they are playing. I wish him the best of luck -- he will be tempered to neither extreme after he's spent some time working in various places.

jayair 18y ago
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.

by bprater 18y ago

jayair 18y ago

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.