Daniel asks a tailor to make him a suit. The tailor measures him and says “come back in three days.”
Daniel returns to try on the suit. “The left sleeve is too short” he complains. The tailor says “Raise your right shoulder and drop the left shoulder and you’ll look great.” Daniel does and, sure enough, the two sleeves meet properly at the wrist.
“The left pant leg is too long” cries Daniel. “No problem” says the tailor. “Lift your left hip and walk on your toes.” Sure enough, both pant legs break beautifully just above the ankles.
Daniel pays the tailor and ambles out to the street wearing his new suit. Another man approaches him and exclaims “Wow, great suit! Who’s your tailor?”. Daniel beams and points to the tailor shop. “He must be a terrific tailor,” says the man, “to be able to fit a cripple like you!”
I’m feeling like Daniel a lot lately. A number of us have been exploring implementation patterns for MVVM in complex, composite business applications. Just as we start getting somewhere promising … someone stops us short and says:
“You can’t do that because it doesn’t work in Blend.”
Let me be clear. I think Blend is grand and am learning to appreciate its power. I desperately want to facilitate the best possible UX. I know I can’t design the visuals worth a damn. I realize the people who can are not programmers and shouldn’t be asked to become programmers. I get it. I will do what it takes to make Blendable Views … including adjusting my posture.
But I’m not happy with show-stopper arguments like “It won’t work in Blend.” That may be the reality today but it need not be my future.
We should be honest about the consequences of saying “it won’t work in Blend”. Make no mistake, we’re twisting and contorting our architectures to satisfy the present state of the tooling.
Worse, we’re encouraging the tailor!
Sometimes I believe he thinks it’s a good thing for us to slouch and droop uncomfortably down the street. He actually thinks it’s a good thing to build View first, to inscribe code in the XAML, to block access to design-time APIs, to resort to Behaviors for simple programming tasks. He can’t believe I need to inject dependencies in the ViewModel … perhaps because that means he’d have to confront his own inadequacies.
I should get over it. Yet my hackles go up when I detect that smug, dismissive tone.
Hey, if you have to say “it won’t Blend” that’s an admission of failure. It means you’re not where you should be. I can deal with that. But stop sounding triumphant … as if what I want to do is stupid because it won’t Blend.
Yes, please make the tooling great for the designer. But the developer is the customer too … never forget that. The tooling should change to suit me … not the other way around.
Signed,
Frustrated-in-CA
2 comments:
I've been a Blend guy for about 3 years, but I'm pretty sympathetic to the architecture needs so I often end up creating views in isolation and the porting them into the project. On the down side, this is more work for me. On the up side, my needs don't get in the way of an otherwise clean architecture.
My questions would be this: Do you think there is or can be a "rule of thumb" for views that can be Blendable vs. ones that are just better off not worrying about it?
Lack of Blendability hasn't stopped Caliburn. :-)
Post a Comment