A physicist we hired, partly because of her impressive "language lawyer" level of C++ expertise, left for a two-week trip back to her home country, after several months of knocking out project features at what had seemed to be a very respectable pace.  In her absence, the project technical lead tried to implement what should have been a minor change, and ended up spending several days tearing his hair out, just trying to make some sense of her code.  When the original developer returned, she explained that MFC simply wasn't "object-oriented enough", and that she had essentially just replaced large areas of the framework with her own, more "correct", versions of existing APIs.  According to the usual definition of "Mort"s and "Einstein"s, this engineer was definitely an Einstein, but she was an Einstein who was FOCUSED ON THE WRONG THINGS!  Aside from the fact that our code base was now inconsistent with all published API information and no one else could ever hope to understand or work on her code, her decision also guaranteed that we would be treated to all kinds of random errors whenever Microsoft got around to updating its MFC dlls. 

As frustrating as it can be to deal with "Mort"s, the tendency of many "Einsteins" to resist learning (or unnecessarily insist on replacing) standard framework capabilities, can derail projects, and permanently cripple code bases, so it always bothers me when I hear respected figures in the developer community suggest that testing for knowledge of specific APIs is irrelevant when it comes to evaluating engineering candidates.

"Our philosophy is that we're hiring for the long term, and any technology you happen to know right now may well be obsolete next year"

- from Joel Spolsky's (in all other respects, definitive) guide to hiring developers, "Smart And Gets Things Done"

