One thing that kind of bothered me in my recent CSM training course was a consultant's comment that he didn't feel any need to try to "sell" Scrum to resistant management, implying that, if they didn't buy into it, it was their loss -- but winning over management is almost certainly a big part of what developers in that organization are expecting a consultant to HELP THEM WITH!

Just as management needs some level of developer "buy-in" for a project to have any chance of success, anyone hoping to transition a traditional organization to Agile needs to be able to SELL the concept, in terms a traditional business manager can understand. "Just trust us" is the arrogant Agile counterpart to management's "Just do it" -- and about as effective.

Agile is a TOUGH SELL! You're asking what may be a whole STACK of non-programming middle managers to abandon established practices, to override PMP-influenced resistance (which may finally be diminishing, now that the Project Management Institute has begun to take an interest in Agile), to buy into subversive concepts like "self-organizing teams", based on rationale they typically don't have the first-hand development experience to understand... knowing that if it all goes wrong, THEY'RE the ones who'll be held accountable.

Emphasizing Agile's ability to deliver better quality software, much faster, using fewer resources (better, faster, cheaper) is critical to convincing management to at least give Agile a TRY, but avoiding an outcome that permanently DISCREDITS Agile requires knowing where you can compromise the "purity" of your model, while holding the line on items necessary for Agile to actually produce benefits. Setting up a system of code review and mentoring, to ensure code is kept clean, maintainable, and extensible, is more important than insisting a large team of developers with poor dev. skills write sloppy unit tests to support their convoluted code. Generating some amount of unecessary documentation is preferrable to having your product fail a customer audit, or to have your project remain unfunded by corporate managers who don't buy into your "trust us" argument.

To offer reassurance and manage expectations, you'll need to provide justification for the changes that will need to take place, be able to offer credible alternatives to traditional methods of maintaining accountability, and openly acknowledge potential areas of conflict (for example, Agile organizations typically require a smaller number of more highly-skilled developers, which may eventually lead to issues of what to do with long-time employees who are under-performing in a department which is over-staffed, under the new standard).

By choosing your battles, and focusing on a few key issues like obsessive attention to code quality, replacing Big Design Up-Front with a commitment to iterative "refinement" of an initial outline spec., sqeezing in at least SOME amount of regular customer proxy feeback (usually from a busy marketing rep. who doesn't understand why you can't just go off and build the entire app. as specified), limiting the number of items under development to force developers out of their silos and encourage them to collaborate, holding regular informal reviews to try to improve the dev. process based on observed results... you are surreptitiously "infecting" the organization with traces of Agile, so you can break down resistance and eventually take over the host.

Don't make the mistake of the last organization I was in, where we managed to get buy-in on adopting specific Agile PRACTICES (continuous integration, unit testing...), but failed utterly to get commitment to the more important Agile PRINCIPLES. Management still insisted that we begin a three year project by dividing all work into "tasks", which were distributed to 15+ developers in two globally-distributed teams to "estimate", despite the fact that only three of us had significant first-hand experience with the technologies we would be using, and many developers suffered from questionable coding skills... with disasterous results.

Kanban is interesting here again, because it seems better able to overcome initial management and developer resistence, by requiring only very minor changes to ANY existing development process (including waterfall), with teams reportedly adopting more and more agile techniques naturally, over the course of the project, as productivity improvements become obvious to everyone involved.

"The (Pirate's Code) is more what you'd call 'guidelines' than actual rules."

            - Captain Barbossa, Agile pragmatist, Pirates of the Carribean, 2003

One of the more confusing aspects of Scrum for me has been the fact that "adapting" Scrum to fit your team's specific circumstances is always encouraged... but doing something like applying the "Kanban" technique to Scrum upsets many traditionalists.

"The surprising thing for me is that many smart Agile people - people I know to be intelligent insightful people - seem bugged by Kanban... I'm seeing Agile people behave as strangely about Kanban as traditional process folks behaved about Agile. They seem threatened." -- Jeff Patton

I've had a hard time getting some Scrum fundamentalists to even DISCUSS why they feel certain parts of Scrum should be "off limits" to change -- a strange idea, considering that Scrum, as it is typically applied today, is already very different from the way it was originally described. This seems inconsistent with Agile principles that encourage change based on continued analysis and experimentation, especially since the majority of people applying Kanban seem to be experienced Scrum practitioners, who report great success with this Scrum + Kanban approach in solving real-world issues that their teams struggled with under "straight" Scrum.

