Saturday, February 02, 2008 -
What could be more boring - a blog about blogging :). Usually when I read a post title which suggests "Blog Like Me, Today!" or "I'm a Blog and So Can You!" I skip over it and move on. I'm sure there are some neat thoughts out there that I can learn from, but usually the posts I read are full of platitudes and "you can do it too" kind of thing which all seems so... Self-Helpy.
Today I read a post by Jacob Proffitt whose blog I'd never read before. How had I never read this guy's stuff? Where has he been? How can I stalk him?
As I started to read, I kept thinking to myself "this...THIS is HOW YOU DO IT!" His post moved me so much that it inspired me to write up my weekend Off Topic post, which, it turns out, is sort of on-topic.
Rule Number One: Don't Blog About Blogging
Link lists, snotty thoughts about "tricks to get links", etc. can be entertaining at times, but as far as I'm concerned it's like having a beer with a picture of your friend - you're just talking to yourself. There are some good posts out there on the subject, however. One that comes to mind is Jeremy Miller's post (Should I Blog?) just a few weeks back about why it's important to have a blog. I liked what he had to say since I think it's important for everyone to get their thoughts out there - especially useful thoughts:
So for Jeremy I'll make an exception - this was a good read. You might be asking yourself if I'm breaking my rule here - but I'm not since this paragraph is blogging about blogging about blogging. OK I spose that was a bit weak. I broke the rules because I like Rule Number Two a lot better...
Rule Number Two: Break The Rules
Like any group, we invent rules and creeds to live by which change over time as we get bored or technology changes. This isn't new stuff (which makes that sentence boring). What isn't boring is that I think I read the perfect blog post today by Jacob Proffitt (or as close to perfect as possible - it was just a smidge too long).
It was:
Despite the title (TDD Proven Effective! Or is it?), the article addresses what is a failing in all of us - searching for confirmation of what we believe in what is supposed to be a critical study (emphasis mine):
One of the things I worry about when I see things supporting the latest and greatest software development practices, however, is a strong tendency towards confirmation bias-of looking for confirmation of current theories and overlooking counter-indicators.
Jacob goes on to dissect a study on TDD ("On the Effectiveness of Test-first Approach to Programming", Hakan Erdogmus, 2005 (?)) and systematically dissects the statistical data that the report produced:
Clever academics have long used abstracts to support the conclusions they desire and this seems to be one such. If you're careful (as these authors are) you can even do it without actually lying...
<snip>
Here are some equally true statements based on the data (pages 9 and 10 of the report if you want to read along with me in your book):
- The control group (non-TDD or "Test Last") had higher quality in every dimension-they had higher floor, ceiling, mean, and median quality.
- The control group produced higher quality with consistently fewer tests.
- Quality was better correlated to number of tests for the TDD group (an interesting point of differentiation that I'm not sure the authors caught).
- The control group's productivity was highly predictable as a function of number of tests and had a stronger correlation than the TDD group.
So TDD's relationship to quality is problematic at best. Its relationship to productivity is more interesting. I hope there's a follow-up study because the productivity numbers simply don't add up very well to me.
If you want to read more, head on over to Jacob's post and see what he has to say. Note that he isn't necessarily debunking TDD or suggesting that it's not A Good Thing. He's simply calling into question our propensity to embrace the next shiney thing, versus critically thinking about it.
Rule Number Three: Research, Re-ead, And Don't Make Me Think
I love to read CodingHorror, even though I disagree with many of the "Jerry Springer" posts he comes up with. It's not the subject, it's the mechanics - I wish more people could do what Jeff does so simply:
When you're done writing, make sure to reread your post to make sure you haven't said something dumb. I fail at this a lot too :). Most important of these items, however, is to not listen to lame advice on how to write a blog. You have a voice and it should be your own. There are no rules to writing anything, which brings me to my closing point...
Rule Number Three: Never Post Rules, For Anything, Ever
It's pretty easy to see things as "it's either this way, or it's wrong" and every time I read a post like that, Obi Wan's words sound in my ears:
"Only the Sith deal in absolutes..."
There are lots of "Hot Or Not" lists out there that dictate what's "cool" and the things you should do. Google is usually unkind to those lists as time goes by (unless you're trying to find places to Frost Grind - thank goodness for WoWWiki). If you're not a blogger and you want to take Jeremy's advice and start a blog (and you should!) - please do me a favor and omit the "Links for today" kind of thing, and "My List Of Must-Have Stuff" (unless you're this guy or SubSonic is on your list :).
P.S.: The irony in this post is intentional - I really do loathe blogging about blogging. But Jacob's post was so well written I wanted to call some attention to it, and him. Absolutely stellar writer.
Regarding all the passing of strings around in interfaces like INotifyPropertyChanged, and just saw it again in Scott H's MVC video and again I find myself wondering why we are passing around strings of property names in C# 3.0 and .NET 3.5?
I contacted Scott GU who refered me to the compiler team about a year ago, and proposed using something like nameof(Class.Property), this simply returns the name of a property as a string, they said they were looking at infoof() somthing similar but does more.
Maybe you could poke around and find out why we are still passing around strings of property and method names, some compiler issue or something else, seems like it would allow the compiler to catch many typos if we could break this practice. It also seems like the MVC, DLinq and other teams would be screaming for this capability.
Thanks.