Archive for the ‘management’ Category

Rating Programmers

Saturday, March 14th, 2009

The Programmer Competency Matrix is an insightful tool to aid in objectively rating programmers in terms of ability when you have no history of results, like in an interview.

In computer science, however, they are missing Boolean algebra and discrete mathematics which are prerequisites for successfully working with data structures and algorithms. Also, in Software Engineering, I’d like to see levels of ability in risk management. Those two nits aside, this matrix is a handy tool to objectively rate interviewees or ranking software engineers by ability within an organization (e.g. associate, senior, principal, architect, fellow, etc.). Too often people are rated subjectively on the wrong criteria, for example: easy to work with rather than the results they produce and the abilities they possess. A tool like this can help you get over objective rating.

In my experience, titles do a have a function; they communicate to people outside your organization what you do and the level in which you contribute. Markup to the titles like senior in senior software developer, has little value. The meaning of associate, senior or architect is so subjective, they tell you nothing. When I look at a business card and I see the title senior software developer, I ignore the prefix (e.g. senior) and only assume they work with software. This is a side-effect of pervasive subjective ratings and a lack of tools to objectively measure ability.

When selecting a method to rate or rank, there’s a temptation to make it so clear, you don’t have to think. The idea is the perfect solution will arrive at the same conclusion every time. However, the best solution frequently arrives at the right conclusion much of the time. Implementing a black-or-white rating scheme invites people to “game it,” or put another way, algorithmic rating invites sub-optimization. A great example of inviting sub-optimization is in a BusinessWeek article, “Data Mining Moves to Human Resources” (via Slahsdot). The articles describes how Cataphora uses algorithms to rate employees, using behavior and communications. Though Cataphora provides objective criteria, it’s rigidly applied. Today, an algorithm can’t holistically measure effectiveness of two different programmers in a meaningful way. Once people know the metrics, and the metrics will be figured out, people will sub-optimize their work, prioritizing conformance to the metrics over achieving business goals.

Imagine if programmers were rated on clarity and volume of their communications. Suddenly you would have programmers spending significant time writing email and documentation. While that’s not entirely bad, email and documentation don’t directly contribute to revenue as code does. Since communications are overhead — necessary, but not directly contributing to revenue — you want the smallest amount possible that gets the job done right. Motivating workers to get a check on an HR form is dangerous, especially with knowledge-intensive workers, as they will reverse-engineer any system to figure out how to do a good job.

My belief is managers can be objective in rating employees without losing a holistic view that is tied to company objectives. While I believe HR can create a framework to capture individual manager’s rankings and ratings on employees and candidates, no one in the organization can successfully resort to using a single set of metrics to effectively rank everyone. Individuals are too individual to be measured in a rigid manner. Being objective takes thought, but when done right, so does every other part of your job. When I hear about a process that removes critical thought, like in the BusinessWeek article, I see trouble. Use objective criteria that make sense, but apply them thoughtfully.

Share

Time Estimation in Software Development

Sunday, March 8th, 2009

Time estimation of software development efforts is usually wrong, often underestimating the time required to complete tasks. Here are some contributing factors leading to under-estimation:

  1. Assumption of full 8-hour days to write code
  2. Incorrect or changing scope
  3. Imperfect knowledge of the problem
  4. Unanticipated changes in priorities (e.g. emergencies)
  5. Budgeting time to test, but not time to close issues found in testing
  6. Failing to time-box research
  7. Overoptimistic, assuming nothing will go wrong

Assumption of a full 8-hour day to write code

Your day will have times when you are not working. Paper work, e-mail, meetings, set-up work such as configuring test environments and that extra 20 minutes taken for lunch all take time out of the day for development. Additionally, developers suffer significant penalties due to interruptions that have large expenses as developers get back up to speed. A good first assumption is 20% overhead, or 8 hours out of every 40 is spent on overhead tasks typically involving communication.

Incorrect or changing scope

Perhaps you missed some steps that need to be done? This is why developers like to have requirements written down. It amazes me how infrequently requirements are written and when they are, the statements make glaring assumptions. Additionally, people change their minds, the economic environment changes or new opportunities arise and suddenly, the scope of work changes, often increasing the scope of work (though not the time to deliver).

Imperfect knowledge of the problem

Teams waste work because people skipped the part where they are supposed to figure out what the problem is, because it’s more fun to code. There are many ways to understand the problem: use cases, design documents, user stories, requirements analysis or simply talking to the customer. A common factor in success is a repeatable means to refer to the problem that everyone can go to and arrive at the same conclusion. Though it sounds easy, it’s surprisingly hard and time-intensive to communicate in such a way that eliminates assumptions.

Unanticipated changes in priorities (e.g. emergencies)