I agree, in principle, when Joel says it makes absolutely no difference whether an engineering candidate is familiar with a particular technology or buzzword -- until you discover that those same developers who are unfamiliar with "MSMQ" turn out to have been supporting a .Net-based client-server application for the past several years, and written a complete network fault recovery system from scratch... or their own transaction support... or their own approximation of role-based security...  Again, these are examples of Einsteins hard at work, when what you really needed was an API expert (at least until they could demonstrate actual DEFICIENIES that couldn't be addressed just by modifying or extending the existing feature set).  Similarly, the Einstein who claims that an understanding of Design Patterns and Object-Oriented (Behaviour-Driven) design, and unit testing... trumps any need for expertise with a specific development framework... may now be sidetracking the members of your project into building and supporting a "better" MVP-based UI framework, when the cost-benefit trade off on that, especially for non-trivial, highly-customized, WPF-based UIs, is still far from clear. 

For the kind of projects I work on, (and that most companies who are interviewing Windows developers usually seem to be seeking to staff), the ability to write low level data structures or sorting algorithms, which is how many organizations test for what they think are Einsteins... is completely irrelevant (and absolutely the LAST thing you ever want your developers to even THINK about doing), while an in-depth understanding of the various considerations involved in using, combining, and modifying, elements chosen from the huge pool of components available in the BCL and elsewhere... is absolutely ESSENTIAL.  Testing a candidate's understanding of specific APIs also gives you some indication of whether that developer has the potential to be productive IMMEDIATELY.  you want your new engineering hires to be familiarizing themselves with the PROBLEM DOMAIN rather than spending their time to learn a new development API.  You also want to ensure that a new developer's code is not going to cause problems for everyone else on the project and, no matter how brilliant someone may be when it comes to CS fundamentals or high-level concepts, with the learning curve for new technologies like WPF, and the breadth and depth of the ever-evolving framework, its probably not unreasonable to expect code written in the first six months against an unfamiliar API to require an extensive amount of rework.

I've occassionally recommended candidates who impressed me as being super-smart, even though they had no direct experience with the specific Windows development technology we were expecting them to use, but only when their performance in the interview suggested they had made the effort to aquire an IN-DEPTH understanding of whatever technology they HAD been using -- with special bonus points for the rare candidate who could demonstrate familiarity with preliminary CTP releases of UPCOMING Windows dev. technologies, since they were unlikely to waste time inventing their own solutions without bothering to at least first fully understand the capabilities of solutions already provided, or which might soon be available.

In fifteen years as a developer, I've had to rewrite ALOT of code created by Einsteins with advanced degrees (my only degree is in Asian Studies), and show them how to write maintainable code and make proper use of available framework features... while I freely admit that I couldn't write a basic sorting algorithm or low-level data structure to save my life.

The only time I ever missed not having a more formal Math/Engineering background, was when I once got stuck trying to calculate a particular coordinate in the drawing routine for my ActiveX "CoolLabel" control, and I ended up finding the solution (calculation of a "polar" coordinate) only by flipping through an illustrated Math encyclopedia three days later.

(Hey, this feature wowed them back in '97, and the associated mapping product sold hundreds of thousands of copies)

Managers at the company I worked for in Japan were surprised that I knew the term "Mado Giwa Zoku" (), or "window-seat tribe", which dated from the earlier economic era of the lifetime employment system, where employees who had proven themselves to be hopelessly useless were still kept on the payroll, and just given a desk by a window somewhere, out of everyones else's way.  Unfortunately, in software, there's just no way to keep someone out of everyone's way while still allowing them to touch the code base.  I was reminded about that recently, as I read about the tendency to trash "Mort", in at the first Alt.NET conference, recently held in Austin, Texas.

"Mort", "Elvis", and "Einstein" were personas defined in the developer tools group at Microsoft many years ago, to describe the three categories of developers that made up the target market.  "Mort" is the pragmatic developer who only studies engineering issues in the context of completing some assigned task, and learns JUST ENOUGH to let him complete that task.  "Elvis" consults a variety of development resources to help him improve the quality of his engineering, and expects tools to enable him to create custom controls and other alternatives to the canned solutions that Mort relies on.  "Einstein" is continuously seeking to expand his understanding of engineering issues, far in advance of receiving any specific feature request on which to apply that knowledge, and he demands tools that enable him to craft more sophisticated lower-level solutions.

Alt.NET is a reaction to what some Agile practitioners consider to be Microsoft's preoccupation with simple drag-and-drop development, at the expense of providing truly MEANINGFUL support for modern Agile practices.  Alt.NET supporters complain that Microsoft introduces its own, sometimes half-baked, alternatives to established, more fully-featured, open source tools, creating difficulties for developers trying to transition to Agile.  Although Microsoft's original definition did not imply any criticism of "Mort" developers (it stood for "mortal"), many participants at the recent Alt.NET conference seemed to take the position that the developer community needs to quit coddling Morts, and focus on how to integrate best-of-breed (presumably, non-Microsoft) tools and practices to support "true" .Net-based Agile development.  Other conference participants described Mort as an "Elvis in training", while some Microsoft attendees took issue with the overt Microsoft bashing.

There are certainly Good Morts, who may be junior developers overwhelmed with all the issues involved with real-world engineering projects, or developers who have only ever worked on trivial projects, or even non-developers occasionally "re-tasked" to write code -- such as the hardware engineer who picks up a copy of "Master .Net in 4 Minutes" and delivers a (surprisingly functional) FrankenApp in two weeks.  Good Morts can be mentored, or inspired, or simply replaced with more qualified resources when an application reaches a level of complexity or importance to justify funding the change.  But, for every Good Mort, there always seems to be a bench of Evil Morts, who are either unable or unwilling to make the effort required to bring their work up to an acceptable level.  Evil Morts suck time and energy from their peers, who constantly have to decypher and fix Mort's code, and who have long since given up trying to explain basic software engineering concepts like "separation of concerns", or "refactoring", or "WouldYouPleaseFollowSomeFreakinCodingGuidelines'".

The tough question is what to DO with Morts.  Its a little naive to imagine you can avoid or eliminate them completely.  The cost and scarcity of really good developers (whose fully-loaded cost here in Silicon Valley can top $150K), may have caused your company to settle for whoever it could get.  Maybe you got stuck with the bosses best friend's nephew (a story for another time).  And then there are all those other pesky real-world concerns liable to be raised by managers...

"We can't just get rid of Mort!  He's been with the company for fifteen years.  He's a nice guy, with a wife and kids and a mortgage... who spends his weekends delivering meals to shut-ins..."

or...

"What?  Reduce headcount in my section (and my perceived importance to the company)?!!!

or (I'm not making this up)...

"Yes, we know Mort's a problem.  But he's been here N years, and we have to be careful to avoid being sued for age discrimination"

Meanwhile, Mort still makes his all member fields public, passes eight separate parameters to hundred-line C# methods, unwittingly writes thousands of lines of code to duplicate capabilities baked into the BCL, sees nothing wrong with cutting and pasting the same ten-case switch statement into three different locations in the source, and will soon be writing reams of unmaintainable unit test code to accompany his convoluted implementation code.

Find some way to keep Mort out of your code base, because the situation is only going to get worse, as the learning curve associated with each new development technology continues to grow steeper, as new practices like Scrum shorten and intensify the development cycle, and make it ever-more-critical for developers to be able to rely on the quality of each other's code, as open source alternatives continue to inflate the size of the "standard" developer tool set, and as the PACE OF CHANGE to tools and practices accellerates to become almost continuous...

Maybe Mort has interests or talents that could be put to use somewhere else in the company.  Maybe you can offer him some financial incentive to leave (His fellow developers would probably offer to chip in -- and, if he goes to work for your competitor, you benefit TWICE!).  As a last resort, the closest developer equivalent to Mado-Giwa-Zoku would be to assign Mort a solo project... that you never plan to ship. 

The path toward becomming an "expert" Windows developer used to be pretty straightforward.  You needed only the most basic understanding of C++ to qualify for a job (if you could define a virtual function and explain the "slicing" problem, you were in), you worked your way through Kruglinski's introductory text on MFC, skimmed each month's issue of "Microsoft System's Journal", and eventually learned to check the index of Prosise's "Programming Windows With MFC" and the Table of Contents of the "MFC Answer Book" before starting any feature, since there was a good chance the authors had already done most of your work for you.  After two or three years of implementing features, you'd probably gotten around to tackling "MFC Internals", and Richter's "Advanced Windows", and maybe Cooper's "About Face", and one or more of McConnell's treatises on process ("Rapid Development", "Code Complete"...), which would put your skills pretty much on par with those of senior Windows developers working just about anywhere.  If you were REALLY concientious, you might have picked up a copy of Petzold's "Programming Windows", the GOF's "Design Patterns", and maybe even a few business-side books like Cusumano's "Microsoft Secrets" -- and then tried to figure out how any of this related to pounding out new features in whatever convoluted MFC mess you happened to be maintaining.  For tools, you relied exclusively on Visual Source Safe and the Visual Studio IDE, and probably watched with detached interest every year or so, as managers fended off some wild-eyed radical agitating to switch to Borland's OWL.

The last time I set aside some serious "study time" between jobs (on that occassion, it was involuntary -- the company shut down and laid everyone off), I had already done all of the above, and I ended up spending ten months hanging out in coffee shops, reading Eckel, Meyers, and others on C++, and programming simple demos in DirectX, before taking what turned out to be a really great opportunity, writing a DX-based digital video editing utility at a hardware startup.  At the time, I had actually been toying with the idea of getting into game development (what developer hasn't?), but suicidal margins were taking out those companies left and right, with a thousand eager job candidates for any position at one of the remaining "name" companies.

Since then, of course, the bar for attaining (and maintaining) any degree of Windows developer "expertise" has been raised, requiring continuous monitoring of dev. community RSS feeds, evaluation of CTP builds of upcoming technologies, and a reference library of critically important material from Lowy and Sells and Richter... and that was BEFORE this wave of .Net 3.0/3.5 tools and technologies that's now looming overhead.

In my current "sabbatical", I'm exploring different ways to architect and implement non-trivial WPF/WCF/WF/Linq applications, while trying to maintain the discipline required to write associated unit tests, and work within the confines of a continuous integration build environment.  I'm trying to understand issues like whether it is still useful, in WPF, to apply the WinForms technique of centralizing marshalling of communications to the UI thread in the business layer (via AsyncOperation), BEFORE raising events to the UI.  Are there situations where data binding to UI elements is NOT a practical strategy?  When is it better to set bindings manually, versus relying strictly on Xaml (via ObjectDataProvider etc.)?  How should source code be organized to best support CI automation?  How do implementation strategies, such as the use of the Singleton pattern, impact unit testing, Xaml integration, and the ability to "hand off" the entire UI layer to designers working with Blend?  Is there a real net benefit to adding extra architecture layers just to support unit testing of the UI?  If so, is it better to use some canned framework like SCSF/Acropolis, or just to roll your own, as Jeremy Miller has suggested?  I've also spent a surprising amount of time and energy resolving issues with open source tools, many of which suffer from REALLY poor documentation, and sometimes don't want to play well together.

I figure its going to take me another month or two before I'm satisfied that I'm able to provide definitive direction to a development department, rather than having to suffer someone's else's WAG (Wild *ss Guess) approach to implementation or dev. process.  My timing may have been a little early, in terms of widespread .Net 3.0/3.5 adoption and available job opportunities, but as long as I haven't jumped the gun by two or three YEARS, I think I can probably endure this pain and suffering a while longer.

Now, if you'll excuse me, my latte's getting cold, and I want to finish testing this new validation strategy in time to catch a matinee at the theatre next door...

I've come accross several good posts recently, reminding developers not to get sucked into a "Red Queen's Race", trying to keep up with every new development tool and technology, and every popular development author's latest book.

On the other hand, your job as a developer includes the responsibility to promote tools and practices that enable your company to create more reliable, more aesthetically pleasing versions of its software, delivered much more quickly -- and quite possibly requiring fewer (but better trained) developers.  Somehow, you have to sort through all the hype, to identify the subset of tools and practices that are actually destined to become industry standards, and you need to understand these technologies well enough (and early enough) to design your CURRENT code and architecture in a way that will make eventual migration to the new standard as painless as possible.

You'd think, with several months free of any of those pesky JOB responsibilities, that I'd have no problem catching up on my backlog of unexplored technologies and unread books, even with the distraction of daytime TV shows like "MythBusters" and "Dirty Jobs", and regular trips to the beach, but even after dropping some of the more "speculative" technologies, like F#, Acropolis, and the ADO.Net Entity Framework, from my study list, I still feel like I'd need to take the rest of 2008 off, just to cover the essentials... and maybe 2009 too!

One of the first things I wanted to do this summer, was to set up a realistic simulation of an acceptable enterprise development environment, using virtual machines, in order to practice with, and test, Agile tools and processes.  I finally settled on using VirtualPC 2007 to create VS2005 and VS2008 Pro Beta2 workstations, with associated continuous integration VPC servers running a whole slew of open source analysis tools.  I can check for issues developing as a Least Priviledged User on my Vista laptop host system, compared with developing with full admin. priviledges on Windows XP running inside a virtual machine.  To create a fresh work or test environment, I can simply copy a "base" VPC image, without having to reinstall the OS.  It may even be possible for the server to automatically publish the compiled output to a fresh VPC image for testing. If you want to set up something similar, you'll save yourself A LOT of time and misery if you refer to the links below.  One hint: Use the NAT networking option to share the host system's internet access and virus scan software, for tasks like downloading OS updates, and switch to a Loopback Adapter when you want to communicate between VPC images, or between your host and a VPC image. You'll also want alot of disk space (each VPC dev. workstation ends up around 9GB.), and alot of RAM (My system has 2GB).

    VPC Development and Debugging White Paper
    Creating Smaller Virtual Machines

For more information and guidance on CI server-based development, I recommend the recently-published Continuous Integration", from the Martin Fowler series. Setting up your server to automatically regenerate the database, complete with a clean set of demo data, in order to validate schema changes, is just one example of possibilities I'd never considered.

I found a couple of new books, covering enterprise Agile and Agile project management, to be enjoyable, quick reads, suitable for managers who may just be starting to seriously consider Agile practices, but the books didn't contain anything that would be new to developers who have been keeping up with Agile community discussions over the years.

    "Scaling Software Agility", from the Agile Software Development series
    "Manage It!", from the Pragmatic Programmers series

I've been working through the LINQ examples in the recently published "Introducing Microsoft LINQ", and I definitely recommend that book as a quick way to get up to speed on the three flavors of LINQ (to Objects, to XML, and to Databases), and the new C# 3.0 language features LINQ is built on.

Its a strange kind of vacation...

Halfway through a four year stint in what was then a "peacetime" army (how quaint does THAT concept seem these days?), I was attached to a Special Forces team for the duration of a three month Arabic language course at the JFK Special Warfare Training Center, at Fort Bragg, North Carolina.  I noticed my new classmates didn't seem to share my unit's obsession with spit shined boots and starched uniforms and buzz cuts, and I was stunned on our first day, when a low-ranking team member cut off an attempt, by an overzelous regular army officer classmate, to assign us some unrelated busy work, saying "No, lieutenant. That's not why we're here" -- leaving the young officer red faced and stuttering.

Over the next few weeks, in answer to my many questions, members of the team described HALO freefalls, sniper, SERE (survival, escape, resistance, and evasion), and Ranger schools, the stress of trying to keep a goat alive through a series of burns and bullet wounds inflicted as a part of medic training, techniques for constructing demolitions using common household materials, the experience of being "drowned" in a swimming pool by military scuba instructors, and much more.  One afternoon, the team's medic suggested I join them at the local hospital after class, where they would practice giving each other injections.  I expected to start off with some carefully-supervised sessions using oranges or something, but they just handed out vials and syringes, and the team's weapons man guided me through the steps, on his own arm.  When I had trouble piercing the center of the vial cap because my hand was shaking, he just arched an eyebrow.  When I failed to jab the needle deeply enough into his shoulder, and had to gradually PUUUUUUSH it in the rest of the way before depressing the plunger, he simply drew a deep breath slowly in through his teeth.  Shrugging off my embarrassed apologies, he gave an evil grin and said, "My turn."  Of course, I didn't feel a thing, and my own attempt on a second victim went much more smoothly, but I still turned down an invitation to come back the next week when they were scheduled to practice inserting IVs.  The no-nonsense attitude and competence displayed by every member of the team was such a contrast to my experience in the regular army, that I spoke to a recruiter about transferring -- until I found out I'd have to extend my enlistment an additional three years.

The make up of a special forces team reflects many of the same values promoted by Agile methodologies, consisting of a small cross-functional team of expert individuals, who share a commitment to ruthless pragmatism.  An S.F. team consists of a team leader, with one expert and an assistant to cover each of four specialized areas: weapons, communications, demolitions, and battlefield medicine.  Team members continuously cross-train one another in their specialties, constantly attend courses to acquire new skills, and receive language, culture, and jungle, mountain, or dessert training appropriate to whatever region is their group's focus.  They can't afford to suffer fools, or foolish processes, lightly.

In contrast to the pragmatic "adapt whatever proves useful" philosophy embraced by most Agile advocates today, the first generation of Agile proponents tried to impose their own brand of process fundamentalism, and only gradually mellowed, partly through the influence of thoughtfull critiques, such as in the book, "Extreme Programming Refactored: The Case Against XP".  Most published Agile references now emphasize that Agile practices are not a "one size fits all" proposition, and it's the shared underlying Agile PRINCIPLES, rather than any specific methodology, which are important for organizations to cultivate.

"Critics of the first edition have complained that it tries to force them to program in a certain way... I'm embarrassed to say that was my intention... in this edition, I have tried to rephrase my message in a positive, inclusive way"  -- Kent Beck, in the preface to his second edition of "Extreme Programming Explained".

Unfortunately, some development groups remain unfamiliar with even the most the basic concepts of Agile development, with management still determined to try to nail down a "complete" design and "accurate" schedule up front, dividing responsibility for work into separate silos, preferring innocuous mission statements and shiny quality commitment plaques to the potential confrontation inherent in rigorous code reviews and post-mortems...  After ten years of intense discussion in the software developer community, with support for Agile practices increasingly baked directly into the developer tool set, that's hard to excuse.

As irrational as some management decisions affecting your development group may sometimes appear to be, at least they aren't likely to get you killed. When my Arabic language course ended, I returned to my own unit, just in time for our commander to order us to get our newly-redesigned camoflauge uniforms starched and pressed.  The uniforms came packaged with warnings from the manufacturer, clearly stating that starching and pressing would destroy infrared dispersing properties embedded into the fabric, making them a bright target for anyone with a night vision scope.  I suspect that more than a few individuals in a Special Forces unit would have stood up to remind the commander of why they were there...

I managed to get a job at a tiny software company out in the Japanese countryside, through a friend, whose best friend's husband regularly golfed with someone, who knew someone, who knew the company president.  Paid on the same scale as young junior employees who were still living at home with their parents, I struggled to cover rent and groceries, and had to save up when I wanted to buy an english language programming book or a pair of tennis shoes in my size, but I was writing software, my Japanese language skills were improving dramatically, and I no longer felt completely insulated from the local culture, as I had when I specialized in "creative accounting" in the Tokyo offices of a U.S. investment banking firm.

As the company's only english-speaking employee, and the first foreigner anyone in the company had ever personally met, I was part developer, and part exotic company pet.  On nights when the entire section would go out for some traditional drunken bonding, my coworkers might order me a dish of fermented squid entrails ("shio kara"), or conduct various other kinds of "experiments".  I'd be asked (usually, directly in front of one of our single female coworkers), "What do you think of Miss X here? Don't you think she'd make a fine wife?  Ha ha ha...".  Everyone went out of their way to make me feel welcome, and to accomodate my obvious language, social, and numerous other deficiencies, compared with what would be expected of a normal new Japanese company hire.  Instead of "Andy", the managing director began to refer to me as "An-chyan", an endearment for a loyal young mafia henchman, which visitors to the company always found hilarious.

We programmed wearing suits and ties, seated side-by-side on long tables pushed up against the windowless wall, in a small cigarette-smoke-filled office with 1950's era furniture.  We punched a time clock promptly at 9AM, ate lunch together every day, and rarely left the office before 7:00, often staying until 8 or 9 at night, and coming in for a few hours on weekends -- not because of any specific company policy, but just because it felt wrong to leave when everyone else was still there working.  Employees were not allowed to use the front enterance, but had to enter the building through the back alley.  We were all on a rotating schedule to clean the office on Friday mornings, including "benjo soji" (hosing down and scrubbing the ceramic squat toilets), and I occassionally got to lead the office in reciting the Monday morning "Chorei", or company pledge ("We solemnly pledge to give our all on the company stage, to optimize our skills and use of technology, in order to earn the trust of our customers and society").  Gradually, it all came to seem... perfectly normal.

Occassionally, there were moments when I'd realize just how culturally clueless I really was, such as the day my manager informed me the company had cancelled its policy requiring employees to wear their suit jackets in the 90 degree, 90% humidity walk from the train station to the office -- and I realized that, rather than confront me directly with my casual disregard for company policy, they had simply changed the policy, avoiding any potential awkwardness, while still subtley reminding me that I was breaking the rules.

I'm afraid I may have been a detrimental influence, as well.  My coworkers found my interpretation of weekend office casual attire to be very entertaining, as I described how developers in the US often worked in shorts and t-shirts.  Once, I tried to liven up my dreary work area with a plastic dinosaur on top of my monitor, and came back the next day to find my coworkers giggling uncontrollably, with a paper skyline of Tokyo in flames taped at the feet of "Godzilla".  A week later, toys of various kinds started appearing next to the keyboards of a few other developers.

About a year after I started working at the company, the woman whose husband had helped to arrange my initial interview invited me to accompany their entire family on the annual "golden week" stay at their vacation home. Making conversation in the car, they asked how the job was working out, and began to look at each other uneasily as I described my various experiences.  When I mentioned "benjo soji", and innocently asked whether this was a common practice in Japanese companies, the wife finally turned to her husband and asked in horror "Just what kind of company did you set him up with?"

It was a great experience, and alot of fun.

Two months into my first job out of college, in the Tokyo offices of a large U.S. investment banking firm, I received an e-mail asking me to verify figures to be presented to the Board of Directors in New York, describing a 65% reduction in trades processing costs, and predicting a similar improvement the following year.  I nervously asked the head of Tokyo operations if he could show me how he had arrived at his figures, and he gave an exasperated sigh, and demonstrated how he'd taken the (unusually low) daily trade volumes from January, plotted a straight line through the current month of August (when we were experiencing the highest trade volumes in the firm's eight year history in Japan), and then simply EXTENDED the line for another twelve months.  I stood there with my mouth open... and then hesitantly pointed out that projecting the growth of an embryo would give you a one year old child who was a hundred feet tall, and that his figures assumed fixed costs, while I'd already heard we were running unsustainable levels of overtime, and adding staff might require leasing more office space in what was, at the time, the most expensive real estate market in the world...  He said that, since these numbers were my responsibility, he certainly wouldn't present them to the board if I wasn't comfortable with them...

Flash forward a few years, to a massive effort to completely revamp a company's flagship client-server software product, requiring coordination between engineering teams in europe and the U.S., involving new technologies like WCF, Windows Forms, and ADO.Net, applying new development procedures like unit testing, FxCop oversight, and comprehensive code review for the very first time, and involving more than a few developers whose skills were... less than optimal.  I'd been pushing to have the entire local team work closely with the two of us who had significant .Net experience, to try to generate, as quickly as possible, an installable, functional UI shell, over a minimal (but architectuarally accurate) remote comms/data access framework.  This would let us iron out basic code quality, architecture, and dev. process issues AS A GROUP, and give us a more accurate basis for monitoring progress, as we gradually added features to a production quality base.  The project manager vetoed the plan, saying we couldn't have everyone working together on the same tasks, and that we had to come up with a detailed schedule.  Three years of tasks were therefore broken out, assigned to individuals to estimate, interdependencies carefully charted, and tasks then reassigned to DIFFERENT individuals for implementation.  Several months later, we had a collection of untested, independently-designed feature FRAGMENTS, which had yet to undergo a single code review, with no idea of when we might ever see a running executable representing the actual integrated product.  After the third panicked meeting in a single week, on how to address feature schedules already double their original estimates, with the discussion focused mainly on the possibly of cutting features (with a ship date still TWO AND A HALF YEARS AWAY), and the need to revise estimates and reshuffle interdependencies in MS Project, not to mention the PM's comment that she hoped she wouldn't have to cancel everyone's vacations for the duration of the project... I announced my resignation.

Reality doesn't conform to carefully "calculated" projections.  As a software project manager, your contribution is not to tweak Gantt chart or MS Project scenarios, but to help identify, and RUTHLESSLY ADDRESS, issues interfering with the optimal performance of your team, adjusting any initial estimates or predictions based on observed (hopefully, ever-improving) results.  No amount of estimation is going to help in the situation described above, without first establishing some actual BASIS for making estimates.  Developers still need to identify tasks, and provide estimates in no larger than half-day increments, but focusing mainly on the subset of features they are ACTUALLY PREPARING TO IMPLEMENT.  Unless you are building a virtual copy of a previously implemented product, involving the same group of individuals, working with identical technologies under the same process... you just have to accept the fact that any detailed time estimates farther than 3 months out are very likely to be VERY wrong, and adjusting those estimates shouldn't be treated as anything other than a natural, expected part of the development cycle.  Obviously, detailed estimates are intended to avoid a situation where you approach the "end" of a three year project, with no clear idea of when, if ever, the product will actually be ready to ship, and modern "agile" methodologies try to address this by advocating the creation of a production quality framework as quickly as possible, by prioritizing features to ensure the most important items are addressed first, by requiring all code to be fully tested and of shipping quality at the time it is written, by not saddling the project with subpar performers or senseless beauracracy, and by defining short intervals at which to re-evaluate the schedule and feature set, based on open, honest, evaluation of OBSERVED results.

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.