Annual Performance Evaluations for Programmers

Here is a template I use as a development manager. Please note that the categories are mandated by the company and are scored on a 1-5 scale (5 is highest) and then averaged for an overall score. The interpretations of the categories are my own as applied to a programming team.

Job Knowledge: Is an expert in both the technology and problem domain relevant to his job. Stays on top of changes to technology and leverages them to improve the timeliness and quality of his work without needing a supervisor to push.

Accuracy: Cases sent to testing by this programmer are almost never kicked back by the testing team for obvious problems. The code written by this programmer almost always has unit tests written that are sufficient in scope and code coverage. This person does not have to be reminded to go back and add unit tests and almost always writes test cases before writing new code.

Work Habits: This person understands and manages priorities extremely well without a lot of follow up required by the person who assigned or supervises the task other than status updates which should be timely, concise and communicative. Willing to put whatever effort is necessary in to get the job done.

Problem Solving/Decision Making: When obstacles present themselves, this person takes ownership and removes those obstacles to remain productive, but also knows when to involve their supervisor to get assistance in getting to the end of that task as expediently as possible. Further, they are an active force to removing obstacles for others. This person has a solid grasp of what issues can be deferred and which need to be cleared before progress can continue. This person is a frequently the catalyst that provides momentum to a project.

Interpersonal Skills: When conflict arises, this is the person who is the calming influence and often steps up as a mediator when tempers flare. In stressful situations they calmly assess the problem, avoid personalizing issues and focus on a solution. Others enjoy working with this person and they actively engage in behaviors that improve team cohesiveness. People frequently request this person to work on their projects.

Communication: Communicates in a manner that is timely, relevant and concise. This person goes out of their way to make sure that others are informed about things that are relevant to them and speaks up frequently as a proponent of more communication. Also important is the person’s ability to adjust the technical detail of their communications to the intended audience appropriately and phrasing things in terms of the other person’s needs.

Leadership: Promotes the corporate and departmental values even when the supervisor is not present. Is a source of peer pressure for doing things the right way instead of the easy way. Does not shirk confrontation when it needs to happen. Boldly steps out of comfort zone to stand up for integrity and quality.

Customer Service: They are the person in every meeting that brings up the customer. When customers have complaints or are being difficult, they instinctively take the customer’s point of view and start trying to understand and solve their problem instead of being dismissive, even when the customer is not around. Generally known as an advocate for the customer, especially difficult customers. The customer can mean both internal and external clients, but when these conflict this person always sides with external clients.

Training: Completed training plan with vigor and enthusiasm and exceeded it where possible. Frequently suggests training opportunities for others. Volunteers and takes the initiative to set up training for others in the organization on topics that they are familiar with. When receiving training, this person eagerly tries to distribute their knowledge out to others. When this person learns something or creates new code their first instinct is to leave a breadcrumb trail to lead others to the discovery.

Scoring Methodology: When I score them, I reserve the highest score (5) for people that not only exemplify the particular trait, but are also are a catalyst for improving others in that category.

A word of warning: Beware of metrics based performance evaluations. You will get EXACTLY what you measure and often in ways that are not what you’d expect. Programmers are especially good at finding ways to meet metric driven goals without furthering the underlying objective of the metric. For example, how many ways can you think to improve your LOC (lines of code) per week if you knew it would affect your compensation that don’t improve the product or speed of the project?

Advertisements

Is Agile for Amateurs?

I found myself discussing development practices with a manager of a local startup software company and was a little taken aback when he unequivocally proclaimed that they didn’t need agile because he had a team that consisted solely of extremely talented veteran programmers, with an average tenure of more than a decade.

He claimed they knew what needed to be done and did it without any official methodology. In these parts we might call that “Cowboy Coding.” His premise that following a standard methodology was meant for novice teams or those with immature programmers who hadn’t gotten “into the groove” of their careers.

Giddyup!

Before you trash the guy,  consider the following:

  • The guy and his team really were hardcore. It was chock full of developers that I’d love to be able to lure over to my shop.
  • This guy had bootstrapped several start-up organizations and is extremely technically competent for a suit.
  • He based this statement on demonstrable results, working software that apparently was popular with his customers.

How can you argue with results? Of course, I’m not absolutely sure about the veracity of his claims of success. In the context of our conversation it was conceivable he might have been exaggerating given that I currently work for a company that is a potential customer for his company’s product.