There is a subculture of agilists who seem to promote an "all or nothing", "enlightened vs. heathen" attitude, reflected in statements along the lines of "if you're not doing X, Y, and Z (or if you try to add Q), you're doing it wrong and you're not Agile". Many senior Agile dev. community members have explicitly spoken out against this, as counter-productive and just plain wrong. Kent Beck included an apology in the preface to the second edition of his book, Extreme Programming Explained, specifically to try to address this for the XP community, and published works by other industry thought leaders including Mary Poppendieck, Alan Shalloway etc. have made similar points. IBM has pushed for ALL its developers to adopt SOME form of agile, while explicitly REJECTING the idea that you need to follow any specific set of practices or methodology.

The Dancing Agile Elephant: IBM Software Group's Transition to Lean and Agile Development

Having worked both in highly-productive start up environments, and some amazingly dysfunctional corporate beauracracies, I'm an absolute supporter of developing software in a way that's consistent with Agile PRINCIPLES, and it is frustrating to think, after finally convincing your corporate management to take a serious look at what Agile has to offer, they'll encounter a discussion space filled with a mixture of hippie-dippy idealism and bickering that's likely just to make them roll their eyes and dismiss the topic out-of-hand.

"Badges? We don't need no stinkin' badges!" - Blazing Saddles, 1974

I became a "Microsoft Certified Professional" (MCP) for .Net back in '03, got my MCP for WPF last summer, and just picked up a Certified ScrumMaster (CSM) badge, all of which means... SQUAT!

Any experienced developer can tell you an MCP certificate (or a CS degree) says absolutely NOTHING about whether someone can actually write production quality code or help a company ship products, and there's been some criticism over the way the term "Certified ScrumMaster" is sometimes promoted and abused. For the record, a Microsoft certification essentially proves you can memorize API trivia out of a study guide, and a CSM certification just says you've had two days of classroom exposure to the basic concepts of Scrum.

Of course, there's a LITTLE more to it than that. A Microsoft certification guarantees baseline familiarity with the recommended way to handle common Windows dev. tasks, and a CSM badge guarantees exposure to fundamental Agile concepts, along with a general idea of how to apply them, and obviously indicates a commitment to helping to refine a company's development process. When interviewing new hire candidates at my last three companies, I always asked about certification as evidence of some level of "devotion to craft", beyond simply working on "assigned features", but I was always more impressed if the candidate was familiar with notable developer community authors, or attended local dev. events.

From the job candidate perspective, certification is most useful in helping get past HR and other non-programming middle manager filters. From management's perspective, the risk in being overly impressed by a Microsoft certification is alot less than the risk of turning an inexperienced CSM loose on your enterprise organization's development process for your mission critical software. CSM training and resources often have a kind of naive idealism to them ("Let's play a game to illustrate collaboration!"), and I think a CSM who hasn't personally experienced harsh corporate realities is in danger of having management and technical staff quickly flip the "Bozo Bit" on them. For example, there's a HUGE difference in promoting "self-organizing teams" in an environment of top-notch, experienced, highly-motivated developers, versus in a bloated, complacent, corporate development environment.

I've been keeping up with Agile practices and approaches since the late '90's, and I'm currently most impressed by approaches that combine Scrum and Kanban, as described in Henrik Kniberg's newly-published "Kanban and Scrum, Making The Most of Both". The book is succinct and the clearest explanation I've come accross, of what all this "Kanban" stuff is that everyone keeps talking about, and how it relates to Scrum

Update (2/13): Scrum co-creator Ken Schwaber recently parted ways with the Scrum Alliance, and started Scrum.org to offer more rigorous developer training.

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

I've been meeting regularly with Bruno Terkaly, Microsoft Dev. Evangelist for Northern California, who has updated his WPF presentations to include discussion of issues I've suggested are important to developers moving to WPF -- but which always seem to be left out or misrepresented in Microsoft presentations and published resources.  Bruno has reported getting some "thank-you"s from audience members specifically related to the new material, just as I got "thank-you"s from developers in reaction to my original blog post on the subject.

