Several things in a developer's e-mail just didn't sound right (they reported problems explicitly checking mouse click coordinates to display a custom control context menu).  Reviewing the code with the developer in their cube, I pointed out Windows Forms features that made much of their code unecessary, suggested a couple strategies to try to address some legitimate issues associated with their feature, and bookmarked relevant sections in the developer's copy of Chris Sell's "Windows Forms 2.0 Programming", that I had insisted we buy (along with Löwy's "Programming .Net Components, 2nd ed.") for everyone in the department. The developer's response: "Do I really have to read all this?  Its almost working, and we've got a schedule to keep."

My job has included interviewing potential new hires at my last three companies, and the one quality I'm always desperate to find, is evidence of sincere PASSION for software engineering. Staffing with passionate developers eliminates situations like the one above, while dealing with "corporate" developers just makes you want to poke your eyes out with a sharp stick on a daily basis -- or makes you want to poke THEIR eyes out, which apparently violates some sort of HR policy.

The "corporate" developer has little interest in software engineering, beyond what's required to check their currently-assigned feature off of their "To Do" list, and they're not about to spend time attending local .Net user group meetings, or catching up on the latest development books, or monitoring dev. community RSS feeds.  Their code usually shows little evidence of any attempt at refactoring, reflects ignorance of features explicitly designed into the dev. platform to address common usage scenarios, ignores obvious opportunities to employ common design or architecture patterns, and sometimes seems specifically designed to make it as difficult as possible for anyone else ever to understand, maintain, debug, or extend, their particular "contribution" to the code base.  Obviously, you can't hire someone purely on the basis of passion, but passionate developers tend to quickly pick up whatever they need to know, and understand it at a much less superficial level.  Passionate developers also care deeply about the quality of the code and architecture that they are inflicting on their co-workers. Some of them may secretly even... blog.

Beware, however, of the passionate highly-skilled developer who seems obsessed with finding fault with Microsoft's recommended approach to almost anything.  These are the developers whose code will have no relationship to anything found in any standard Windows development reference, ensuring confusion for every experienced Windows developer who joins the project in each new dev. cycle, and eliminating any chance of a clean migration path as Windows dev. technologies continue to evolve.  These developers are always able to provide low-level technical justification for their choices that is hard to argue with, but they never seem to be able to demonstrate any real problems with the simpler (usually higher-level), expected approach, that a target end user would actually care about -- or even be able to detect.

Developer passion and complacency are equally contagious, so be sure that your hiring, and FIRING, decisions leave no doubt as to the kind of engineering department you're trying to build.

The fact that the Blend tool was used to design the non-trivial UI of Blend itself, is pretty convincing evidence that the first release version is probably already suitable for use on many real-world projects, but there are a few practical concerns that always seem to be glossed over in Blend-related discussions.

How exactly is this new designer-developer coordination supposed to work?  An interesting Channel9 interview with members of Microsoft's User Experience Team in the UK details some valuable lessons learned through trying to apply this developer-designer collaboration on actual projects (jump to minute 16:00 to skip intro material).  The team discovered that designers needed some level of understanding of Windows development and WPF, in order to avoid problems such as designers creating image elements where they should have restyled control templates, or designers breaking links to underlying business logic by "replacing" controls with restyled versions.  The developers also found the auto-generated Xaml provided by the designers to be difficult to read and edit in those inevitable situations where it became necessary or beneficial to do so.  The UK team finally settled on the very interesting approach of having the designers generate a "wire frame" DRAWING of the overall UI, which the developers use as a guide in beginning the actual project, while the designers go on to create separate resource library projects, featuring the production quality UI elements that the developers plug into their own carefully-crafted production code.  Other development teams have reported success using a single set of shared project files, but its helpful to be aware of a full range of real-world proven alternatives before rushing to apply Blend on your company's next mission critical project.

Realistically, what are the chances that your company will hire professional desigers, or approve funds to hire one of the few consulting firms with experience in this area, like Vertigo?  I recently worked at a chemical equipment manufacturer, which contracted with a professional industrial design firm for their complete line of hardware enclosures, while relying on the artistic talents of internal developers using MS Paint for their accompanying software, and a marketing manager at a different company once asked why I couldn't just use clip art throughout the UI for the "commercial quality" digital video capture and editing application they'd hired me to write (using DirectShow, to accompany one of the first generation 1394 Host Bus Adapters).  For many organizations, this attitude is likely to continue -- at least until that first trade show where a competitor demonstrates a professionally-designed product that takes full advantage of new WPF graphics capabilities.  Even if a company is willing to allocate the funds, there is still the issue of trying to FIND designers who have the combination of skills described in the UK group video.  This is not a situation where you can simply retask your company's web developer or marcom person, which still leaves it up to the DEVELOPERS to acquire expertise with Blend, at least in the near term.

On the architecture front, Blend promises to enable designers to "reskin" an application at will, but this separation of UI from business logic occurs at a much higher level than what is currently supported through code-level frameworks such as CAB and SCSF. Whereas these code-level frameworks often attempt to create extra abstraction layers (presenters, controllers, etc.) to decouple UI "views" from the underlying business logic, they still assume that developers will be required to "code" the UI.  Microsoft has already announced that CAB/SCSF will be replaced by Acropolis, which will offer some degree of support for Blend (currently, limited to the ability to open "PartViews"), but is not expected to ship "for quite some time". 

Finally, Blend is specific to building WPF applications, and WPF is a brand new technology, with a steep learning curve, which will not even enjoy a significant degree of Visual Studio designer support until the release of Visual Studio 2008 at the end of this year. Some corporate managers may feel it is safer to hold off on any commitment to Blend, or designers, or possibly even WPF, until things sort themselves out.  I disagree, in cases where a change in technology clearly represents a major advance that will need to be adopted eventually anyway, and I'll have more about THAT attitude in a future post.  A beta of Blend 2.0 is already available and, as the tool continues to mature, and the practical issues I've mentioned are resolved, we can expect Blend-based development to become the standard for a significant percentage of Windows dev. projects in the not-too-distant future.  I recently decided to check out an online course in Blend at the local junior college, and the text we are using, "Microsoft Expression Blend Bible", seems to be a pretty good introduction to its features

A few hours of playing around with one of the earliest CTP builds of "Sparkle" (now, "Blend") got me very excited at its potential to address some familiar UI design PROCESS issues...

1)  Our client's team of marketing product managers had flown in from corporate headquarters for the annual project kickoff meeting.  After reminding us that we had to deliver in ten months in order to meet Christmas store deadlines, they proudly announced that it had been decided that EVERYTHING in this year's version of the product would be designed around the concept of a "concierge".  If the user wanted some information, they would consult the "concierge".  We said, "Fine,"  would this take the form of some kind of animated assistant, or were they envisioning a special screen that the user would navigate to in the application?  Would the feature involve recorded or synthesized speech?  Would it have an online component?"  We were told that focus groups were already hard at work, considering such questions as "If you were to invite the concierge to dinner, what would he look like?".  Four months later, a group of us flew East to participate in formal usability lab studies on the product shell, and I took aside one of the PMs, to try to pin down this still-undefined concept of "concierge".  He told me the design consultants were still busy, finalizing the product color scheme, and he was shocked when I told him they could safely delay a decision on the final RGB color values almost to the end of the project (this was MFC, so I simply #defined place-holder color codes in a header file), whereas implementing the "concierge" might require significant effort.  Six months later, we shipped a product (to good reviews) whose only reference to "Concierge" consisted of a single modal dialog.

