Friday, September 4, 2009

On Software Warning Labels

"The only demand I make of my reader is that he should devote his whole life to reading my works." – James Joyce to an interviewer.

I’ve been weighing in on Colin Blair’s blog recently about concerns I have about the RIA Services DomainDataSource (DDS) … concerns that apply equally to our own DevForce ObjectDataSource.

Colin’s blog on RIA Services is worth watching as Colin’s is a thoughtful voice. He likes RIA Services a lot … but not uncritically.

His post is a response to Jeff Handley’s twitter poll: “Do you consider the .NET RIA Services DomainDataSource to be ‘Data Access Logic’ in the UI?”.

Collin said “Yes”, then did the responsible thing and posted his reasons. That set in motion a small to-and-fro with Jeff who is maintaining and evolving the DDS for Microsoft.

What is going on there is some sensible thinking. There is no Microsoft bashing. I suppose some posturing is inevitable (at least where I am involved) but I believe that matters of real substance are poking through. We’re not just talking about “good design”; we’re talking about consequences.

Which brings me to something that has been gnawing at me since I fulminated against Drag-and-Drop back in August.

I received feedback, not only from Microsoft friends, that I had been uncharacteristically caustic and univocal in my opinion. I seemed to be sliding into the camp that would “shun” people who might use a DDS control; the camp that would “think those people are stupid.”

I recall too well my Berkeley days of smug “Us versus Them”-dom. Appears my capacity for self-righteousness is undiminished.

Timeout! I do not believe that the people who use the DDS are stupid. On the other hand, I do meet a great number of developers who are overworked, undertrained, and uncurious. They constitute the majority of developers … as they do in every profession.

I look in the mirror and can say the same of myself with respect to many topics. There isn’t time to understand the implications and nuances of everything I do. I can muster little interest in certain areas of software development. I simply trust that the technologies work and are appropriate … and I move on with my busy day. Our love of our craft is not equally distributed over the entirety of our domain.

So when I … or anyone … get amped up on a topic like DDS or drag-and-drop or ViewModel … what should I expect? Is this stuff really that bad for you? Are they clubbing baby seals?

No. It’s only software. We are not geniuses. We are not James Joyce and we certainly don’t deserve that kind of devotion.

I’m not backing off my “concern” about drag-and-drop. I’m not recanting my critique of the DDS (and our own ObjectDataSource). I just want to position myself differently … a bit more sympathetically … perhaps suggest an approach that may benefit the developer community and lower the temperature.

What if Microsoft (and IdeaBlade) were more upfront about the consequences and alternatives of some of these dubious controls and practices?

There is the sense among many that Microsoft doesn’t talk as openly as it should about technical debt.

Taking on technical debt can be a wise investment. I use the DataForm with auto-generation in my demos. Incredibly convenient. Could probably get away with it for some production screens that have only a few fields and don’t need much management; it will save tons of time that would be utterly wasted if I did a better job of customizing the user interaction … because nobody wants or needs “a better job”.

I incur that technical debt with gratitude. I choose what I’m doing.

There is no problem with the DataForm, or the DDS, or drag-and-drop. The problem is that many developers are insufficiently aware of the debt they are incurring. I use my credit card knowing that I’ve got it covered; too many developers are using the “credit card” thinking it’s free money.

Alan Stevens suggested something like the following in the Herding Code podcast I wrote about. He said it would be ok to do demos with drag-and-drop if the presenter stopped for a moment and said:

“This approach has utility under specific circumstances … but watch-out because it has costs too. I strongly recommend that you read up on it over here … to appreciate the limits of what I’m showing you … and to learn about alternative paths that may be more appropriate now or in the future.”

That speech is a responsibility we have as presenters at conferences.

Those of us who make and sell a product bear an additional responsibility, especially when we target the broad market of developers who, let’s face it, don’t try very hard to master the craft.

It isn’t enough to squirrel the discussion away in the corner of some blog. That’s the equivalent of hiding in the small print.

I think we (IdeaBlade, Microsoft) should put a warning sticker right on the control itself. Put it in the XAML doc. Teach Intellisense to show the “warning” hyperlink.

Smack me as a hypocrite if we neglect to put a warning on our own ObjectDataSource when we ship it.

2 comments:

David Nelson said...

Couldn't agree more, especially about the staggering silence regarding technical debt. Any financial advisor will tell you that a small amount of debt is ok, as long as you understand the benefits and risks and have a plan ahead of time for paying it back. Anything else is financial disaster waiting to happen. Too often (the vast majority of the time in fact) developers incur technical debt without even realizing they are doing it, much less with an understanding of the dangers or a plan to make up the cost.

Kyle Szklenski said...

And to further the point a bit, most developers don't even know to look for when they're incurring technical debt. It's a bit of a meta-programming question at that point - not template meta-programming, but the ability for the programmer to ask the question: Is what I'm doing stupid, or is it relatively maintainable? Is this going to bite me in the ass later? And not asking these questions can end up causing a failure on a grand scale later on down the road.

I think this links in tightly with Robert Martin's ideas on professionalism. We should in general be aware of the code we are writing and understand whether or not it fits in with our design and principles (if any), and we should move from the mentality of, "Just get it done" to, "Get it done right." But since, as Ward rightly points out, so many devs are lazy, uninspired, and uncreative, we end up with solutions that are little more than POCs.