People organize for the common scenarios, i.e. business as usual. If everyone knew and was adequately prepared for an emergency, it wouldn’t be an emergency. Those who try may be seen as wasting time and resources, which can be true. Sometimes, short-term business needs re-allocate resources and the best thing to do is actively communicate upwards the effects of changing priorities before, during and after the change. How do you do communicate before the change? I communicate time estimates with the explicit assumption of unchanging priorities. Once they change, I state the effect. You can’t assume everyone knows the effect of the change or even knows about the change.

Budgeting time to test, but not time to close issues found in testing

It may take a week to go through all the tests, but what if bugs are found? First the bugs have to be reproduced, documented, fixed, verified and then, ideally,  the tests start from the beginning and the cycle repeats. Typically, the larger the number of bugs, the more test cycles needed, though complexity of fixes is a better indicator. How many test-fix cycles will you need? It’s a hard question to answer and keeping your software quality up and your technical debt down is the best way to keep the number of test cycles low.

Failing to time-box research

Some problems are not straight forward. Many solutions may need to be evaluated or sometimes you need figure out a new way of doing something. You can generalize developers into two categories: production and prototype. Production programmers will usually take much longer, because they want the ideal solution. Prototype developers take much less time, but their solution usually has limitations. Time-boxing research is a way to set expectation with developers. If you know that developer’s ability, time-boxing is a coarse way to control quality of the design and implementation.


Overoptimistic, assuming nothing will go wrong

Helmuth von Moltke wrote, “No battle plan survives contact with the enemy.” If you account for that, perhaps by giving yourself a time buffer for problems, you can absorb many, but likely not all, setbacks.

Conclusion

On a high-risk project, I convinced the team to account for all of the above when estimating effort for software development. We easily met our goals, so easily, that management accused the team of padding the estimates. Under pressure, we went back to the old way of estimating (essentially ignoring all risk). Projects were delivered late and management changed it’s grumbling from “lazy, padded estimates,” to “lazy developers need to work harder.” In software development, there is a tendency to shoot the messenger (i.e. developer) for accurate estimates. Software is expensive and many companies would rather go into it not knowing that.

Share

Body Language

Wednesday, February 25th, 2009

Not everyone says what they mean, but according to Navarro and Karlins in What Every Body is Saying, our bodies are more truthful. Apparently people are prone to look at faces first for meaning when they should be looking at the feet, torso, arms, stance and posture. The central idea of the book is that our physical actions are governed by our limic system which controls the fight or flight response. If you didn’t like someone, you might unconciously lean away or turn your feet away from them. If a person puts you at ease, you may find yourself copying their posture, e.g. crossing your leg in the same manner they did. Recently, I saw someone report a delay to a manager. The manager suddenly dropped their cell phone, thinned their lips and looked to their left for 10 seconds, a clear indicator of the manager’s emotional state. Because it was a departure from the previous behavior and occurred in response to a statement (“the project will be late”), I could make a compelling case that the manager was upset even though no displeasure was registered verbally. The book trains you to use body language as a way to make educated guesses on the emotional state of people. You can’t tell if people are lying, but knowing if they are anxious, upset or pleased can help you communicate effectively. The book is well-written, contains copious case studies and citations which makes interesting and credible reading.

Share

Do Cubes Make Sense?

Monday, February 23rd, 2009

The people who need solitude the most, software developers, quality engineers, etc. are working in noisy cubes with constant interruption. Meanwhile, managers, whose job is to primarily communicate and organize, have offices. Yet managers spend much of their time away from the offices, communicating to people not in their offices.  Developers who would benefit from doors to close, rarely get them. The logic is managers need doors to close to discuss private matters. In my experience, if I am closing my door a lot, I’m doing something wrong. Why businesses should give developers offices is well-covered in Peopleware, yet most developers remain in cubes.

Cubes made sense, once. In the age of mainframe computing, your IBM 3270 was not portable as it was hardwired to the server. To work, programmers needed to be at their desks. The idea of programmers working from home was not feasible early on. Most everyone in the data processing industry had a cube. Eventually we got modems, SLIP, PPP, broadband connections, laptops and now, wireless. Today, where you can sit, you can work. Beds, coffee shops, couches, air ports, trains are all potential work locations. Why do we still have cubes?

Some people like a small space to personalize that is separate from their home. For some working from home is more distracting than in a cube. Some people like the distractions and opportunities to socialize with co-workers.

Many larger, slow-to-change, businesses have yet to figure out that cubes are overhead and a waste for those who don’t want or need them. Sometimes, corporate culture can be slow to change.

Companies fear that people not co-located won’t work together effectively. I’ve had employees work from home and from the other side of the world effectively. If you have competent people that are motivated, you can trust them.

