Drag & Drop Debate on Herding Code

I just listened to a Herding Code podcast in which “Drag and Drop” development was attacked and defended (thanks to Tim Heuer for the pointer).  That wasn’t the offical topic but there was a golden 10 minutes on this subject about 35 minutes into the program.

I don’t believe they do transcripts of Herding Code podcasts. With apologies to those guys, I transcribed those 10 minutes for your delectation. Go hear the whole thing.

Speakers

The guests (and bio extracts from their web sites) are

G. Andrew Duthie (GAD): ”G. Andrew Duthie, aka .net DEvHammer, is the Developer Evangelist for Microsoft’s Mid-Atlantic States district, where he provides support and education for developers working with the .net development platform.”

Alan Stevens (AS): “Alan Stevens is a ... software artisan living in Knoxville, TN. Alan is an Open Space Technology facilitator. Alan is a Microsoft Most Valuable Professional (MVP) in C#. Alan is a member of ASP Insiders”

The Exchange

GAD: Alan likes to beat me up on Drag and Drop (d&d) development … and I’ll be the first to say that I’ve done my fair share of d&d demos and some of the code I write I use d&d and I’m not ashamed to admit it.

AS: Will you please promise here now never to do that again!

GAD: No, I won’t actually. Here’s my take on the whole drag and drop thing. … [I enjoy] the concept of “Technical Debt” and d&d is an example of something that can lead to Technical Debt and I’m perfectly willing to accept some of that Technical Debt and sometimes the reality is that I pay for it later …

AS: No!, No. _I_ pay for it later. You go on and do a demo of something else that will be released next year. And I have to clean up behind these poor slobs that all they know about .NET development is what you showed them in the PowerPoint deck and the d&d demo … and they don’t have a _clue_ what’s going on. And it’s just _garbage_. I walk into these steaming piles of poo that are called “business applications” and have to clean this mess up. You just aren’t doing anybody any good by making them ignorant.

Unknown_1: So what you’re saying, Alan, is that your upset that MS is providing you with a job.

AS: I would say that there are other skills that my clients could exploit

GAD: So let me give you my take on this. This is a place where I think you and I disagree pretty vehemently.

AS: Yeah, you’re wrong!

GAD: My take is that if we are out there doing demos of any rapid application development feature that has the potential for accruing technical debt that we probably ought to be saying that. … So … If all that we’re doing is teaching people how to … spin the knobs … we’re not teaching them enough, but at the same time I think we have an obligation … to show off those new features. I’d love to see us do a better job of giving the caveats and letting people know that “this demo that I’m building here is not based on any patterns so … you don’t want to … emulate this.” … Pete Brown says “as I’m building this keep in mind that this is demo code. Ideally, when you’re moving into an application, I show you a pattern you can use but right now, this code is really to demonstrate this feature and I don’t want to clutter it up with the conversation around the pattern _yet_. ” Eventually he gets to MVVM …

AS: I think caveats of “here there be dragons” are fantastic. I just haven’t seen them yet at a launch event. It seems like there is a fear of criticizing the product, that it’s not super easy to use .. if there’s a trend toward doing that [caveats], I’m 100% for that because that’s what people need to get in their heads, this is not a model of how you should do your real world development. I’m trying to show you features.

The other aspect of d&d demos that gets under my skin is “I didn’t write a single line of code”. What the hell is wrong with writing code? … Why should dragging something from the toolbox be a better experience than actually writing it in the editor?

GAD: I’ll give you an example. I don’t ever want to have to write a login dialog again in my life. I don’t want to have to write that code. So when we brought out ASP.NET v. 2 and VS 2005 and you could just drag a login control and if you had the membership service provider set up, you were good to go. That’s a big win to me and I don’t see any downside to that particularly given that if you have to change out your membership provider … you don’t have to change anything.

AS: … I agree that I don’t want to write plumbing code every time. But I don’t mind writing code to re-use a component

GAD: So, ultimately, if you have that code somewhere and you can drag it into the code, are you guilty of d&d development too?

AS (incredulous): Why would I ever do that?

GAD (frustrated): So do you object to controls?

AS: I’m leaving visual designers out of this. I’m talking about _non-visual_ components where you create a visual designer for no reason. Why would I drag that code out of somewhere? Why wouldn’t I configure my IoC container to inject that component and then just use it in my code? Intellisense is a wonderful thing. I don’t need some graphic on the screen; I don’t need to reach for the mouse to add these things into my application.

GAD: I think you’re getting into a philosophical disagreement …

AS: No, no, no! You are still wrong.

GAD: … Trying to make a “one size fits all” statement about how development should be done, I don’t see that working in our industry. There are many different ways that you can successfully build software …

AS: Let me leave it at this. I’ve never seen it work. I’ve never seen it work in a long term, maintainable sense. Only in the initial release. And, honestly, the initial release is not where the cost of any application lies. It is always down the line, in extending and maintaining the application. …

Kevin Dente: … Not only do I never see it working, I never use it in my work. And whenever I hear Microsoft say “We have resource constraints so we have to make judgment calls” well when tons of effort is poured into those things for which I think have no value and aren’t put into places which have a lot of value, I get very frustrated.

“And the Winner Is …”

My heart is with Andrew (GAD). I do a lot of demos myself both of Microsoft technology and of our product. I appreciate the challenge of demonstrating features such that they can be seen without scaffolding … scaffolding that proper patterns may introduce.  I love IoC and wouldn’t develop without it. I confess I can’t do a demo with it … today … and still reach my audience.

But my head says Alan (AS) is dead-on right.

This is not a “philosophical disagreement”. The drag-and-drop approach in which you populate your views with non-visual controls is always wrong outside of a demo. There is no “choice” here. The d&d proponents are “flat earthers”, pretending that this isn’t a settled fact.

How can I be so sure? Let me offer the same reason that others brought up. If these components had a legitimate place in my application, I would use them. If I would always yank them out, they have no good reason to be there in the first place. And if it’s not good enough for my code, why would it be good enough for my customer’s code?

Think about this. When you never see these controls in good code and you often see them in bad code, what must you conclude?

Note that AS and GAD do not disagree about “good” and “bad” code in this regard. It isn’t as if reasonable minds differ on this. GAD never says that coding with these components is ever good. He admits straight-up that their use incurs “technical debt”.

And by the way, GAD, these components don’t “have the potential to incur technical debt”. There is no “potential”. They are always technical debt. The only question is when you pay for it.

All of us understand that we incur “technical debt”. It’s an essential fact of development. But we don’t take on debt frivolously. And these d&d components are frivolous choices.

We know from our own experience that it is neither easier nor faster to use these components than to do it right the first time. Once you know the proper way, d&d saves you zero effort. I say this assuming that you employ some amount of decent structure the first time … that your app is not a total hack job from day one to first release. Would any of us do that?

No, the only place for d&d non-visual components is in demos. MS is properly faulted for failing to warn people. They should be faulted for wasting resources on these components and their visual designers … resources that could otherwise be deployed to improve the platform and the experience.

Today, my poster child for waste happens to be the RIA Services DomainDataSource which mimics the comparably atrocious ASP ObjectDataSource.

And guess what? Because Microsoft is doing it, we at IdeaBlade feel that we have to do it too. That’s right … we’re forced to write our own Silverlight ObjectDataSource just so we won’t lose customers to a Microsoft demo. What a frigging waste all around.

Our customers suffer doubly. They are encouraged to develop poorly and they are deprived of means and guidance to develop well. What a shame.