Obviously, these things exist a long a continuum. For example, at Google, people do tend to write design docs, maybe because writing and sharing them are so eas

Obviously, these things exist a long a continuum. For example, at Google, people do tend to write design docs, maybe because writing and sharing them are so easy with Google Docs and Google Sites. We also write lots of "Getting Started" docs, so a new team member can check out code and know how to get his project up and running quickly. How to commit and test changes. How production works. Privacy, Security, Logging, and Monitoring related docs. Source Code documentation seems better than most companies I've worked at, and Code Reviews are not skipped. The source control system won't allow you (without overrides) to commit without review and approval for most projects. We also don't like committing hacks just to get something to work. It is generally understood that a //TODO -- will clean up later, or promise to do so will almost never actually be cleaned up later. Rushing creates technical debt. Not saying it doesn't happen, but the degree to which people commit something they know to be wrong just for expediency is low. This certainly affects agility. All of the burdens of docs, reviews, testing, et al do slow down iteration, but I've also been slowed down by hacky code at other companies. It's a trade off. Personal projects are a way to let off steam and feel agile again. There you can bypass reviews, tests, docs, and just hack hack hack.