3 ms·

The podcast covers unit testing and code quality at 45 minutes in or so. I haven't listened to the entire podcast, so I may have gotten this wrong, but it seems

by jd 18y ago

The podcast covers unit testing and code quality at 45 minutes in or so. I haven't listened to the entire podcast, so I may have gotten this wrong, but it seems like Joel and Jeff made only nuanced statements. No unqualified remarks like "testing is bad" were made, I think. Joel and Jeff mention that code quality doesn't matter much from a _business_ perspective. In Jeff's case - does the code quality of StackOverflow's internals matter? Probably not. There's no critical information there - so security is not an issue. It makes sense to me that time spent on features is going to be appreciated more by the users than time spent on code quality. As for the unit tests - I don't think they mean to say that unit testing is a waste of time in general. 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. If you consider unit tests intrinsically valuable you may end up writing tests for every getter and setter, and that's just a waste of time. They also mention that unit-tests themselves have to be maintained and updated, and if architectural changes break a significant percentage of unit tests then you have to put a lot of effort in fixing your tests. The .NET framework was even mentioned as an example where high code quality is incredibly important and where all interfaces should be extensively unit- and regression-tested by Microsoft. > I’m starting to wonder if anyone should be using any of their products. So happy users of Fogbugz and StackOverflow should leave because Joel and Jeff are too pragmatic?

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

by jd 18y ago

azanar 18y ago

> 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.