Personally, and despite these points I still tend to disagree. Even though he may be seeing success despite an unstructured development environment. I’d argue that the team may still be performing below their full potential and would still benefit from some flavor of an Agile approach.

It seems to me that Agile is better suited to teams with a lot of talent and experience, and if anything would be more problematic with a bunch of rookies. A core Agile concept is to let the development team self-organize, which implies a great deal of trust.  Agile is not about babysitting, and certainly not about command-and-control management. It is about communication, coordination, and frequent re-alignment with an emerging picture of the customer’s needs.

I’m curious what you guys think?

19 Tips for Recruiting Great Developers

1. The big job boards like Monster and Dice have become practically useless for hiring top tier talent.

It is easy to quickly obtain a pile of resumes using these services. However, this approach will have you shucking a heck of a lot of oysters to find a truly great Perl programmer. Several professional recruiters I know have given up on these boards except for staffing entry level positions like help-desk and phone support jobs. The odds of finding the proverbial rock star programmer on Monster are growing increasingly slim.

2. Niche job boards will get you qualified leads, but not very many of them.

High-end job boards like TheLadders charge a fee to the candidates and are as much a den of recruiters as the mainstream sites.  I find it hard to believe that top-tier talent is likely to pay to be listed on a job board.

Caveat: I have not personally used TheLadders as part of my recruiting efforts, but did briefly have a subscription as a candidate.

The really niche job boards like the one at JoelOnSoftware do a good job at pre-qualifying the candidates through self-selection, but maybe too much so.  I’ve listed a few jobs on this site for opportunities in Austin that generated almost no response. I suspect this is a better tool if you are in a bigger market like NYC or the silicon valley.

Actually Joel’s board does have a compelling strategy to draw higher quality candidates:

  • Trim back recruiter nonsense by forcing the advertiser to disclose in the ad who the candidate would actually be working for.
  • Asking advertisers to post their Joel’s Test score. Candidates who care about this are more likely to be passionate about their craft.

Despite my limited success with it, I’d still recommend the site given that there really is no financial risk.  I can personally attest to Joel’s “If it doesn’t work, you don’t pay” guarantee. We got our money back promptly with no hassle when the listing didn’t net any interview-worthy candidates.

3. Use LinkedIn Strategically

I have it on good authority that LinkedIn is a pretty strong source of candidates who are only passively looking and currently employed, which are generally traits of the better candidates. However, programmers don’t seem to frequent the job board on this site  as much as sales and management types.

That said, I  can’t really vouch for its job board when looking for developers based on my experience. However,  never before have you had such unprecedented access to the innards of another company’s org chart as LinkedIn provides. A few quick searches containing the name of  other companies in your industry will usually reveal developers with relevant experience in your industry.  This site is also used as a stealth way of looking for another job for people who don’t want their employer to catch them on a job board.

I was just NETWORKING, I promise!

4. The best candidates aren’t going to come to you.

There are exceptions to this, but I’m betting that you wouldn’t have read this far if you are recruiting within a company that the best programmers already yearn to work for. This advice is for the rest of us who don’t have the luxury of offering a job that would be a showstopper on a resume or turn heads at RenFest / Comic-Con.

Some managers, especially new ones, whose only experience with recruiting has been as a candidate desperately seeking an audience with a choice company, have the impression that their role as a hiring manager is akin to sitting atop a throne as candidates compete for their favor.  Not exactly.

There is a pool of candidates who are going to come to you, and their names will quickly become familiar because they will apply to every job posting you open even over several years. In most cases, there is a reason that someone else hasn’t snapped up these people and absent evidence to the contrary you probably don’t want to hire them either. If you aren’t willing to be proactive in your search and sometimes take on a more subservient posture when dealing with candidates, you are eventually going to force yourself to choose from this pool.

The top guns may only hit the open job market once in their careers, and from that point forward get subsequent jobs through networking, which brings me to my next point.

5. Networking is as essential for you as it is for the candidate.

Networking as a job-hunting strategy is a no-brainer, right? So what are you doing to make sure you are on the other end of that network for the right candidate?

Your existing team of developers is often a great entry point into a pretty substantial network of developers. Referral bonuses are the tried and true way to enlist employee help with the recruiting process, but often the prospect of working with a favored peer is a more powerful motivator.

Other benefits of this approach include:

  • The person who made the referral will to be invested in the success of the employee and likely will take an active role in bringing the new person up to speed.
  • Barriers to acceptance into the team will be reduced because the new person already has a relationship with at least one person.
  • You are more likely to get a true picture of what you are getting with the candidate without as much puffery as you might get interviewing strangers.

