Just Stop. Please.
Wednesday, October 07, 2009 -
I’ve tried to stay out of the whole “Spolsky Thing” of late as it seems like it’s spectacle for spectacle’s sake. That seems to be Spolsky’s thing and it’s one of those things you sort of ignore most of the time.
But he just keeps going – sort of like your parents revving your kids before bed while you watch, knowing there’s nothing you can do – he’s just going to do it anyway. It’s weird how that works – my family and my wife’s – they love to rev the kids up at bedtime for some reason and then I spend the next 2 hours trying to get them to go to sleep. It’s not fun, but to my dad, who’s upstairs reading a book (complaining about all the noise coming from downstairs) I just “worry too much – let them be kids!”
Sure. I’ll do that. And I’ll pay the price when they wake up tired the next morning and cry through breakfast while you remind me how discipline was handled when you were a boy.
Anyway - as I read through Joel’s latest train wreck, this clip of Jon Stewart on Crossfire popped right in my head…
Joel – it’s not funny any more. You’re hurting the industry, not helping. You’re acting like my dad did – revving up the industry and spewing old-time wisdom that does not apply anymore.
Here’s some tea – time for bed. Please stop.
At that point I decided Joel wasn't terribly relevent to me or my industry. Everything Joel says has to be viewed through a filter that a) only software that is for sale matters, b) only his view of how the development process works is correct.
The thing that saddened me in his latest post was once again he takes a swipe at unit testing, guess his code works the first time and he doesn't have to worry about changes mucking it up... sigh.
The gist of the post is to keep it simple and ship often. That's not new, and it's hard to disagree with that.
It's not just the keep it simple stuff. Take a look at this post on IoC containers: http://tinyurl.com/lame-post-on-IoC and scroll down until you see Spolsky's answer. It really is the coding equivalent of "Hey, you kids stay off my lawn". It celebrates ignorance and assumes that the best way to write code was perfected about 10 years ago.
I used to think Joel on Software was required reading, now I just think of it as a voice from the past.
He's done a ton of good for software development and developers over the years and though he's slowed down and makes some quick judgements at time he does continue to contribute.
Rob, I think it's very unfair to compare Joel to those douche bags (not sure you spell that) on Crossfire or the Bush administration. I think your just frustrated with some of his opinions and that he speaks into a megaphone. This post is more than a bit of a stretch.
I'm not going to try to tell you that you should agree with Spolsky. Far be it, in fact, because I happen to agree that some of his stuff is a little over the top. But I am firmly of the opinion that if we can't read his stuff and make intelligent decisions about whether any of it applies in our lives, then the primary problem lies with us.
Additionally, if you browse his writing over time, a great deal of it works because it's always been just a little bit inflammatory. It rubs a nerve or pokes at a stereotype, and it gets us to think about the issue and start talking about it. If the end result of Joel rubbing some salt on the wounds of our industry is that we educate a few more people about IOC or software development best practices, then I'm not sure it's all that bad.
Of course, each of us is more than welcome to simply stop listening. No audience == no problem, right?
I hope the TTD advocates take their own advice as they get older and new methods and techniques displace TDD.
I think Joel should continue to post things like his 'duct-tape' post and all 'elite' programmers should have to read it. Seriously.
People who 'worry about the state of the industry' seem to me to be people who are hurting the state of the industry.
Agreed! Joel may well be successful but I want to feel pride in what I create.
If I was an accountant, that pride would stem from the bottom line; but I am a programmer and hence that pride is in the code I write.
Kindness,
Dan
I think the point of the article is that a) anyone who cares about what they do wants to do things the "right" way and b) doing it the right way gets in the way of shipping. Strive for the golden mean!
Oh yeah, lets not forget about the secret that the "right" way isn't defined and never will be because things change so much and once we figure out the right way someone is going to come along with something cooler, faster, easier. Damn you Ruby! Damn you Python! And of course, damn you C# . . . you are so much safer than C but C is the right way . . . it's the only way . . . and Joel said if I don't know C I am useless!
Much <3 for this post.
"Like it or not – the future is calling and we need to advance."
Yeah, that's scary. It's new, therefore it's good. Continuous change isn't necessarily continuous improvement. We really need an entire industry full of brittle tests. That will make things SO much better than they are now.
and you should return result codes in your methods.
They write "smackdown" blogs. It's us versus them. The good guys versus the bad. Black and white. No gray. Gray is boring. Nobody reads nuanced gray articles. It's all about the page view.
Joel knows that the real world is a lot more nuanced (his blog is featured blog at ACM Queue, after all), but he apparently doesn't care about nuances, because nuances bore people. Joel and Jeff can't just say "a good solution solved now is better than a perfect solution that's never implemented". Instead, they have to turn it into "Shipping is the thing that matters".
Joel and Jeff are the Jerry Springer and Maury Povich of tech blogging. They get page views by generating a reaction. Nuances are ignored, because nuances put people to sleep.
So they write and say absolute nonsense. Quantity over quality, says Jeff (I'd hate to be on a life machine in the hospital whose software was written by Jeff). Solid principles = waste of time. Shipping date is more important than testing (I sure hope that Boeing does a couple of rounds of testing the software in the new planes before putting them into the skies).
And what world does Joel live in where the biggest problem is overengineering? I'm sure there are, perhaps at MIT, people who look so long for the perfect architecture that they never actually create a real product, other than for themselves.
But the real world is mostly the opposite. I have seen time and time again, so many accidental architectures. Bad method names, bad class names, long methods, and rigid structures that require gigantic hacks, because the architecture no longer reflects the real business domain. And those piles of dung were created by duck tape coders.
But Joel didn't mention that. That would make the blog nuanced and he can't have that.
I think if you ignore Joel's rhetoric and actually dig down deep into what he's saying, I believe he's arguing against Over Engineering. While I don't agree with the "A shipped incomplete product is better than a non-shipped product" philosphy, but I do agree with the fact that a simple solution will likely be better than the "right" (re: complicated) solution.
Sometimes you just need to throw a value in a config file, but give a developer some leeway, and before you know it you've got a complicated rules engine on your hand.
In that respect, he has value (as a contrary view point), because you have to remember, in this niche he's actually in the minority. "Bad" developers (or 5:01 developers or whatever we're calling them these days) don't read his work.
Let's put it this way, if it wasn't Joel who wrote the Duct Tape blog, and we replaced the words "Duct Tape" with practically any other set of words, would anyone really have cared?
http://codezest.com/archive/2009/10/07/worst-development-blog-post-ever-ndash-by-joel-spolsky.aspx
and you should return result codes in your methods.
Wow, Unreal. It just gets better and better. Lets listen to such sound advice as we hack together our applications. Everyone, Joel's driving the bus. Run for your lives.
Lots of software projects fail and personal experiences, though valuable, fuel the vehemence with which points of contention are debated; this project failed because it turned into a tarball; this project failed because the designers were too inflexible and unrealistic in their demands. In this sort of forum people almost feel pressure to align to a side even when the divide is not so black or white nor so wide.
The pragmatist might argue that taking the middle ground is what they are doing, whereas the believer of a particular practice(s) might claim the middle ground or correct approach because the benefits are so vast and apparent.
My personal take would be for everyone to keep saying what you are saying but perhaps spend 5 minutes to work out where you do agree and then say where your views intersect and benefits could be arise. Once you start preaching to your own choir or deriding the other side (and hey you’ve done with proper discussion now because you’ve done that all before and they just won’t listen!) you’ll find that the real moderates (floating voters) give up reading (or voting) and just gets on with things their own way regardless of what you might hope for them.
I saw much validity to his post, but then again I am just a lowly corporate development manager and not a figure head of the industry as some of you are. I knew exactly what he was talking about when he said that some times you just don't have time for unit tests. It is true, when the vp/pres of the company comes to you and says I need X yesterday well you hack something together for them to use and hope that you can come back to it later to refactor it. Some times the corporate world could care less that it is a little buggy as long as the primary functionality is served. Bugs can always be fixed later but that TPS report that they have lived perfectly happy without until today will absolutely make or break the company.
I may be out of place in saying this, but I believe there may be a disconnect between the developers who are writing commercial software products and the developers who are writing proprietary software custom to business practices. When you are writing a product that will be generic in terms that many varying businesses/consumers can use it you have the time, and if you don't you should make the time, to unit test everything, refactor where you can refactor, develop very clean and maintainable code, etc. When you are responding to immediate internal customer needs because some department just signed up with vendor xyz and they need some new functionality that will fulfill a requirement for said vendor, well you don't always have time for these niceties. It is all fine and dandy to say what you should do in theory, but practice is often quite different and sometimes adverse to theory.
Then again, as I said, we all read things and apply them relatively to our perspective. So in my perspective of being a SMB development manager I realize the time constraints that can be imposed by the executives of a company that don't understand the level of work that goes into development. It is my job to balance the amount of time and effort required to deliver and the determine the level of expectations of business unit. If they are rushing a project but they are acceptable to the idea that it could be buggy, then I work with my developers and I begin whipping out my duct tape. If they are rushing a project and it has to be bug free (or as bug free as possible) then I have to work with the business unit and explain to them their expectations are unrealistic and this is what I can deliver in x time and I can meet or exceed their expectations in y time, then give them the choice.
I will agree with the sentiment that talented programmers can become distracted with fascinating side-problems, but the solution is not to dumb down your development staff. The smart ones can produce valuable software if you are able to engage them and focus them on the demands of the project. Don't expect developers to manage themselves - mastering one wickedly difficult profession is enough for one person.