If we are not honest about the causes of a bad situation, we pose a significant danger to those who are either less-experienced or uncertain about their own situation. Take a slow test suite, for example. Having a test suite that actively hinders a developer from running portions of it while developing is a deterent even to run the suite at all. As the run time climbs into minutes, the test suite becomes an antagonist, rather than the helper and guide that it should be. Instead of rationalizing, say you have some serious design flaws in your system. Or, say you have a large codebase and a huge team consisting of people with varying desires to write automated tests. When we mask the real causes of a problem, it has the potential to confuse less-experienced developers who look to us for guidance. For example, thinking a slow test suite is inevitable could stop someone from asking for help optimizing their own codebase while there is still time.
I completely agree with Corey here. There are very few true cases of “that’s just the way it is”. You just can’t do continuous deployment… except that you can. You can’t have a productive distributed team… except that so many companies do. You can’t really isolate your units in order to test them… unless you have the discipline to do just that.
“You can’t speed up a project by adding programmers”. That’s about the only rule of software development that I can think of which has stayed largely inviolate. And even that one is somewhat fungible depending on the type of project and the culture that is in place. Most “rules” are really cultural mores, taboos, and superstitions, passed from team member to team member.
What superstitions have you internalized?