Warning: This doesn’t work so well with the mediocre programmers. The best developers try to hang with people smarter than themselves. Mediocre ones will seek out people to make them feel smarter. Don’t hire the wing-men.

6. Focus your search on finding developers, not job hunters.

Employers are going to hang on to their best people and keep them away from recruiters, recruiting events, and by extension you.

I’m not trying to imply that their bosses are actively prohibiting them from these types of contacts, but rather that they work hard to keep them happy and busy enough to not even try.

Developer conferences and user groups are a great way to contact engaged developers who may not be actively looking for work. They even triage themselves into sessions so you can more readily identify them by their area of expertise.

The best emissary to send to such an event is a development manager or supervisor. HR types are going to scare away the fish by being too sales-y and saying things like “Do you know Sea Pound?” and many programmers tend to be too introverted to make a lot of contacts.

I’ve a friend who recounted a tactic that had worked well at these events for him. He wore a t-shirt to the conference that read: “I’m hiring developers.”

7. Programming competitions

If you need a lot of developers and want them to triage themselves by skill AND aptitude, you might try sponsoring a programming competition. I’ve no personal experience with this approach, but I’ve seen a number of companies try it.

It definitely sounds good, but be careful to understand what you are looking for. These competitions seem to appeal to people who love puzzles, and those are types of programmers can often exhibit a pathology where they like tinkering and optimizing at the expense of getting a good-enough solution out the door.

8. Don’t expect to pay median salaries for top talent.

Often I see companies that claim to hire only the best, but their HR people argue that they should only have to pay the median salary as determined by salary surveys. Try that argument at a jeweler or sports car dealership and let me know how that works out.

How can you charge $200K for that diamond necklace when I can prove that the average piece of jewelry retails for $150?

If you want the top 10% of developers, you should expect to pay at least in the top 25 percentile, and you are only going to get off that cheap if you bring something else to the table like a cool product to work on,   good benefits, private offices, or some other perk.

9. Get the muggles out of the process as early as possible.

If at all possible, don’t force the candidates to endure even a phone interview with a non-technical person. If you can’t avoid it, at least strip out any technical questions from the interview script that the person performing the interview doesn’t understand well enough to talk about competently.

Let HR/Recruiters manage the scheduling, resume screening, benefits discussions, etc. , but don’t give them a phone interview script with technical questions and let them lose on the candidate.

10. Be flexible with your requirements.

If you need a .NET developer, don’t be a stickler for C# or VB.NET. The best programmers can become quickly proficient in just about any language, make sure that the person screening resumes understands what keywords are acceptable substitutes for the ones in the job description.

11. Branding is not just for cattle and marketing.

Branding is the act of creating and maintaining a positive image to grease the skids for selling people on your team or company. It is often confused with advertising, but it is a distinctly different animal. Branding is about managing your reputation and advertising is just one means to that end.

Creating an identity for your team that is attractive to potential recruits not only helps with sourcing candidates, but also adds ballast to your side of salary negotiations.

Brand characteristics that resonate with developers:

  • We have and hire the best developers – Top developers want to work with other top developers.
  • We work on cool products that your friends and family will be familiar with.
  • Our company is a meritocracy that values technical know-how above politics.
  • Our team keeps up with the latest technology and invests in training for developers.

Some techniques for advertising and reinforcing your brand:

  • Sponsoring developer conferences and events
  • Developer Oriented User Groups – Often you can get a plug on the cheap by buying the pizza or contributing a few give-away items like t-shirts or books.
  • Support Open Source Projects under the name of the company.
  • Offer unusual perks that appeal to programmers and then submit a press release about it to local media outlets.

12. Understand your needs and recruit for that.

This seems too obvious to mention, but is probably the easiest mistake to make. Clearly define what you expect the new hire to do every day and hire someone that can do that job every day and enjoy it.

Some guidance in this area:

  • Don’t hire based on interviewing skills unless you need a sales guy.
  • Don’t hire based on management skills unless there is potential for them to lead or manage in the near term.
  • Don’t hire a clone of yourself or your best employee, you already have that. Hire someone that complements what you already have.
  • Hire for what you need NOW, not what you think you will need later.

13. Ignore your instincts during the interview

Your tendency during an interview is to form an opinion quickly at the start. Your mind is wired to preserve its own worldview and will often fight against all evidence to protect that initial judgment.