2)  In preparation for a major revamp of the company's flagship product UI, myself and several other developers in US and German engineering departments spent several months separately implementing a number of interactive mockups using Windows Forms, while I used PhotoShop to generate over 200 additional static "screen shots" of UI alternatives that would have been too time consuming to code...

3)  I've almost always had a major role in defining the UI of the products I've worked on, writing many custom UI elements (in Windows Forms and, previously, with MFC), and working with end users or user proxies (ie: Marketing) to design the overall UI experience.  This is one of my favorite parts of the development process, and I've read most of the popular design references (Cooper, Krug, Nielsen, Spolsky, Tufte...), so I've always been surprised at the number of developers with good technical skills who seem to have no affinity for, or interest in, user interface design. In some cases, the developers simply seem unable to envision how complex and unintuitive their proposed application workflow will appear to the target (non-technical) end user.  In other cases, it's pretty clear that they consider any amount of attention to aesthetics or design to be completely irrelevant to the task of engineering an application, even to the extent of failing to size and line up controls properly, or to follow basic Windows UI design guidelines.

For those who have been busy with existing projects, and may still be unaware, Microsoft's Expression Blend is a UI layout tool (and much more) for WPF applications, that enables designers to generate the actual production UI for an application themselves, rather than having to settle for the developers' distortion of some carefully-rendered initial design.  Because they share the same project file format, developers can load a Blend project in Visual Studio to add business logic to the designer's work, and designers can load a Visual Studio project in Blend to professionally "style" basic control layouts stubbed out by the developers.  Blend's capabilities extend far beyond mere layout however.  Without leaving the design environment, designers can bind controls to XML data, or to class instances defined in code-behind files, or bind property values between controls.  Designers can hook up events, create and trigger animations (defined in WPF as any change in the UI over time, including the appearance and location of controls -- as opposed to the more traditional definition, which was specific to image animation), completely restyle the appearance of system controls, or implement entirely new controls.

Sound a little too good to be true?  A little skeptical that your same company management which ships products featuring artwork created by developers using MS Paint will suddenly approve funds to hire "interaction design professionals" -- and just where do you find these strange, half-programmer, half-artist, creatures anyway?  More about all that in my next post.

I recently decided to cash in my company stock options and take the summer off to focus full-time on the latest generation of Windows development technologies (WPF/WCF/WF/LINQ/Blend etc.) and maybe pick up a few MCPD certifications, before looking for someplace new to put it all to good use.  I've actually worked with WPF/WCF and Blend off and on, beginning with early CTP builds, over the last 18 months, but now I'm ready to dig a little deeper, and the timing seemed right to get a jump on what I think will be some fundamental changes to the way companies staff and organize Windows development projects, going forward.

I started out writing applications in C for a software development shop in Japan, did alot of work in C++/MFC, and some DirectX, at two Silicon Valley startups, and have been working with C# and Windows Forms ever since the release of .Net 1.0 five years ago.  My experience has been almost exclusively with desktop and client-server applications, with web projects limited to a few experiments with personal sites (like this one).  Although I took a couple intro. to CS courses at CAL (Berkeley), my degree was actually in Asian Studies, and I learned to program "in the trenches".  I was also the .Net evangelist at my most recent company, authoring internal white papers on .Net, sending out a weekly ".Net FYI" e-mail, conducting .Net training, and sweating the truth out of job candidates who claimed to have .Net experience (You'd be amazed at the number of Silicon Valley engineers who list "three years of C#" on their resumes, who are unable to explain how to hook up a simple event handler, or identify basic terms like "reflection", "attributes" -- or "Richter" and "Löwy").

After years of preaching the need to monitor dev. community RSS feeds, and this extra time on my hands, how could I possibly NOT have a blog of my own?  So, here I am, injecting my drivel into the spew, with a site I expect will feature some combination of comments on development technologies and the trend toward more agile development practices, sprinkled with accounts of management inanity that I suspect will seem all too familiar...

Welcome.