Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Joel Spolksy is wrong about my work" - Kent Beck

threeriversinstitute.org

Post reply on HN
Print view View original

91–100 of 100 posts

Re: "Joel Spolksy is wrong about my work" - Kent Beck

#91

Post by trapper »

swombat wrote: post #54
trapper wrote: post #43

Earlier quoted context omitted.

There are two schools of thought in programming I have seen. 1. Design it right the first time, tests and all. 2. Build a throwaway, no tests, little refactoring as you quickly iterate Programmers who fall into category 1 in my experience mistakenly believe that they understand the requirements of the software they are writing. Category 2 programmers tend to be ones who actually deal with users/real world, and know t…

You're assuming that you'll get something in front of users more quickly without writing tests. I find that's not the case in my experience.

Also, to get something in front of users, you rarely need to be doing anything remotely complex. It's not like writing a disk based inverted index or a filesystem. When writing tools like those, obviously testing is important.

Re: "Joel Spolksy is wrong about my work" - Kent Beck

#92

Post by mattm »

fizx wrote: post #33
swombat wrote: post #30

Earlier quoted context omitted.

'Fraid not, axod. It's when you're quickly iterating and changing lots of stuff that quality unit testing helps you the most. Let's look at 2 possible scenarios: 1) You don't bother testing much. You make lots of changes, iterate quickly. Before the changes, you have code that, let's say, you know works. After the changes, you know there's probably bugs, but you don't know where. 2) You test fairly thoroughly. You ma…

I'll chime in from recent experience. I had to pull a dependency in my project because it was causing heisenbugs that I couldn't root out. Without tests, I wouldn't have known. With tests, it took 2 hours to replace (diff -200 +250), and I'm confident the library still works. Without tests, it would have taken several more, at least.

How long did it take to write the tests?

Re: "Joel Spolksy is wrong about my work" - Kent Beck

#93

Post by giles_bowkett »

andreyf wrote: post #16
dasil003 wrote: post #2

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 b…

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. See How to Disagree, by PG: http://www.paulgraham.com/disagree.html

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.

Re: "Joel Spolksy is wrong about my work" - Kent Beck

#94

Post by nostrademons »

biohacker42 wrote: post #84
nostrademons wrote: post #78

Earlier quoted context omitted.

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…

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.

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.

Re: "Joel Spolksy is wrong about my work" - Kent Beck

#95

Post by nostrademons »

projectileboy wrote: post #86
pkaler wrote: post #82

What has Kent Beck shipped? Follow the advice of people that have shipped code. That is what I took from the Stack Overflow podcast. Seriously, what has Kent Beck shipped? The Chrysler Compensation program is always brought up. But, I understand that the project was cancelled. I'm not trying to troll here. I would have greater confidence in Kent Beck's argument if I knew what he was actually capable of shipping.

JUnit, for one thing.

Eclipse as well.

Re: "Joel Spolksy is wrong about my work" - Kent Beck

#96

Post by hello_moto »

It's quite interesting to see two kinds of technical guys arguing against each other. On one side, we have the product guy, on the other, we've got the consulting guy.

You've got Joel, Jeff, Paul Bucheit on the product side saying that "Yes, automated testing and some of the OOP principles are great, but let's not go as far as Uncle Bob"

Check out the SOLID principles. Some of the principles are alright, but when Uncle Bob explained that Rectangle class thing, I don't know what to say other than I just changed my mind leaning toward not to buy his "Clean Code" book.

On the other side, you've got Kent Beck, GoF, Uncle Bob, Martin Fowler, etc. (and possibly Gilles Bowkett). They're what you would consider "war-proven": they've done numerous "IT projects", leading a team of corporate developers, probably making a website for clients, and etc.

I don't mean to be rude (and perhaps this is an overgeneralisation), but I haven't heard any software product made by the consulting group. Yes, they wrote code, but the code is based on requirements given by some clients that:

1) Change the requirements frequently 2) Keep cutting costs 3) Ask for more 4) Cut more time

There's a huge different between writing code for commercial software that you steer versus writing code driven by someone else who knows almost nothing about software development but knows a lot how to save money.

Would you TDD-ed your UI code?

If you wrote API, yes, I can understand you do heavy unit-tests.

A side note for having your own unit-test framework: 1) Developers shouldn't write them 2) Developers should provide minimal to enough unit-tests 3) Go hire your own test team to do the rest

Developers aren't meant to be full-time testers. Testers aren't mean to be a full-time developers.

What I'd like to see is a team like this: 1) Joel becomes the product manager 2) Paul Bucheit becomes the software architect 3) Jeff, Kent Beck and Martin Fowler do the coding 4) Robert Martin and those infested TDD people can build a full-blown suite of unit-test frameworks, acceptance test and etc.

Microsoft has a category for the people in (4), it is "SDET". For those of you who think developers must write a comprehensive TDD (not just a minimum or "just to pass"), here's a challenge to you: why don't you try and be SDET. You'll see some of the serious full-blown test code, black-box, UI test code, UI automation and a serious CI process. I'm sure the experience will make your TDD and unit-test code look pale in comparison.

Google seems going to that (MS) direction slowly.

Re: "Joel Spolksy is wrong about my work" - Kent Beck

#97

Post by demallien »

nostrademons wrote: post #78
biohacker42 wrote: post #63

Earlier quoted context omitted.

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. (J…

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…

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!)

Re: "Joel Spolksy is wrong about my work" - Kent Beck

#99

Post by mrandle »

trapper wrote: post #88
swombat wrote: post #54

Earlier quoted context omitted.

You're assuming that you'll get something in front of users more quickly without writing tests. I find that's not the case in my experience.

I'd love to see some research on this. I would hypothesize that there is a point of problem complexity where the lack of tests becomes a negative for productivity.

I second this suggestion (and agree with the hypothesis, although its probably not just a function of raw problem complexity, other variables must come into play)

Hasnt it been done already? Couldnt find anything I would class as 'scientific' with a quick google search. Would be a good thesis for someone.

Re: "Joel Spolksy is wrong about my work" - Kent Beck

#100

Post by fizx »

mattm wrote: post #92
fizx wrote: post #33

Earlier quoted context omitted.

I'll chime in from recent experience. I had to pull a dependency in my project because it was causing heisenbugs that I couldn't root out. Without tests, I wouldn't have known. With tests, it took 2 hours to replace (diff -200 +250), and I'm confident the library still works. Without tests, it would have taken several more, at least.

How long did it take to write the tests?

I write tests as I develop, and they take the place of going to the browser or a repl and poking around at my work. In some sense, testing takes zero or negative net time. It would be hard to measure gross time, because it occurs in such small increments.
Post reply on HN