WPF is a GREAT technology, but developers need open, honest discussion of the pain points they can expect to run into as they make the transition.  Examples of less-than-helpful guidance includes the often-repeated advice to simply "hand the project to the designers", while all the developers in the audience are wondering "WHAT designers?  We can't even get approval to hire TESTERS!"  Xaml is frequently portrayed as low-level tooling support, which can safely be ignored, while failing to mention that Visual Studio lacks design-time support for basic WPF features (DataTemplates, for example), and Expression Blend, which DOES offer support, is promoted as a tool for designers.  Any suggestion that developers avoid working directly with Xaml is especially unfortunate, since it takes just a few weeks to become completely comfortable editing Xaml directly, and this approach is MUCH more productive, and leads naturally to better-refactored, more maintainable markup.

After describing similar issues involving other Microsoft technologies, including difficulty in trying to make sense of Microsoft's recently-announced "Azure" cloud computing platform (Bruno says I can take credit for the fact that essential white papers are now grouped together and accessible when you click on the link labelled... er... "White Papers"), I was very kindly invited to attend an informal upcoming get-together of local Microsoft dev. community figures, where I'm hoping to compare notes.  I've also managed to finagle a breakfast meeting this weekend with Microsoft's Karl Shifflet, where I'll have the opportunity to discuss these issues directly with the WPF Program Manager.  Last night, I attended an excellent presentation on Azure, by David Chappelle, where I mentioned some of these issues, and was surprised to hear him express similar sentiments (confusion over the dual storage systems in Azure, the lame attempt to paint the lack of schema support as a feature instead of the honest -- and more palatable -- reality that ALL cloud vendors are adopting a very similar approach...).  He also seemed to agree with my impression that these issues are occuring more frequently, with evidence of development by independent teams (who don't talk to each other)... showing through at the seams.

I've suggested Microsoft could benefit from having internal developer ADVOCATES, focused on identifying and fixing these kinds of issues, rather than just developer "evangelists", who operate more as an extension of Microsoft marketing. Responsibilities for such a team might include...

• Working to identify and resolve sources of frustration and confusion in all public-facing content.
• Acting as a dev. community resource, soliciting reports of new issues, and maintaining a public (?) list of issues and their resolution status.
• Ensuring that cases where perceived issues are actually justified (or temporary), are clearly explained, as close to the start of the release cycle as possible.
• Using the history of reported issues to improve internal guidance for online documentation and SDK content and install experiences (including the possibility of relying more on pre-configured vhd images).
• Working to see that all mainstream documentation, sample code, tool-generated code, and public presentations, reflect industry "best practices", or that such information is at least mentioned alongside the usual focus on point-and-click solutions.

The idea is a little naiive, of course, and developers already have access to a wide variety of ways in which to report issues, but the current “scattershot” approach, leaving it up to each individual team to report and respond to issues in its own way, may be part of the problem.  A small team that served as the developer community voice INSIDE Microsoft, that was explicitly tasked with helping to identify and resolve these issues, regardless of which dev. or documentation group might actually be technically responsible for that particular area… could reduce frustration among Microsoft's target customer base, and probably also reduce the time dev. and marketing team members spend, having to repeat answers to the same questions, from a variety of sources.

I'm really enjoying the opportunity to discuss these issues with knowledgable people in the Windows dev. community, and I'd love to think that something in one of these discussions could trigger real change.

"Lead or follow, but GET OUT OF THE WAY!"

       - plaque on the desk of Ted Turner

I've worked with some really GREAT managers, several of whom had absolutely no software development experience.  Some were hardware engineers, some were from marketing, and some were just individuals with relevant domain expertise.  Qualities that made them great engineering managers included the ability to quickly grasp the GIST of technical issues, highly-developed BS-detectors, calm in the face of a need for decisions on the basis of limited information, the courage to say "no" to upper management when necessary (and the willingness to fight, to make it stick), intolerance of empty beauracracy, a commitment to the highest (practical) engineering standards, and acceptance of the fact that plans and predictions inevitably CHANGE, incrementally but continuously, sometimes right up until near the very end of a project.

A good engineering manager enjoys getting their hands dirty with the evolving product, and is able to provide constructive feedback like "I was playing with the product yesterday, and I noticed X, Y, and Z", or "How can we design feature A to be better than a similar feature in our competitor's product?"  A poor manager takes refuge in a filtered subset of second hand information ABOUT the project, in the form of tidy reports and spreadsheets and charts, and may go to great lengths to avoid commiting to a decision involving actual technical or design issues.  Unfortunately, over the course of dozens of projects, at half-a-dozen different companies, really good managers have been in the minority, and were often handicapped (if not initially, then after the first or second reorg.), by having to report to individuals farther up the chain who seemed to consider "management" to be a TITLE instead of an ACTIVITY.

