It's been a very interesting couple of weeks...

I attended the local .Net User's Group "Education Day" event covering the Model-View-ViewModel architecture pattern, presented by Microsoft's WPF Program Manager, Karl Shifflet, and Jamie Rodriguez .  Karl missed our breakfast meeting, but we arranged to talk on the phone, and he apparently thought enough of my e-mail summarizing some of the issues to forward it to HIS boss.  Microsoft dev. evangelist Bruno Terkaly has also forwarded some of my feedback on various topics, and we joked that I'd end up on some kind of internal list of "trouble makers" at Microsoft (I listen for the black helicoptors at night...).

My e-mail included the following: "Looking at forums and sites like StackOverflow.com and listening to questions at the end of presentations, you'll keep hearing confused developers asking "Do I need to learn Blend?"  "For data access, are we supposed to use ADO.Net, or DAAB, or Linq to SQL (and is that now deprecated), or Entity Framework (and what about the posted 'vote of no-confidence')...?"  "Are we supposed to REJECT the WPF architecture encouraged by VStudio in order to insert some MVPoo mini-framework?"  "Should we use MVPoo version A, B, C, or go with Prism?" etc. etc. etc.   Microsoft reps seem to treat these as trivial concerns because they are each focused on their own specific area of technology, not considering that a dev. team on an actual project is in the position of having to essentially investigate ALL the available options in order to pick the best approach for EACH area of technology (because their project involves data access, AND remote comms, AND a UI...), and they have to do this in the limited time available before a project is under active development, and they have to train all the members of the dev. team (who are generally NOT MVP caliber developers)."

The gist of our conversation was that Microsoft is aware of many of these issues, and has been discussing them internally.  Karl was also surprised to hear that Blend is NOT included in the professional-level MSDN subscription, and said he'd recommend changing that, which would be great.

I attended the first meeting of a local SilverLight User's group, hosted in Microsoft's San Francisco offices.  This was the first event I've ever been to, where the number of designers and design-related discussion had any kind of parity with development concerns.  Presenters included Scott Stanfield and other representatives from Vertigo, as well as design/devs from the San Franciso offices of the advertising firm, McCann Worldgroup.

I also attended the day-long MSDN Developer's Conference, billed as a "mini-PDC", covering updates to topics and technologies presented last September, and was honored/priviledged to be invited to attend not one, but two social gatherings, where I got to hobnob with Microsoft and local dev. community leaders, bending their ears on dev.-related issues -- especially after the first couple of free pints...  I reluctantly passed up a free pass to MIX, since I just can't justify the hotel and other costs at this time (and videos for the sessions will be available online anyway).

For the second time in as many months, I've gotten e-mail from someone who noticed my CodeProject posts, asking if I'd be interested in doing some WPF consulting.  This time the request came directly from the CEO of an east coast medical equipment manufacturer, and I've forwarded some WPF resource links that should help their devs get up to speed, and offered to put together a simple demo to illustrate some architecture and design options just for fun -- since many of the requirements don't seem all that different from another CodeProject demo I've been working on anyway.

My social calendar hasn't been this busy since college!  Even the ILLUSION of being included in serious dev. discussions has me hooked, as I discovered from monitoring, the "WPF Disciples" discussion thread.  You have to filter out alot of empty "banter", but I swear I learn something completely unexpected from that site at least once a week (variations on approaches to M-V-VM, markup extensions as a localization technique etc.), and it really makes you feel like you're sitting directly together with the people who will have the most influence in guiding the direction of the WPF platform.

"Princeton could USE a man like Joel."

     - Hope for all us unconventional interview candidates, from "Risky Business" 1983

I've been living off my incredible shrinking stock portfolio, hanging out in local coffee shops and restaurants with my laptop, working with WPF and other development technologies...  for too long now, and I'm itching to APPLY these new technologies and practices, to something challenging and interesting, working with people who are "smart, and get things done".

In addition to pointing out that I'll be starting my job search in the depths of a nation-wide employment freeze, friends have predicted that hiring managers will reject me because of my recent "sabbatical", but I think any company that would consider intense work with next generation development technologies on my own dime to be a BAD thing is probably one I wouldn't want to work at anyway 

I'm obviously delusional enough to think I can still afford to be picky, and there are some situations I'm really hoping to AVOID this time around...

• The New Number 6:  "This 'best practices' stuff all sounds very interesting, but right now what we really need is for someone to take over John's code.  We're down to five developers now that John got fed up and quit, no one undertands his stuff, and marketing has commited us to delivering a big stack of new features in eight months."
• How Hard Could It Be?:  "We can't spare any of our hardware engineers to spend a weekend knocking out this 'simple' software, so we want to hire you.  We've already done the hard part of defining the database schema, and we just need you to add a few things and get together with marketing to slap on some kind of pretty UI."
• Brain Silos: "Joe is designing data access, Tim is handling remote comms, Fred is responsible for security... you don't need to concern yourself with those issues, and they don't need to be a part of discussions involving your area."
• Plug-and-Play Developers:  "We're going to need to pull you and Joe off the project for eight weeks to jump on a new marketing request.  Remedial Roger's not doing anything right now, so he can fill in until you get back, and then maybe we'll have you split your time 60/40 between projects X and Y..."
• Sacred Tablets:  "I'm not sure what you mean by 'Agile', but we follow the process described in this 5 inch thick binder, written ten years ago"
• Invertebrates:  "Yes, we've all been saying for years how we should be doing X, Y, and Z, but what can we do?"

I have this fantasy where I work in an environment where we avoid doing things we already know are dumb before we even start, and where we actually FIX things we discover we got wrong along the way.  I'm not holding out hope for an environment as enlightened as Fog Creek, but a company should fall within some REASONABLE RANGE on these issues.

Some organizations believe they "can't afford" to spend time refactoring their development process, especially in the current economic environment, when its probably the adoption of a more streamlined iterative process, featuring cross-functional teams, relying on a smaller number of more capable individuals, that is likely to have the most dramatic long-term positive impact on a company's software development costs, schedules, and quality.

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 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.

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.