To remain objective and overcome jumping to conclusions, consciously decide to go harder on the people you like and easier on the ones you don’t. Otherwise you will be inclined to do the opposite and just reinforce a your initial impressions and waste a chance to learn more about the person in front of you.

14. Trust your instincts when making the final hiring decision

Trust your gut whenever you are the slightest bit uneasy.  At my own peril I have several times learned the hard way that losing a good candidate is far preferable to hiring a bad one. For the dozens of people I have hired in my career, there have been a number of people I was sure would be great and turned out to be just so-so, but  I have never hired someone that I was unsure about that turned out to be a great employee.

At each step of the process separate your candidates into two piles:

Yes: From what I know so far, I could hire this person without reservation.

No: Everyone that doesn’t pass the criteria for the yes pile. Includes anyone who is a “Maybe” or a “Yes, but…”

15. Just say no to puzzle problems.

First, see item 7  about the problem with logic puzzles.

Second, these things tend to annoy really good programmers who don’t like make-work or meta problems.

Don’t kid yourself that “you just want to see how they think.” Knowing that someone can come up with a clever way to estimate the number of boat trips required to determine which switch turns off Mt. Fuji is fun conversation, but a waste of everyone’s time.

Alternative approaches to evaluating a candidate:

  • Rough-out an application architecture on the white-board for this scenario.
  • Role-play with them a troubleshooting scenario for a challenging problem you have worked through.
  • Get code samples.
  • Ask them to describe an application they have built and ask probing questions to make sure you understand their level of contribution to that project.

16. Write an interview script and test it on your current team

Write interview scripts (for each job title/level) and keep your notes for each candidate.