What would I like to see? A quiet-as-a-library work area, with desks, chairs and couches. Near the work lounge would be numerous small rooms for teams to collaborate. Adjacent to that would be a large space where people could talk, have many white boards, sit down, eat and be noisy. However, some people may need or want a cube – give it to them. However, split some of the cost savings for those who choose less expensive options like working from home or shared work areas. I don’t see a problem with cubes, but if less expensive options exist with equal promise, why not try them?

Ironically, though, after we transition to shared work areas, cubes will become a a luxury. Imagine that.

Share

Be a Leader

Friday, February 13th, 2009

A friend gave me invaluable advice on management: Be a leader. Managers delegate tasks, but leaders are the people you turn to when you have a problem. You want to go to a leader because you know they will help.

To me this means, I have to be:

  • Competent
  • Clear
  • Humble
  • Trusting
  • Consistent
  • Honest

And one more that’s different from the others:

  • Creative

More frequently than you’d like, you’ll be caught between upper management your team. On the line will be your team’s goal to do the great work of which they can be proud. Being creative helps you see the middle road between the black and white areas. In other words, the solution that you didn’t think of right away that gets everyone to where they want to be.

Creativity is different, because it’s the only one you can’t learn or practice. You have it or you don’t, like the ability to learn pointers – not everyone has it. However, the other traits you can learn through practice. Many people go very far that were competent, humble, etc. but not creative. Because rather than having subordinates, these leaders had a dedicated group of supporters who were always there for their leader. It’s arguable that a slightly flawed leader is easier to follow, because you feel that leader needs you.

“Be a leader,” was the most succint and helpful advice I’ve ever received.

Share

Performance and Knowledge-Intensive Work

Sunday, February 8th, 2009

Sometimes your reports don’t work in an optimal fashion during their work day. People don’t come and go at the same time and some arrive very late. Not everyone works exactly 8 hours every day. Sometimes people work together on a task best suited to one person.

Occasionally, managers try to raise productivity by optimizing how people work on an individual level. Hard rules, like “everyone in the office by 8 a.m.” or “no web browsing not directly related to work,” are what I call top-down productivity approaches and, in software development, I’ve never seen any returns other than increased turn-over of staff. Bottom-up approaches, getting staff to volunteer improvements, works better. Near-universally, people want to make positive impacts and will try, if given a chance. Structure opportunities for people to improve their performance. A simple question may suffice, “How could we deliver more features in the same amount of time?” If the initial answer is, “We can’t,” then keep asking questions and continue to challenge them. Most will rise to a challenge.

Management must be concerned with performance, but past the workflow-level (i.e. where are the bottlenecks constraining my resource capacity?), it’s a mistake to try to organize how individuals perform tasks delegated to them. If you were managing a team whose sole job is to clean floors and there is one proven way to do the job efficiently, then directing people on how to work makes sense and saves money. However with knowledge-intensive work (e.g. software development), there’s frequently countless ways to do any task. Though you may know a wonderful way, is that the way your report can best implement and maintain? Likely not, if they did not pick your preferred method. It’s a trust issue – your reports were hired to think and if you trust them do their jobs and avoid doing theirs for them, they will be happier and more productive.

Share

Interviewing Programmers

Sunday, January 25th, 2009

After my former CEO said, “We’re shutting the company down,” I had to interview. Which is not much fun when the interviewers aren’t good at it. Bad interviewers, about half of those whom I met, did one or more of the following mistakes:

  • Assumed candidates are perfect fits, until proven otherwise
  • Relied on random quiz questions to establish technical competence
  • Looked for a grocery list of skills rather than intelligence or ability
  • Forgot the candidate is also interviewing them

Start at 0 and Work Up

In most interviews, I walk in the door as a “100%-fit” in the eyes of the interviewer and lost percentage points for every question I missed. For knowledge-intensive workers, it’s the wrong approach. At one interview, I aced it after correctly answering all their questions. The job wasn’t a good fit for me, but because I had the right answers, I was a fit. However, the job required skills I didn’t have — they just hadn’t found a reason to not hire me. Failing to find reasons to not hire is not the same, or as good as, finding reasons to hire. Find reasons to hire candidates rather than assuming they will work until they miss a question. This removes luck – some can sail through interviews and still not be a match.

Quiz Questions

The technical interview usually unfolds as a quiz of technical questions, that are often obscure. The logic is, if the candidate knows the obscure parts of a technology, they must know the common parts. At one interview, I aced the quiz and managed to get bonus points by answering the question, “How do you share file descriptors between Unix processes?” Coincidentally, the week before, I read the solution in W. Richard Stevens‘s Advanced Programming in the Unix Environment. They over-rated my ability based on trivia questions I happened to get right. Joel Spolsky wrote a significant article for hiring technical workers, The Guerrilla Guide to Interviewing and in it, said the following about interviewers employing quiz questions:

