I was just reading the transcript from the StackOverflow podcast nº 38. I came across it via a post from Jeremy Miller's blog, since I normally don't listen (actually I've never listened) to the StackOverlow podcast. Well it seems that there's been some comments regarding this particular podcast, since Jeff Attwood, of Coding Horror fame made some comments about not caring about quality. No doubt I disagree, but this particular post is my beef with some of the other things mentioned in this podcast.
I don't know how long Jeff or Joel have been programming, and to be frank I don't care. I do know how long I've been at it. I'm not going to bore you with the details, but suffice to say that it's been long enough and I've made some terrible mistakes and suffered the consequences while writing code and managing teams. We all live and learn, and one of the best ways to learn is from making mistakes. What I do care about however, (care maybe too strong of word, maybe "bothers me" is better) is people talking about things without proper knowledge.
Joel starts talking about Test Driven Development and 100% test coverage, which is not correct, and says:
...breaks 10% of your unit tests. Intentionally. Because you've changed the design of something... you've moved a menu, and now everything that relied on that menu being there... the menu is now elsewhere. And so all those tests now break.
Now I'm not even going to question what a menu position is doing in a unit test, but normally if you design your tests correctly, if something breaks it means it's broken. It means the change has caused a test to break, and that is a GOOD thing. If your tests are breaking when they shouldn't then your tests are maybe wrong. If you have to update the tests so they pass, then you've most likely changed the design, but you're explicitly acknowledging this.
He then goes on to talk more about unit tests:
make in maintaining those unit tests, keeping them up-to-date and keeping them passing, starts to become disproportional to the amount of benefit that you get out of them.
I'm curious how benefit is actually being measured here, not to say that the statement is an oxymoron if your tests serve their purpose.
The next part I'm perplexed with:
Last week I was listening to a podcast on Hanselminutes, with Robert Martin talking about the SOLID principles. (That's a real easy-to-Google term!) It's object-oriented design, and they're calling it agile design, which it really, really isn't. It's principles for how to design your classes, and how they should work. And, when I was listening to them, they all sounded to me like extremely bureaucratic programming that came from the mind of somebody that has not written a lot of code, frankly.
I'm all against acronyms, but please understand things before making statements about it. Nothing in SOLID is bureaucratic. And to say that people that apply SOLID have not written a lot of code, frankly, is just plain bullsh*t. I would say quite the contrary. I would say that people that have written a lot of code, know the side-effects of introducing changes, and how things can blow up in a million places, understand how code without tests can make your life miserable, how you worry about every other deployment you make because you don't know if the changes you made have broken the estimate calculations, or whether negative values can still be invoiced correctly, these are all things that make you appreciate more principles such as Single Responsibility or Open-Closed Principle.
Joel then goes on to talk about interfaces:
So, you've got some class, with 40 different little methods on it, and I'm only going to use six of them, so I should make an interface with those six things that I can use, and the class will implement that interface, and that's my contract with the class, that those are the only six things I'm going to use.
Is it only me that thinks this whole paragraph is nonsense? Have you completely missed the point of what an interface is Joel?
And then we come across the fileophobia:
Because what they're doing is spending an enormous amount of time writing a lot of extra code, a lot of verbiage, a lot of files, and a million little classes that don't do anything and thousands of little
I've said it a million teams: you'll have other sh*t to worry if you ever hit the NTFS file limit per directory.
Continuing:
This seems to be where a lot of the Object Oriented Design community went, and if anybody has any strong feelings about this, call in and tell me what you think--tell me if I'm totally off track here--but it seems to me like a lot of the Object Oriented Design principles you're hearing lately from people like Robert Martin and Kent Beck and so forth have gone off the deep end into architecture for architecture's sake.
Joel, I'd love to come on your show and tell you you're completely off track but I'm sure there's tons of other people more qualified than me that can do the same. This is not about architecture for architecture sakes. This is about not developing DemoWare applications that blow up every time you make a change and end up costing you more time in debugging and saving face with your customer than it would have if you had done things correctly from the start.
Jeff goes on to talk about his quality views, which sparked many of the posts:
... There was this quote from Frank Zappa: "Nobody gives a crap if we're great musicians." And it really is true. The people that appreciate Frank Zappa's
See I think that's where you're wrong Jeff. I do care if I'm a good coder and I care if those on my team are good coders. Not because I can walk into a room and say I'm a great coder, but because I know it pays off in the long run. And Joel/Jeff, you can only appreciate what you're talking about in your podcast if you've truly been coding for years.
[delphi]