Some managers become obsessed with being recognized as the primary source for all information and decisions on the project.  I once walked into a project manager's office, with print outs of bug reports spread out all over her desk, who complained she was being overwhelmed with issues reported by our publisher client.  Since I'd recently resolved several issues just by speaking directly with one of the publisher's engineers, I curiously leaned over to look at one of the reports, and she practically THREW HERSELF onto the desk, covering the print outs with her arms, as I sloooowly backed out of the office.  On another occassion, a year into a job at the Tokyo offices of a US investment banking firm, I was CC'd on email that revealed that a certain middle manager had been rewording requests for information from upper management, and then rewording my responses, in order to hide the identities of the original email authors and ensure that they remained at the center of all communication.  That would have been fine (if a little silly), except that they sometimes misunderstood either the original request or my response, creating confusion and wasting everyone's time.  Some dysfunctional managers insist on personally taking charge of presentations, or leading discussions, on issues with which they have only a very superficial understanding, where they hopelessly mangle key technical information, or sidetrack the proceedings onto irrelevant (but more familiar, non-technical) issues.

Managing software engineering is HARD!  Even skilled developers who take on a management role quickly lose touch with continually-evolving development technologies and best practices, and must depend on their top engineers for guidance on project decisions.  Identifying RELIABLE sources for information from among the development staff is especially difficult for non-technical managers, since it is easy for mediocre developers to fake a convincing level of expertise, while many of the best developers don't bother to cultivate the kind of basic social skills that engender management trust.  Some organizations resolve this by splitting management responsibility, giving a "Technical Lead" authority over a project's engineering-related issues (including issues which are not strictly technical, such as "Joe is not performing and needs to be taken off of the project"), while the "Project Manager" takes on a more administrative role, becomming responsible for shepherding issues through the corporate beauracracy so the engineers can focus on... engineering.

Iñigo Montoya: "Naturally, you must suspect me to attack with Capa Ferro"
  Man in Black: "Naturally… but I find that Thibault cancels out Capa Ferro. Don’t you?"
Iñigo Montoya: "Unless the enemy has e'studied his Agrippa… which I have."

       - how to spot REAL talent (in a fight to the death), from "The Princess Bride"

How can you identify the "Evil Mort"s, and the wrong kind of "Einstein"s, during an interview, in order to avoid hiring them?  Below, are the actual guidelines I recommended at my previous company (updated with .Net 3.0/3.5 references), which we used to evaluate new hire candidates for open .Net engineering positions.  I purposely used very open-ended questions intended to maximize the candidate's opportunity to sell themselves and demonstrate some evidence of passion, a willingness and ability to learn, and sensitivity to maintenance and process concerns... IN ADDITION to testing their understanding of .Net.  We needed candidates who were still able to support unmanaged C++ and MFC code, so each candidate first underwent a separate, fairly rigorous, C++ exam, and my portion of the interview didn't involve any actual coding.

New Hire Candidate .Net Interview Questions

We should be seeking PROFESSIONAL Windows developers – candidates who not only have a good understanding of .Net (as well as MFC and C++), but who are PASSIONATE about software, and who can also think in terms of ARCHITECTURE and development PROCESS.

Many of the questions below do not have “correct” answers. We’re looking for responses that demonstrate thinking beyond simply implementing assigned tasks (ie: “I think unit testing is a waste of time because…”, or “I prefer Lowy’s component focus to the inheritance focus in Microsoft’s class design guidelines because…” etc.)

General (10 mins):

1)  General questions, based on examination of the person's resume

What made them decide to leave companyA after 8 years? Why did they only stay at companyB for 6 months?  How many developers were on projectY? etc.

2)  Try to separate development technologies in which they have MEANINGFUL experience (and interest), from the usual dump of token resume keyword references.

Do they consider themselves to be primarily a C++/MFC developer with some .Net experience, or vis-versa?  Do they have more of a back-end, or GUI, focus?  Has their .Net experience primarily been with ASP.Net, or desktop clients?  Did their C++ experience extend into COM/ATL, or C++/CLI?  Any managed or unmanaged DirectX?  What experience do they have with specific remote communications and data access technologies? etc.

3)  What .Net authors/resources do they recommend, or consider to be required reading for developers, and why?  Do they track any RSS feeds?  If they can’t come up with any .Net examples, what about resources for other development technologies?  What was the last development-related book that they read?  How much experience with .Net 3.0/3.5?  Have they worked with LINQ, Lambdas, Blend...?  Have they heard of F#?  (ie: do they stay CURRENT with engineering practices and technologies?)

