5 ms·

Good point, but it's not just fanboys, I've seen Uncle Bob speak and he's a lot less reasonable then he was in his response to Joel. The thing is, it's appropr

Good point, but it's not just fanboys, I've seen Uncle Bob speak and he's a lot less reasonable then he was in his response to Joel. The thing is, it's appropriate for his audience, large cubicle farms with a completely broken system. So oversimplifying and extreme work for Uncle Bob when he's consulting. Joel was obviously talking about the kind of super star programmers he hires in his magical fairy land office. (Just kidding Joel, I wish I worked in an office like that.) The problem as I see it, is the difference between what's good for good programmers, and what's good for most people who happen to diddle with visual basic. (No offense to VB rock stars, keep on rockin'!) Kent Beck and Bob Martin are very good programmers, but they get paid from consulting large organizations with not so great programmers. Joel gets paid by hiring and working with great programmers, in his magical high rise office, with free gourmet food and rainbows.

nostrademons 18y ago
Most great programmers take very well to unit tests. The way they became great was to assume their code is flawed and take steps to remedy that. Perhaps I'm being a little harsh, but I don't think Joel or his employees are really all that great. I mean, they're working on bugtracking software. Great programmers tend not to trade interesting problems for private offices and gigantic monitors (plus, they often can get jobs at places that offer them interesting problems, private offices, and gigantic monitors).
- dasil003 18y ago
  I don't think anyone ever accused geeks of really meaning sexy when they say sexy. More like, to each his own.
- biohacker42 18y ago
  I absolutely agree everybody, including the great ones, should write unit tests. I think the storm in a programmer's tea cup here is exactly how much unit testing do you need. Joel is accusing Kent Back and Robert Martin of wanting to write a whole testing framework for each and every little get and set method.
  - nostrademons 18y ago
    That might apply to Robert Martin, but Kent Beck's on record as saying don't unit test getters and setters. "Test everything that could possibly break." So, strawman.
- demallien 18y ago
  No, really? FogBugz is written in a custom language created by the team for the application. Doesn't that sort of problem sound interesting enough to you? http://www.fogcreek.com/FogBugz/blog/category/Wasabi.aspx http://www.fogcreek.com/FogBugz/blog/category/Wasabi.aspx Honestly, the problem domain is not an indicator of the programming interest of a project. It's a general rule - if you are working in a boring problem domain, then you need to abstract out the boring part. Doing the abstraction is generally a very interesting task. Example: you have a GUI test rig for a set top box. Your task is to generate tests for the setup, which works by doing screen captures, and then comparing the screen capture with a pre-recorded image of the screen, to verify that error messages are correctly displayed. The problem is that the tests are brittle - if the designer changes the shade of a pixel anywhere on the screen, your test breaks and has to be regenerated - a very boring, repetitive and time-consuming task. So, change the system - right a screen scraper with some OCR, that can actually read the screen. Now the screen design can change, and as long as the message still appears somewhere on the screen, your test passes. It's a very non-trivial, interesting problem in a relatively dull problem domain. Conclusion, if your work as a programmer is boring, you're doing it wrong (unless you're doing documentation - good grief, I'd kill for a way of automating that well!)

nostrademons 18y ago

Most great programmers take very well to unit tests. The way they became great was to assume their code is flawed and take steps to remedy that. Perhaps I'm being a little harsh, but I don't think Joel or his employees are really all that great. I mean, they're working on bugtracking software. Great programmers tend not to trade interesting problems for private offices and gigantic monitors (plus, they often can get jobs at places that offer them interesting problems, private offices, and gigantic monitors).

dasil003 18y ago
I don't think anyone ever accused geeks of really meaning sexy when they say sexy. More like, to each his own.
biohacker42 18y ago
I absolutely agree everybody, including the great ones, should write unit tests. I think the storm in a programmer's tea cup here is exactly how much unit testing do you need. Joel is accusing Kent Back and Robert Martin of wanting to write a whole testing framework for each and every little get and set method.
- nostrademons 18y ago
  That might apply to Robert Martin, but Kent Beck's on record as saying don't unit test getters and setters. "Test everything that could possibly break." So, strawman.
demallien 18y ago
No, really? FogBugz is written in a custom language created by the team for the application. Doesn't that sort of problem sound interesting enough to you? http://www.fogcreek.com/FogBugz/blog/category/Wasabi.aspx http://www.fogcreek.com/FogBugz/blog/category/Wasabi.aspx Honestly, the problem domain is not an indicator of the programming interest of a project. It's a general rule - if you are working in a boring problem domain, then you need to abstract out the boring part. Doing the abstraction is generally a very interesting task. Example: you have a GUI test rig for a set top box. Your task is to generate tests for the setup, which works by doing screen captures, and then comparing the screen capture with a pre-recorded image of the screen, to verify that error messages are correctly displayed. The problem is that the tests are brittle - if the designer changes the shade of a pixel anywhere on the screen, your test breaks and has to be regenerated - a very boring, repetitive and time-consuming task. So, change the system - right a screen scraper with some OCR, that can actually read the screen. Now the screen design can change, and as long as the message still appears somewhere on the screen, your test passes. It's a very non-trivial, interesting problem in a relatively dull problem domain. Conclusion, if your work as a programmer is boring, you're doing it wrong (unless you're doing documentation - good grief, I'd kill for a way of automating that well!)