Technologies that Drive Patterns that Drive Tools (that Drive Technologies!)

I recently hosted the first .Net user group here in town and was pleased to be joined by D’Arcy from the Winnipeg .Net User Group.  Afterwards we had a chance to sit down – probably for too long, given his two-hour drive home afterwards! – and talk about everything from past projects to past employers to the impossible fact that we didn’t know each other given how many times our paths have nearly crossed.

We got to talking about design patterns at one point in the conversation and how it was interesting to see some of the emerging patterns and how tightly coupled they were to some of the technologies that we have as developers.

One such instance is how MVVM serves WPF nearly exclusively.  Sure, it’s a derivative of past patterns, but this has been very tightly coupled to the WPF experience.  So, here’s a technology that, as developers began to share code, helped to surface a pattern.

Then, MVVM was used to create the very tools that designers and developers are using to scratch together WPF applications. Now there are even extensions to VS.Net that allow easier implementation of MVVM (see Karl Shifflett and the WPF Toolkit).

WPF drove the creation of MVVM.

MVVM served as the backbone for tools development.

Now, it’s getting really interesting.  Because of limitations in the command binding syntax and underlying framework, the folks on the WPF are actually considering changes to WPF to allow for simpler binding. 

Where did this come from?  MVVM exposed a need for binding to commands that was not native to WPF.  Some of the tools that are being created have features that allow for developers to work around these WPF limitations.  The WPF team recognizes this – good on them – and are now updating the framework to improve this aspect of WPF development.

Tech –> Pattern –> Tool –> Tech.  We’ve come full circle.

Lather, rinse, repeat.

Rephrasing the Business Vernacular

It is always interesting when you first join a team and everything they talk about seems foreign or new.  It usually doesn’t take long before you realize that much of what is said, many of the concepts and the overwhelming majority of acronyms are actually just different ways of saying the same things you’ve said all along.

There are instances, such as this new position, however, where everything is new to everyone. The company where I now work has expanded with triple- and double-digit growth since inception in a market that doesn’t know its product.  The technology is new, the people are new and the processes are new.

You can’t hire people with experience in this field; there just aren’t a lot around.

So it’s no wonder how the company has adopted terminology which works for them but seems like a foreign language to me; it seems foreign to some of them too! 

What has ended up happening over the last few years is that the people here have begun to recognize some of the processes as being similar, so, while there are Service Orders, Work Orders, Tower Tickets, Help Desk Tickets and Infrastructure Work Orders, they are all just units of work.

I am making it part of my job to introduce more common functionality to handle these very similar concepts and to merge much of the existing interfaces together to capture this same data.

The biggest strike against the framework as it exists (I’ll leave Classic ASP out for the moment) is that there are different data structures for all of the above work.

Today was a big data modelling day – again – as I was able to permanently strike off some 25 tables from the company data model.

And, if I’m successful in this attempt, some of that local language will soon be struck out of the vocabulary here too.

How We Failed

I had a chance to sit down and walk through a list of higher-priority items with several of the key stakeholders for the existing enterprise management application today.  We made some great progress and I was able to diagram out some of the NextMostImportantThing items that users are looking for.

It wasn’t the features they were asking for that shocked me, however, when we spoke; rather, it was the way they described them.

Generally speaking we as software developers have failed our users.  Perhaps, better said, we have failed ourselves because of what the users have come to expect, and what they perceive a ‘good’ user interface might look like.

For a long time I have been in the camp that claims, “Users don’t really know what they’re asking for.”  In a lot of cases I could argue that still might be true, though I would suggest a rephrase on that take to say “We haven’t equipped users with the vocabulary they need to best express the functionality they would like.”

Why is it important to put the blame on developers, analysts and architects?  Because it is not likely our end users who will come up with the next innovation in user interface and in order for us, as a community, to do that very same thing we must first admit that our processes are broken.

Take, for instance, some of North America’s leading applications in the CRM category.  I was recently contracted to a company to help them decide from the myriad of options out there what platform and package best suited their needs.  Vendor after vendor I became increasingly frustrated as I helped the company survive demos and walkthroughs that confused users and presented over complicated user interfaces for very basic tasks.

I later returned to that company – after their employees completed the three week training program for the selected package – to help a lady who was in tears because she couldn’t remember how to print labels.

I remember the epoch of the trainer’s failure who, when asked about how to print labels, replied very confidently, “Oh, that’s easy! All you have to do is pull up a query of the customers that you want the labels for, flip over to this tab, look for the tree node appropriate for the label size and type you’re looking for, then drill into the options to begin the merge.”

To you and I, that might sound easy, but lately I’ve been seeing the stunned look on those users’ faces when he said that over and over in my mind.

Our users are people, not computers. Data and queries and tree nodes and tabs and asynchronous operations mean nothing to the 45 year-old office worker, and quite frankly, to most 15 year-old so-called “computer whizzes” too.  We have polluted the user experience with elements of what makes our lives – as developers – easier to digest.  I love using a tree to walk through a class hierarchy or browse a project, but is that how people – note that I didn’t say “users” – think of their customers?  Is it fair of us to group everything not part of the application framework or the user interface into a bucket called “data” and then blame the users for not getting it?

I’m starting to wonder if great design begins not with understanding what the user wants, but rather with equipping the users with the vocabulary needed to express their requirements.  When they start thinking and telling us about the kinds of things they would like the computer to show them – and I’m not talking about endless grid after grid after table after filtered list – then we will be able to empower them to do the human side of work and start letting the computers express the data in more meaningful ways.