10 Programming Proverbs Every Developer Should Know

Whenever I read articles like this, it makes me wonder why half of it even needs to be stated; then I go and look at the code base for some of the companies that I do development for. At that point I realize that, planning, documentation, and "fixing broken windows", are all activities that you need to build into the core values of your company from the start. They need to be so ingrained in the culture, that people participate in them on an intuitive level, instead of it being a after-thought. The time spent working around "known bugs" far (exponentially) exceeds the time it would have taken to fix them before they were part of the current stable release.

I like the "bus factor" discussion. It's #3 in the article. In the projects I've been a lead on, the bus factor is in a sense 1: each hacker is responsible for their own module, and while others might read their code, they don't contribute (except report bugs).<p>However, the modules are set up so that there is a clean separation between them, with all interaction being through well defined API's. In fact, each hacker typically uses their own server unless/until efficiency constraints force us to do otherwise. So far it's worked well. If one person goes away, the project can continue until they come back or one of the others can learn/duplicate their module.<p>This allows us to dramatically increase prototyping speed, but may not be sustainable as project size increases.<p>I'm fairly inexperienced, so I'd like to know what you guys think about this practice, since it's something I think about a lot.

Architecture astronauts should take careful note of points 7 and 9. I've read some obsessive-compulsive discusions regarding RESTful design around here lately. You don't see much focus on the customer.