It sucks to have your life's work strawmanned like this by pop programmer podcast banter. I hope Joel addresses it professionally.
XP/Agile/TDD (like any movement) is filled with rabid fanboys who misapply the principles and try to ram them down everyone's throat, but it's rarely the case that the inventors of popular methodologies are filled with the same blind zeal. After all, their ideas were originally informed by first-hand experience.
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.
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).
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
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!)
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."
I think that the whole movement idea of software development is pretty weak. If Joel can write down a life's work in a couple of sentences, then there is definitely not much to it in the first place.
This is a mud-slinging contest over a subject with dubious value to software development in general. it might just be me, but whenever I hear TDD/Agile/XP my heart is made sad by all the crap out there in software development.
I want to design and write good programs. Now of course, that might include testing the software for errors in an automated way. I would think that most people would agree on testing as a needed tool for most software developed today and in the future.
But there is a long way from testing a piece of software to the extreme views. And there, we see all kinds of disagreement. Hence the mud slinging. This is a bad bragging contest. And it is just going to take up your time. You won't gain anything from it unless you take stance. Here is mine:
XP: Crap. Kill it. It completely disagrees with the way I can work soundly on a project. But take the code review part with you.
TDD: Crap. Kill it. It completely disagrees with the way I develop software. Sorry. I am not going to change. And I am not becoming extinct because of my view either.
Agile: Take the old ideas of iterative development and short development cycles. Take the good idea of keeping the development methodology simple. Take the good idea of providing transparency of the development status. Kill everything else.
Now your stance might be different from mine. But we will gain little by discussing the finer points.
> If Joel can write down a life's work in a couple of sentences, then there is definitely not much to it in the first place.
You seem to presume that Joel has written down Beck's life's work in a couple of sentences. The whole point of Kent's post is to refute this presumption.
I'm sure you agree that Joel did not write down his own life's work in articulating twelve simple yes or no questions about software development practices. There's more to Joel's own experience than those twelve questions, and there's more to Kent's life's work than Joel's off-hand remarks.
I'll close my rebuttal to your comment by pointing out that you have just summarized your own stance on software development with some amazingly superficial and non-actionable prescriptions.
But I would never presume that these prescriptions, right or wrong, would summarize your life's work either. Nor would I jump to hasty conclusions about your experience based on whether I agree or disagree with your stance on TDD.
It's interesting how this "little" detail always seems to get overlooked by the XP zealots. A great book which I think everyone should read before jumping onto the XP/TDD/Scrum/Agile/etc bandwagon is called "Extreme Programming Refactored: The Case Against XP". It highlights the failed C3 project and offers some compelling arguments.
Don't conflate having a project canceled with having it fail. Successful projects get canceled for a variety of reasons, and some failed projects never get canceled.
Never heard of this guy before, but considering that he just wrote 3 paragraphs eloquently saying "Joel is an idiot" without saying anything about how they disagree makes me think quite little of him. Ad hominem attacks are rhetoric - meant to influence, not inform.
Kent Beck is one of the original Smalltalkers....way back.
If I recall correctly, Kent won the "competition" for the best answer to "How many lines of code does your app have?". His answer (best recollection) was "lots, but with some effort I was able to remove most of them".
Kent and his circle of friends were refactoring before there was a word for it; when XP and all its many ancillary methods were just called "best practices".
Not sure I've ever seen him publish something like this before. This is part of the problem with dismissing people over the Internet without really knowing their backgrounds. It is very easy to make a fool of yourself.
I think he treated Joel fairly. He was complimentary to Joel's efforts in writing but simply told him that he doesn't really know him and should be more careful with his opinions.
Joel dragged him into this by name. Clearly he thinks Joel is attributing ideas to him that he doesn't hold. Therefore it's not a matter of disagreement--he may well fully agree with Joel's thesis--it's the demonization of his work by misrepresentation. In that light his response seems measured and appropriate.
Let's assume that Joel is neither stupid nor malicious. Therefore he is having problems that presumably others are having. In this case it is useful to actually set out the nature of Joel's error, rather than simply saying "Joel is a dolt". Non-malicious criticism can often be helpful in letting you explore why people misunderstand you.
Of course my assumptions could be wrong - he could believe that Joel is being malicious.
2. "Joel is a dolt" - Neither on the lines nor between them have I seen this in Kent's post.
1. "Joel is neither stupid nor malicious" - Stupid + Malicious != AllThereCouldEverBe... Pompous and AttentionCraving are missing for example. Others are too...
0. I _partly_ dislike both stands on software dev. methodology (Kent's and Joel's) so don't take this a fanboysm. I respect Kent's life work more though.
Kent Beck is the creator of Extreme Programming, one of the fathers of Test-Driven-Design and a bunch of other agile practices. Quite well known amongst most programmer circles.
I totally disagree with this. First of all, Joel is an idiot. I think this is fact. I think we all know this, and those of us who don't know yet will find out sooner or later.
More importantly, this whole "how to disagree" thing is about extending courtesy. Joel Spolsky dissing Kent Beck is like a four-year-old piddling on a real pioneer's foot. Beck did Spolsky more courtesy than Spolsky deserved just by responding at all.
A lot of people on the Internet don't seem to realize that when one person disrupts another's day with attacks or what have you, that other person might have other things going on that are more important to them than responding to the Internet crap, or which require so much time that no time remains for responding to Internet crap.
The subtext in "How To Disagree" is "you have to show me respect if you want to debate something with me." That's perfectly reasonable. But starting a fight with somebody out of the blue isn't about rational, adult disagreement.
Besides, dude, he's responding to something somebody said. It's not his fault you know about it. He didn't publicize it to you, and for you to judge him based on his failure to provide you with context, when it's you going to his site, that makes no sense at all. Be mad at Hacker News for linking to something you don't know about, or be mad at yourself for clicking links automatically and wasting your own time. I mean there's no logic in holding that against Beck at all.
But what happens when you stick inventor of popular methodology A against inventor of popular methodology B? Is the disagreement blind zeal or professional opinions originally informed by first-hand experience?
Or is the whole thing just like duct-taping buttered toast to the back of a cat and then pushing it off a high surface?
(Toast always ends buttered side down. Cats always land feet first. Thus, if either lands, the universe implodes. I don't even want to consider what happens if the push-cat-off-ledge-or-not decision is made based on whether a radioactive isotope decays or not.)
Joel pushed no "methodology" in that sense at all. What I see is Kent Beck, who pushes a methodology which has taken up a religious like following in "IT" or corporate developer circles. Joel just ships software, and judges things in terms of commercial success in the market place.
I am not really a fan of Joel's advice, but if I look at the relative successes, I would have to favour Joel (also, listening to him speak now, on that podcast, indicates that in his "old age" he really has less advice, he has mellowed out and realised that there is a lot more variables at play).
I think any methodology really boils down to: have good people any they will make something work. That is the only common thread in successful projects/teams/products that I have seen (and others). Its 80% people, perhaps more. Therefore any other tweaking of things are really like premature optimisation.
And I like brain candy. Its sweet in a bitter world ;)
I think Paul Bucheit said : "Limited life experience + overgeneralisation == advice".
XP/Agile/TDD (like any movement) is filled with rabid fanboys who misapply the principles and try to ram them down everyone's throat, but it's rarely the case that the inventors of popular methodologies are filled with the same blind zeal. After all, their ideas were originally informed by first-hand experience.