Of Tailors and Tooling (rant)

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.



This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

7 Responses to Of Tailors and Tooling (rant)

  1. Billy Hollis says:

    My usual contrarian view: We’re spending way too much time worrying about factoring things so that designers can make them pretty (which has limited value) and far too little time collaborating with the subset of designers who understand interaction design trying to make users happier and more productive.

    Changing cosmetics late in the cycle of development is easy, or at least it is in an app that’s properly designed with factored styles. Changing the interaction pattern is much, much harder. Blend is not usually the best tool for that, either. Good interaction patterns are not just transition effects and such; they always require logic to implement the users’ needs and wishes.

    This excessive attention to architecting so that designers can make things pretty is only making it easier to put lipstick on the pig. I think it’s a better investment to make sure we’re not creating a pig that needs prettifying.

  2. Alan Le says:

    MVVM is a framework where the view is the responsibility of a designer. Designers express themselves using tools instead of code. The current tool for Silverlight design is Expression Blend. If the framework breaks Blend, then the designer is blocked. And if we don’t get designers on board, we’ll end with more of the same non-usable, ugly apps.

  3. Andrew says:

    Steve Py makes a great point. It’s funny actually, Developers get irked by Designers, Designers get irked by Developers and Users hate both. 😉

    The problem mostly comes down to the fact that most of the time Designers and Developers think they know what the client wants based on their own opinion rather just asking the actual end users. And when I say “end users” I mean the people actually using the app, not some Manager who hasn’t done any real work in the last five years.

  4. Steve Py says:

    Sorry, but what the hell is wrong with UI-centric development?? The issue with most software I’ve seen is that there is way too little regard to the UI, as if developers forget that software is only as good as the number and contentment of “users” that use it! I think Ward’s description of the tailor more closely resembles user experiences with software UIs built by “software engineers”, and now he’s a bit bitter about being on the receiving end of “we can’t do it that way because…”. 😉 How many times have you told a user that excuse because of the “architecture” or chosen toolset?

    IMO Microsoft took a step too far with Blend in that it wanted to delegate all UI to the designers which creates a gap that can be difficult to bridge.

    UI designers are nothing new, but typically ignored until it’s too late. There have been plenty of attempts to try and bring them in near the end of the development cycle with things like skinnable / theme-able applications and such, but the reality is that like testers, UI designers should be involved right from the start. IMO a UI designer should be working in nothing more than UI prototyping tools and discuss with developers and BAs, “can we make this function like this?” BA (or customer) asserts it fits with the business requirement, developers have to be the tailors.

  5. Hey Ward,

    I hope you didn’t read anything triumphant in my comment mentioning Blend in our discussion earlier. I also hope that you know that I am continuously working with the Blend team to make the experience better than it is now (for example the “create sample data from class” menu item is a result of those discussions). I am also not very happy when I have to bend my code to make it work in Blend. However, the fact remains that for firms like ours, if we cannot work in Blend, the result is more pain. I don’t like pain, so I feel compelled to remember people what works and what doesn’t work in Blend. I guess that where your frustration ends, mine starts 😉

    Eventually, like I told Glenn this morning, there is no one solution who fits everyone’s needs, at least not at the moment. Thankfully we can choose to use the implementation that we want in the applications that we build. Ours happen to be very design and UX intensive.

    Nothing personal though 😉


  6. John Papa says:

    Ward … I don’t think its that it won’t work in Blend that is the issue. I think its more about allowing for design centric and UI centric development. But you know how I feel already.

  7. Rick Barraza says:

    Nice Post. I agree that “it doesn’t work in Blend” isn’t the best argument against MVVM architecture. I think there are still many iterations of the Tool(s) in question and how they do work together versus how they should work together. I think there are too many teams duplicating effor across too many tools and the messaging has become muddy. Keep up the critiques, they should be addressed and you pose them well.

Leave a Reply