Good reasons to use standardized interview script

  • Less room for ad-hoc questions helps you avoid favoritism (see #13).
  • Documentation of  equal treatment of candidates to defend against potential hiring discrimination claims.
  • Easier apples-to-apples comparison of candidates..

Tips for refining your interview script

  • Test it on current employees – Did it draw out the important positive and negative aspects of that employee? Tweak it until it does.
  • Get current employee feedback on the script – Any offensive/insulting questions? Do they think it would help or hurt the perception of the company for the interviewee?
  • Review your interview notes one year after the hire. Were there any surprises? Tweak the script to prevent similar surprises next time.
  • Review your script for and remove questions that require  specialized knowledge that only a current employee would have.

17. Don’t leave people hanging.

If your company’s recruiting process is interminably slow and out of your control, take it upon yourself to call your short-list candidates and frequently re-assure them that things are progressing. The best developers are going to be highly recruited. Don’t assume that just because someone submits a resume that they are somehow locked-in and will be forced to give you first right of refusal.

I’ve heard and been part of stories of companies calling back EIGHT MONTHS after a resume was submitted to ask for an interview. This is crazy. Even if by some miracle that person was still on the market after that long, clearly they have been passed over by just about everyone else in the interim. Why would you even want them after so much time has passed?

18. Recruit former employees

Face it, your top people get recruited heavily and eventually will jump ship to see if the grass is greener, even if it isn’t.

Good employees that have left your team in are a great source of new hires for several reasons:

  • You know what you are getting and so do they.
  • Previous employees can become productive much more quickly.
  • You can recoup some of your previous training investment.

Even if you can’t convince them to come back, the fact that you want them back is an ego boost for them and will often create some goodwill and improve your branding by creating an advocate that works with a lot of other developers who you might be interested in recruiting.

Some preemptive steps to increase your  odds of re-hiring a good employee later:

  • Give them a final chance to give honest feedback about the aspects of the job they didn’t like and communicate your desire to fix those things for the rest of the team.
  • Organize a happy hour and give them a great send-off.
  • Give them a souvenir of their employment to take with them that will remind them of their friends at the job.
  • Keep in touch, and not just when you need something.
  • Call to ask how their new job is going and solicit advice on things they like about the new job that you could try.
  • Continue to make sure they are invited to happy hours to keep the ties with their former co-workers strong.

I have re-hired several employees during my career as a software development manager who have turned out to be some of the best programmers on the team.

19. Mind your karma and don’t make enemies

Don’t be an ass when developers leave the company, whatever the circumstances. It doesn’t matter if you never want to see this person darken your doorstep again. Also, treat every candidate who took the time to apply with respect, even if they were completely unqualified. Word of mouth is a powerful thing and this industry isn’t as big as you might think. Chances are that these people will talk to someone about your company that you one day will want as an employee or customer.

The unspoken truth about managing geeks (Article Review)

Just finished reading “The Unspoken Truth about Managing Geeks” written by Jeff Ello and was blown away by how insightful his assessment of the psychology of IT workers was and how gosh darn practical his advice was on structuring an organization and managing technical people to maximum effect.

This is not just another blog article that rehashes something we already know, it is a refreshing new look on the consequences and reasons for behaviors and attitudes that we observe and identify with in our careers programming or managing programmers.

I encourage you to read the entire article, but here are some choice bits that really hit home for me.

“Few people notice this, but for IT groups respect is the currency of the realm. IT pros do not squander this currency. Those whom they do not believe are worthy of their respect might instead be treated to professional courtesy, a friendly demeanor or the acceptance of authority. Gaining respect is not a matter of being the boss and has nothing to do with being likeable or sociable; whether you talk, eat or smell right; or any measure that isn’t directly related to the work. The amount of respect an IT pro pays someone is a measure of how tolerable that person is when it comes to getting things done, including the elegance and practicality of his solutions and suggestions. IT pros always and without fail, quietly self-organize around those who make the work easier, while shunning those who make the work harder, independent of the organizational chart.”

Ego, as it plays out in IT, is an essential confidence combined with a not-so-subtle cynicism. It’s not about being right for the sake of being right but being right for the sake of saving a lot of time, effort, money and credibility. IT is a team sport, so being right or wrong impacts other members of the group in non-trivial ways. Unlike in many industries, in IT, colleagues can significantly influence the careers of the entire team. Correctness yields respect, respect builds good teams, and good teams build trust and maintain credibility through a healthy projection of ego. Strong IT groups view correctness as a virtue, and certitude as a delivery method. Meek IT groups, beaten down by inconsistent policies and a lack of structural support, are simply ineffective at driving change and creating efficiencies, getting mowed over by the clients, the management or both at every turn.”

The victim mentality — IT pros are sensitive to logic — that’s what you pay them for. When things don’t add up, they are prone to express their opinions on the matter, and the level of response will be proportional to the absurdity of the event. The more things that occur that make no sense, the more cynical IT pros will become. Standard organizational politics often run afoul of this, so IT pros can come to be seen as whiny or as having a victim mentality. Presuming this is a trait that must be disciplined out of them is a huge management mistake. IT pros complain primarily about logic, and primarily to people they respect. If you are dismissive of complaints, fail to recognize an illogical event or behave in deceptive ways, IT pros will likely stop complaining to you. You might mistake this as a behavioral improvement, when it’s actually a show of disrespect. It means you are no longer worth talking to, which leads to insubordination.”

“Insubordination — This is a tricky one. Good IT pros are not anti-bureaucracy, as many observers think. They are anti-stupidity. The difference is both subjective and subtle. Good IT pros, whether they are expected to or not, have to operate and make decisions with little supervision. So when the rules are loose and logical and supervision is results-oriented, supportive and helpful to the process, IT pros are loyal, open, engaged and downright sociable. Arbitrary or micro-management, illogical decisions, inconsistent policies, the creation of unnecessary work and exclusionary practices will elicit a quiet, subversive, almost vicious attitude from otherwise excellent IT staff. Interestingly, IT groups don’t fall apart in this mode. From the outside, nothing looks to be wrong and the work still gets done. But internally, the IT group, or portions of it, may cut themselves off almost entirely from the intended management structure. They may work on big projects or steer the group entirely from the shadows while diverting the attention of supervisors to lesser topics. They believe they are protecting the organization, as well as their own credibility — and they are often correct.”

“Unlike in many industries, the fight in most IT groups is in how to get things done, not how to avoid work. IT pros will self-organize, disrupt and subvert in the name of accomplishing work. An over-structured, micro-managing, technically deficient runt, no matter how polished, who’s thrown into the mix for the sake of management will get a response from the professional IT group that’s similar to anyone’s response to a five-year-old tugging his pants leg. What IT pros want in a manager is a technical sounding board and a source of general direction. Leadership.”

Finally, executives should have multiple in-points to the IT team. If the IT team is singing out of tune, it is worth investigating the reasons. But you’ll never even know if that’s the case if the only information you receive is from the CIO. Periodically, bring a few key IT brains to the boardroom to observe the problems of the organization at large, even about things outside of the IT world, if only to make use of their exquisitely refined BS detectors. A good IT pro is trained in how to accomplish work; their skills are not necessarily limited to computing. In fact, the best business decision-makers I know are IT people who aren’t even managers.”

The unspoken truth about managing geeks

Poll: Where does software Q/A belong in the org chart?

A critical element of creating a successful software development team is identifying and implementing an organizational structure that encourages collaboration, creates accountability, and enhances morale-improving positive self-efficacy for both testers and programmers.

Of particular interest and substantial debate within my company, is the optimal relative placement of the QA/Testing and programming functions in the org structure. I am working on an article discussing the issues, trends, and best practices for setting up a software development team. I’d like my readers to share their experiences and opinions as fellow managers, testers, and developers on the topic to include in my findings.

Thanks in advance for your participation.

Poll 1: Your reality.

Poll 2: Your ideal.

Further Discussion

Please use the comments area to provide any additional detail on your answers or discuss related topics, such as:

  • Does a particular structure work better for different types of development activity (internal, product, consulting, etc)?
  • For organizations that place the programmers closer to the testers, how do you maintain checks-and-balances?
  • For organizations that separate programmers/testers more, how to you encourage collaboration and information sharing?

Age Discrimination and Programming Jobs

As my personal odometer clicks over to 38 today, I’m thinking about the very real concern of age discrimination in the technology field where many would consider a person wizened at 40. The legal and political considerations associated with this issue make it a very touchy subject that encourages many to tread lightly or avoid discussing it entirely. This is unfortunate, because for both the job-seeker and hiring manager, passive acknowledgement that age-bias is a factor does little to remedy the situation. This Tauran is going to stampede through that china shop and confront the issue head on with in a frank discussion about older programmers and the recruiting process. Along the way I’ll provide advice to both managers and job hunters for overcoming bias that can result in unfair and illegal discrimination.

Let’s start with what I admit is an unabashedly controversial opinion. It is my belief that, for programmers, age discrimination is more pervasive than either racial or gender discrimination during the hiring process. The basis of this sentiment is rooted in the demographics of the software development community which is predominantly comprised of male employees that are on average younger than the labor force in general (McConnell).

I suspect that hiring decisions made and influenced by younger managers who were raised during a period of increased emphasis on achieving racial equality in the wake of the civil rights movement are less likely to reflect race based bias than those of their elders. Further, it is likely not uncommon for the typical young, socially awkward, male software engineer to sometimes give an edge to qualified female candidates if only for some respite from the homogeny of his peers. That said, I also think that older female candidates are victims of more discrimination than older male candidates.

Do you feel me on this? If so, we are both guilty of exposing a personal bias that younger workers are less likely to discriminate in their hiring practices and men as a group are generally prone to using their status as a hiring manager as a personal dating service. While it is certain that both of these preconceptions must be true for some element of the workforce, it is equally true that they are not universal, and it is ambiguous about whether these characterizations are even widespread. The important consideration here is that each of us harbors at least a few innate personal prejudices, and there is a good chance that some of them are going to be inaccurate.

The Two Question Technology Bias Test

Even if you didn’t take the bait on that first point, consider the assumptions at play in the following two question quiz.

(1) What Operating system does the man in this photo prefer?
Guess my favorite OS!

(2) What makes the following image humorous?
Unix Girls on the Beach

Despite what the guilt mongers would have you believe, prejudice, discrimination, and bias are not fundamental human failings that are uniquely modern and need to be worked out of the system. Instead, instead they are shortcuts wired into our primitive brains that allow us to apply a probabilistic model based on our own experience.

In a survival sense, it provided competitive advantage for our ancestors to assume that a particular lion is prone to violence based on their experience with a completely different lion eating a cousin’s face. The types who argued that maybe this new lion seems nice and deserves a fair shake probably didn’t fare as well as the lion-ist jerk who didn’t trust anything with six inch incisors. Given the eons it took to condition this into us, I don’t think it is feasible to eliminate it from our nature.

Although you can argue that the lion-prejudice pattern is outdated and no longer applicable. Consider the more modern practical applications of bias for programmers in the refactoring movement. Code Smells are little more than prescribed bias against certain coding elements that may or may not indicate real problems. I am not going to go all Gordon Gekko on you and declare that “Bias is Good.” I am just trying to say that in the appropriate context bias can be beneficial.

Conscious acknowledgement of preconceived notions and being vigilantly objective despite experience is critical, however, for managers making recruiting decisions. For the candidate, who is unlikely to suspend the well-shorn biases of society for the duration of an interview, mitigation strategies are in order.

Continue reading

A Manager’s Retrospective on the C# versus VB.NET decision

There is no shortage of discussion or flame wars weighing the relative merits of the various Microsoft .NET programming languages, nor is there an outcry for another opinion on the subject. This article will instead discuss the process of making a sound business decision on a controversial issue without inciting mutiny among the developers. More importantly, I’ll revisit some of the key considerations in that decision through the razor sharp focus of hindsight. It is my hope that my experiences from the trenches will provide guidance to software development managers who have not yet made the jump to .NET, are bootstrapping a new shop, or are considering a switch from another platform.

It’s been just over six years since I managed the transition of my development team to Microsoft’s .NET platform and made the call, for better or worse, to standardize on VB.NET. As a developer myself, I was keenly aware of the how the programming language of a software development shop defines its culture and similarly shapes the professional identity of many programmers. The polemic among developers created a real risk of breaking down the team dynamic through second-guessing and deflated morale regardless of my choice. As is the case with implementing any politically sensitive change, the prudent course of action was to aggressively seek buy-in by actively soliciting input of each team member, remaining visibly objective, and maximizing the transparency of the issues that factored into the final decision. Despite the lack of unanimity requiring over 30% of the team to acquiesce on this hot-button standardization issue, the team dynamic remained strong after my final decision.

The Players

Although the list of languages that are currently supported on the .NET framework is more diverse than most would probably imagine, the options were far more limited back in 2003.

C#.NET: A hybrid of C and Java that attempted to lure defectors from the Java camp to the .NET platform. It also provides an easy transition for C++ refugees who are sick of the annoyances of manual memory management and having 9 incompatible ways to implement a simple string.

J#.NET: Most of the quirks of Java and none of the cross-platform support and about as useful as non-alcoholic beer. Enables developers to pretend they still hate Microsoft, but participate in their market share. Also allows Microsoft to pretend that C# wasn’t a blatant attempt to crush the upstart Java language that threatened to weaken their dominance of the OS market. The technology pundits have moved on to other issues enough for Microsoft to silently drop support for J# from Visual Studio.

VB.NET: The next generation of the popular Visual Basic language, all grown up and fully OOP capable. It is unfortunate that Microsoft didn’t take this opportunity to rename the language to remove the stigma associated with programmers using this language that only resembles its forebears in its verbosity. I assume they kept the name to provide an unambiguous upgrade path for the unwashed masses of VB6 programmers many of which ironically and belligerently dug in their heels and refused to upgrade.

C++.NET: For a while I assumed that I must have been missing something with respect to C++.NET. The juxtaposition of the venerable I’ll-roll-my-own-thank-you-very-much C++ and the don’t-worry-your-pretty-little-head-about-cleaning-up-that-memory .NET framework felt even more awkward than “Java.NET.” I took a course to absolve me of my silly notions, but only managed to reinforce them. C++.NET is neither fish nor fowl. It is like a halfway house for recovering masochist programmers who really want to like automated garbage collection, but want to take it one day at a time. Just one more hit of STL, I promise I’ll quit tomorrow! In one of the rare parallels with the VB camp, many of the Microsoft Visual C++ developers found little motivation to abandon Visual Studio 6.

The Contenders

Let’s face it. Aside from C#, VB.NET, and their ugly cousin C++.NET, none of the remaining .NET languages were used for much more than  Microsoft demos to prove that they wanted to support open standards. This was even truer back in 2003 when I was weighing the options. The team divided itself naturally into a C# and VB.NET camp and no one even hinted at seriously considering a third option.

The Process

It is extremely important when soliciting input from employees to be very clear about how the final decision is going to be made, especially when it is not the purely democratic process that they might otherwise assume. Recognizing this, I was careful to communicate that while everyone’s input was valued and would be carefully considered, I’d be making the final decision based on both the advice of the team and the interests of the business. I promised complete transparency on my decision and a chance to appeal it on factual, but not subjective grounds. As it happened, no such appeals were proffered. The C# proponents were slightly disappointed, but were also thankfully supportive the decision to go with VB.NET.

My solicitation for input included the following:

  • Provide as many supporting arguments for your preference as apply to our environment.
  • Arguments based on business objectives (reduced cost, greater efficiency) will be weighed more heavily.
  • Performance comparisons between the languages had been researched and dismissed already, don’t bother including them.
  • It is perfectly valid to support your preference in terms of your personal goals (money, prestige, taste, etc.).
  • Regardless of whether you can support your preference, please indicate it in your response. Morale impact is a key consideration.

Facts, Factors and Opinion

After compiling my own research, business case analysis, and the collective wisdom and opinion of my team, the following key themes emerged.

  • Functionality (TIE): Functional differences between the capabilities of these languages were primarily cosmetic/syntactic/irrelevant(Appleman/Atwood), MSDN.  There were a few IDE features that one language or the other had the edge on, but MS was already promising IDE parity in future releases.
  • Learning Curve (VB.NET): Because our previous standard was VBScript for ASP pages, and VB6 for the middle tier object layers, VB.NET seemed like the quickest path to productivity. I was particularly concerned about the impact of forcing the developers to make the jump to a completely different language at the same time they would be also required to get up to speed on the .NET framework and ASP.NET.
  • Existing Code (VB.NET): We were maintaining a significant amount of existing VB6 and VBScript code that would need to be ported to .net. Visual Studio provided tools to automate most of the conversion from to VB.NET, but considerable extra time would have been required to go to C#.
  • Product Road maps for .NET languages (VB.NET): An MSDN magazine article comparing the road maps for the two languages indicated that VB.NET was going to continue to be optimized for rapid application development while C# would follow the tradition of C++ and trend towards power-user features. The direction of VB.NET was more relevant to our development efforts which were mostly on CRUD type applications.
  • Developer Preferences (VB.NET): Despite the tendency of most to gravitate towards the familiar in platform wars, C# had a good showing. The balance was tipped by a few developers who had already started down the VB.NET track of their MCSD certifications. I hate to reinforce the stereotype, but it was interesting to note that the more senior developers were mostly in the C# camp.
  • Developer “Street Creds” (C#): Almost all of the developers subscribed at least weakly to the popular notion that C# experience would command a higher premium than VB.NET by riding the coattails of C++ as a more respected language. Whether justified or not, it appears that this rumor has become fact.
  • Product “Street Creds” (C#): There was also some concern that the “taint of VB” would hurt the perceived professionalism of our software among our customers. I have not yet seen evidence of this, however, we don’t advertise the language we use, and our customers don’t generally ask or care.
  • Recruiting (TIE C#): There was a lot of discussion that MS was strongly favoring C# as the language of choice for .NET and that most developers were following suit. I was somewhat concerned about the possibility of VB.NET becoming marginalized and creating recruiting hurdles. That is, if VB.NET became uncool, it might be difficult to get people to respond to our job postings even if we didn’t discriminate against people with only experience in other .NET languages. On the other hand, I reasoned that we might be able to avoid paying a “C# premium” that didn’t guarantee any associated additional value add over a competent VB.NET programmer. I think that predictions of VB.NET’s demise were very premature as it continues to have a solid following. However, in retrospect, I think I underestimated the impact of the decision on recruiting. I suspect that some of our recruiting difficulty (even with very competitive salaries) can be attributed to the fact that VB.NET developers readily apply to C# jobs, but the reverse is not as common.
  • Language Obsolescence (Non-factor): A small contingent was even predicting that Microsoft planned to phase out VB.NET in favor of C#. I just didn’t buy into this notion given my experience with how slowly Microsoft has retired product lines in the past. It took them 27 years, for example, to retire FoxPro after acquiring it, and salvaging it for parts to include in their competing database package, MS Access. So far it appears my skepticism was warranted.

Recommendations

As I have already mentioned, our team went with VB.NET. I still think it was probably the right decision given the skills of my existing team and our considerable investment in legacy code in VB based languages, despite the minor difficulties it has created for recruiting. Absent either of these preconditions, however, I definitely would suggest a preference for C# for any manager going through this decision today. That said, this article is no substitute for your own research. As is the case with any heated topic, there is an abundance of misinformation, some of which may even be repeated by members of your own team. One resource that I have come to trust over my years in this industry is Dan Appleman, who has published a highly regarded e-book, Visual Basic .NET or C#, Which to Choose? (VS2005 edition).

The lesson that can be drawn from my experience, however, is not so much about a preference of one language over the other, but instead the importance of involving the whole team in the change management process. This decision has major ramifications on their professional careers that extend beyond the walls of your organization and has the potential to create significant anxiety among them. Manage that anxiety by including them in the process, making it clear that their individual interests are being carefully considered, and the making the decision objectively and transparently as possible.

Links to the Fray