This is the kind of person who thinks that smart means “knows a lot of facts.” […] There is no possible, imaginable correlation between people that know that particular piece of trivia and people that you want to hire.

He’s right. However, candidates need to enter with a minimum of knowledge. Phone screens are good for determining if the requisite knowledge is present. For C/C++ programmers, I ask basic knowledge-based questions on fundamental aspects of the language. What is the stack and the heap? What is the time complexity for an algorithm that traverses a binary-tree? Explain inheritance and polymorphism. This is not obscure trivia, or a quiz, its a sampling of the basics you need to know to be effective in C++. That and some descriptions of how they contributed in recent projects will fill out phone screens nicely.

Match Ability Before Skills

Looking for specific skills or experiences can exclude great candidates. Sometimes, you can spot a match for another group or, if you have open mind, you can spot abilities that can overcome skill gaps. Imagine your open position requires a C++ network programmer, though the candidate knows networking programming, it’s with Python and Perl. The person demonstrates amazing knowledge of algorithms, fantastic problem-solving skills and a great attitude that would fit in with your team. Moreover, the candidate is self-taught in both Python and Perl, becoming adept in each in weeks. Given a choice between someone with high intelligence and gaps in skill and another with average intelligence and no gaps, with all else being equal, I’ll select the more intelligent candidate.

Forgot the Interview Goes Both Ways

In one interview, I was made to wait 30 minutes as the hiring manager “had an important meeting.” It’s hard not to read into the manager’s priorities. Worse, when my prospective manager showed up, it was clear he had not read my resume. When he became bored with my answers, he would interrupt to start with the next question. An interview is like a first date where everyone is on their best behavior. If the prospective employer is rude during the interview, it’s hard for candidates to imagine the workplace values workers and their contributions. Maybe the manager had a legitimate emergency and was “off their game.” The best thing to do would have been to apologize and re-schedule the interview. Though that’s also poor, it is better than overwhelming potential employees with unprofessional behavior. Even if the interviewees are poor fits, it’s best to treat them with the same respect as everyone else because it’s the right thing to do.

Summary

  1. Screen the prospect, ensure they have the minimum knowledge, skill set and experience.
  2. Figure out what the candidate can do.
  3. Avoid quiz questions, focus on relevant problem-solving.
  4. Don’t just match positions with skills, look at the candidate’s abilities.
  5. Remember, the candidate in interviewing you, too.
Share

Fear of Failure and Quality

Monday, January 19th, 2009

Lydia wrote a great article titled “The Process Trap,” that asks weather company processes help or hinder quality of service. The trap results from a company’s inability to acknowledge and learn from problems. About half of my past workplaces fell into the trap Lydia describes. For individuals, it’s dispiriting to feel “stuck,” and for companies, these are lost opportunities for improvement.

Everyone with whom I’ve worked wanted to provide the best service possible. However, when the penalty for failure is significant, people become fearful. With fear, people’s motivations change — they become less concerned with quality and improvement and more concerned with avoiding failure. Fear of failure is a such a huge detriment to quality that one of Dr. Deming‘s fourteen points for management effectiveness is, “Drive out fear.” Deming wrote that in 1986 for Out of Crisis, so the idea is not new, but not everyone reads Deming.

When customers won’t receive acceptable service, what will employees do when fearful of deviating from standard operating procedures? They will ensure customers receive lousy service. No process will fix that, because it’s an issue of leadership. Somewhere between the person answering the phones and the board of directors, someone has to stop being scared and enable the people under them to do the best work they can. When you’re under a lot of pressure, and most managers are under pressure, it’s hard to be fearless, but not impossible. Absence of fear is necessary because it takes people to improve and adapt processes and people will avoid changing anything when scared.

Share

Hardline Management at Yahoo

Sunday, January 18th, 2009

On ValleyWag, Yahoo CEO Carol Bartz reportedly told staff she would “dropkick to fucking Mars” anyone whose gossip about Yahoo ended up on the blogs. The quote itself was on ValleyWag shortly after. Aside from the obvious fact that treating people with disrespect is wrong and potentially illegal, managers who only care about profits should still avoid this behavior. The key asset of a technology company is not the technology, but the people. Not matter how good your technology is, in a few short years today’s intellectual property will be tomorrow’s commodity.

Threatening employees is demeaning. Your best employees, the ones you want to keep, will have other employment options and, after being repeatedly abused, they will leave. Meanwhile, the people whom you’d better off without, will stay. Demeaning people pushes staff talent the wrong way (down).  In a technology company, this throttles the competitive advantage.

While the threat is strong, this is not strong leadership; it’s not in the company’s interest. Over time, this management style will discourage, demotivate and drain talent, which is especially dangerous for technology companies.

Share