> From what I understand they're saying that unit testing isn't "real actual work". You write unit tests to save yourself debugging and regression testing effor

> From what I understand they're saying that unit testing isn't "real actual work". You write unit tests to save yourself debugging and regression testing effort later. This sent off my faulty logical implication detector. Assuming that debugging and regression testing are work, doing something that isn't work right now to avoid having to do something more tedious and time-consuming that is work later on seems like a good trade-off to me. This seems like splitting hairs over the definition of work, and worrying about semantics rather than the end result. > Joel and Jeff mention that code quality doesn't matter much from a _business_ perspective. Yikes. This reasoning scares me. I can understand the business not caring directly about the quality of code, in that people working from that perspective would go in and start doing code reviews. But indirectly the implications are huge, and any business man who would claim not to care about the code base is really saying to me they don't care about the longevity of their business. The success of the business is directly tied to the ability of the developers to continue making things that people want, and this is way easier and faster when they aren't consistently confounded by the code.