Qualified developers should know some of the Windows dev. community luminaries, and have definite opinions on good (and bad) books and online resources (favorite Blogs etc.).  I would probably expect them to name MSDN Magazine (certainly MSDN online), and at least one of Richter, Sells, Lowy, Petzold, Adam Nathan on WPF etc.  Non-.Net references might include Scott Meyers, Martin Fowler, Kent Beck, Bob Martin, Richter’s Advanced Windows, Don Box on COM, Prosise on MFC, MFC Internals…  More than any other question, I think this identifies desirable candidates.  Developers who are not actively keeping up with the evolving technologies are dead weight.

Attitude Check (20 minutes):

1)   What was the “best” project they were ever on? Why (what made it so good)?

We should see some evidence of PASSION in response to this, and the next question.

2)   What was the WORST project they were ever on?  What made it bad, and what should have been done to FIX it?

Developers who are passionate about software are constantly analyzing the development process, and will have strong opinions about how things OUGHT to be done – while still being reasonable about the need to accommodate trade offs for valid business concerns.

3)   What would they consider to be important coding guidelines?

They should express moderately pro-guideline feelings, and be able to list at least a few specific examples, such as not exposing member fields, not using magic numbers, avoiding multiple classes in a single file, some reasonable approximation for when method size could indicate a problem…  Ask how they would ENFORCE a coding standard.

4)   Determine the extent of the candidate’s understanding of (and attitude toward) modern STRUCTURED development cycle and process elements.

Ask them to describe the process they would set up to ensure successful delivery of a product, on a project staffed by a small team of junior developers, where they had been given complete authority over all aspects of the development process, able to define exactly what needs to occur, and in what order.  The candidate’s answer should reflect some reasonable middle ground between fascism and anarchy, and might include mention of requirements, design and specifications, code reviews, handling of change requests, unit testing, coordination with QA, milestones, the use of specific tools such as CruiseControl… and possible mention of MSF, Scrum, or other formal methodologies.  Do they like or dislike particular methodologies?  What conditions might cause them to increase or decrease the level of "agility" in their process? 

Base Line Technical (30 mins):

(Ask them to briefly identify, and expand on the significance of, terms they recognize in the list below)

A qualified candidate should be expected to be able to use many of these topics as a launching point, to describe related technical and process issues, whether it be the role of Design Patterns, or technical differences between .Net and MFC, or the trend toward process support in the IDE, implementation of the Dispose pattern etc.

• CLR
• Internal
• Delegates
• DRY
• Singleton (probe general knowledge/use of Design Patterns)
• UserControl vs. custom control
• Dataset
• Marshalling into UI thread
• Attributes
• NGen (probe knowledge of JIT compilation)
• Patterns and Practices Group (PAG)
• Refactoring
• lock(this)  -- do they understand the problems with this pattern?
• Test-Driven Development (TDD), or Behavior-Driven Design
• S.O.L.I.D
• Visual Studio Team System (VSTS)
• Enterprise Library
• Juval Lowy, Chris Sells, Jeffrey Richter… others?
• Reflection
• Xaml
• Extension Methods
• FxCop
• Lambda
• Dispose
• WCF/WPF/WF
• P/Invoke
• Continuous Integration
• Func<T,TResult>
• “Agile” Development
• CodeDOM
• DataTemplate
• ControlTemplate 
• LINQ 
• Blend
• Attached Property 
• MVC/MVP/M-V-VM  
• Routed Events
• EndPoint
• F#
• SOA

In terms of evaluating a candidate's performance in this "vocabulary" section of the interview, when the candidate sees "Singleton" in this list of terms, its expected that they will be able to identify it as a Design Pattern, and we can use this as a lead-in, to discuss the use of patterns in general.  If they display familiarity with the debate over the advisability of USING singletons, it shows that they are plugged into the developer community, and possibly gives some indication of the degree of passion they have on design issues (watch for overly-contentious foaming-at-the-mouth radicals).  If the candidate can discusss double-check locking in the context of a singleton, it provides some additional clues on the depth of their engineering expertise, and if they are aware that CLR rules for static constructors can eliminate the need for double-check locking, it suggests the candidate may be less likely to write unecessary code in ignorance of existing framework features.

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. 

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

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.