Sunday, July 29, 2007

The Dilemma of the Capable

The Peter Principle states that in a hierarchy, every employee tends to rise to their level of incompetence. In other words, every employee gets promoted until they reach a level where they are unable to perform their duties well and hence cannot be promoted. A variant I have noticed on the Peter Principle is this: If you are sufficiently capable in certain activities, you will find yourself getting involved in other activities, voluntarily or involuntarily.

Suppose you are hired to do a particular job, maybe let's say a programmer. If you do your job well on time, people will notice you and they will think that you are capable of greater things. It does not matter whether you are capable of those new things. The fact that you are good in something shows that there might be the potential for you to do more.

Showing capability draws the attention of both your peers and managers. And they start asking you to do things that are beyond what you initially signed up for. For example, your fellow programmers may ask you to help them with their coding problems. Your manager may ask you to help out with some of the management activities like planning and reporting.

This situation may also happen voluntarily. If you are sufficiently capable, you will find yourself finishing work faster than other people. Instead of sitting idle, you will start trying to find ways to contribute to the team or doing more work. Most capable people find it really difficult to pass their time doing nothing.

However it occurs, this situation poses a few management problems both for the capable employee as well as the manager:

  1. Any additional activities done by the employee cannot usually be compensated in real-time by the manager, regardless of the benefits to the project or the organization. The actual reward may come much later in the form of a promotion or a good opportunity and this time lapse makes it difficult to establish the correlation between the reward and the prior work. In the meantime, the employee may feel short-changed.

  2. The additional activities may overwhelm the employee and affect their normal work. When this happens, the employee stops taking responsibility for their primary work. Sometimes, this results in even basic tasks in their domain of expertise going on the backlog. The tolerance for additional tasks varies from one employee to another, but once it crosses the threshold, even one additional task beyond regular work is intolerable.

  3. Extra voluntary contributions from an employee, like a new innovation, may sometimes be interesting, but not of use to the project or organization. Rejecting such contributions can cause them to lose motivation and not spend further time and effort in additional activities in the future, even though they still have the potential of doing something useful.

This issue is sometimes referred to as  the "over-qualified employee" problem. Most management books talk about hiring the best employees. But hiring a highly capable employee can backfire on you if they are hired to do something entirely below their capabilities. You will find them contributing beyond what they are hire for. At the same time, you cannot compensate them enough or help them focus on what they must do.

In some environments, such as product companies in a rapidly evolving market, this may work out well. In stable environments with limited product and service profit margins, this is not the case. Capable employees in such environments may find themselves like space travelers in the Stone Age. Managers also find it difficult to manage the expectations of such employees.

What should a manager do with such capable employees? The most important thing is to establish the right expectations between effort and reward. If there is no guarantee of rewards, then the employee should be asked to scale down their efforts or do it on their own interest or risk. Discourage activities that may at some time overwhelm the employee.

But before all that, hire the right person for the position.  


Saturday, July 28, 2007

Q & A Session on Google Analytics

Users of web visitor analytical data from applications such as Google Analytics and other programs use them to understand more about their visitors. They use the information to better design their website layout and content. But Google Analytics also provides other pieces of interesting information.

Using some of the statistics (over the last 6 months) from the visitors of this blog (generally people interested in technology), I am going to formulate some questions and answer them. Here you go:

Question: What are most people interested in when they search?

Trouble-shooting. Of the top 25 keywords, 15 related to "problems", "shutdowns" and other technical issues (Yahoo! Mail, Windows Vista, Office 2007). People come to search to find solutions to problems they are facing and usually these are pressing, immediate issues. Then come the news and people related searches (Dale Carnegie, Barack Obama, Jan Grzebski, etc.). Finally, there are people who are interested in various technical and management issues.

Question: How do people find out about and visit web sites?

No marks for guessing the top answer: Google. But the next common is direct visits, which means people typing in a URL or using a bookmark to return to the site. The most-likely pages to be bookmarked are the home page and pages that have more content - it is likely that people cannot read them immediately and therefore bookmark to visit them at a more convenient time. Trouble-shooting pages that have the potential of being useful in the near future are also prone to bookmarking.

Blog sites are likely to get many visitors through various uses of their feeds. For example, your feed (if it has the appropriate license) may be syndicated by another blog or it may be shared through a blog reading application like Google Reader. Blog search engines, directories and hosting sites also send traffic.

Question: Is there a difference in the quality of traffic sent by various sources?

I used to think so when I had less data in the form of visitors. Nowadays, I find that there is no difference from the major source of traffic in terms of order of magnitude. The only poor quality visitors are referrals from web sites that have a different subject matter. For example, posting a comment on a comic strip website may bring some visitors, but they are not going to wait around to read a technology blog.

Google visitors comes right in the middle in most visitor properties. This is not surprising since it accounts for the majority of the hits and influences the statistical averages. Webmasters would be well served to spend more time ensuring that their site appears favorably in Google search results, since the aggregate benefit is much greater than other sources of traffic.

Question: What city has the most people interested in technology?

According to my data, these are the cities with the most people interested in technology (in order of priority): London, San Francisco, New York, Bangalore, Chennai, Delhi, Sydney, Los Angeles and Singapore. It was surprising to me that London beat out San Francisco, but then I remembered the many recent trips my software friends in India have been taking to England. There is a lot happening there.

If you want country data, it reads: United States, India, United Kingdom, Canada, Japan, Australia, Sweden, Singapore, Germany and Philippines. And as far as continents go, the Americas (primarily North America) lead the way, followed by Asia, Europe, Oceania and Africa.

Question: What browser should I design for?

Ah, that age-old question. Many years ago, I had been asked to design different versions of corporate web sites to cater for Netscape Navigator versions, Internet Explorer, text browsers (Lynx), WAP, etc. Now, the main browsers are definitely Internet Explorer and Firefox, but Safari and Opera also command a significant number of visitors, even if the percentage of visitors may be lower.

All 4 browsers are now available for Windows, so theoretically you should be able to test for all users without switching to a Mac. Designing for mobile devices is a different ball game, though Apple may be changing things there with a regular browser on the iPhone. A good simulation of what your site looks like on a mobile device is available at Mowser. (thanks to Manoj for that last link)


Wednesday, July 25, 2007

When Murphy Strikes

Management is tough. It takes years of experience and learning to understanding how to manage people and resources well. While some managers get lucky and have an easy time, most managers find the going tough. Management is fundamentally a balancing act between several conflicting priorities and an assumption of risks and responsibilities over which one has limited control.

The most difficult thing that managers, particularly less experienced ones, find it difficult to digest is the phenomenon of bad things that happen despite their best efforts - bad things that they could have done nothing to prevent. When someone lands in trouble because they have been slacking off or neglecting something, they reconcile themselves to the fact because they understand that they are directly responsible for the failure.

That is not the case with incidents of pure bad luck. Sometimes, superstitious managers feel that there is some curse on them when that happens and they get terribly depressed and helpless. Here are a few incidents of Murphy's Law in action:

  1. Losing an important team member at a critical juncture: The person falls ill with some disease or meets with a road accident at the time that you least expect it to happen. One day, he or she is helping you day-dream about great possibilities and the next day, they are calling you from a hospital bed. Suddenly all your plans are not worth the paper they are printed on.

  2. Getting hit by some unexpected technical glitch: You suddenly help Microsoft or Oracle discover that obscure bug in their system software in that important functionality that must work for your application to be useful. What is worse is that you think it is your fault and then spend hours chasing that non-existent programming error.

  3. Being strung along by the ups and downs of business cycles: You suddenly get several customers in a week and cannot possibly get enough staff quickly enough. Or a large customer lands into a business crisis of their own and has to downsize. There is never a perfect staffing situation, even if you are the best resource allocation expert on the planet.

How does one cope with such situations? By definition, I am talking about unexpected situations, for which you didn't plan. For example, if you did take into account the loss of every team member, then that particular situation does not apply. But even with your best risk management, there will be other cases that you did not consider and then found yourself totally dumbfounded when it happened.

The first thing as a manager is to remember that "stuff" happens. This has the unfortunate side effect of becoming a person who is not overly enthusiastic about anything good happening, because you are just waiting for the inevitable downside. The good thing about this pessimistic outlook is that you are not totally surprised by bad things happening. The older you get, the more likely you are to have this attitude towards life.

I think the people that really get hurt when bad stuff happens are the innocent and the idealist types. They naively believe that if they do the right thing, everything else will automatically fall into place and fit into their well-laid plans. When they get a dose of reality, it does not meet their perception of fairness and they just cannot accept it. Unfortunately for them, life is never fair.

The second step is to not panic. In many bad situations, there are always other options. Although those options are not necessarily perfect, they are usually much better than the worst case scenarios that you start building up in your brain during a crisis. What I have seen is that in many tough situations, being honest and transparent with the stakeholders gains you support and allows you to manage the situation with less stress.

Sharing your problems with people who can help is very important. A very counter-productive step at this juncture is to gripe about your problems to someone who cannot or will not help you. It only increases your frustration and feeling of helplessness. If no one can help you, talk to someone who can comfort you, like your spouse or best friend.

Finally, gain a sense of priorities. Most bad things in the business world are really nothing compared to the troubles faced by people in under-developed and developing countries. You are not starving or having to worry about being maimed, killed or imprisoned. Apart from the crisis, most of the things in the rest of your life are just fine. The few irritants today will disappear at some point in the future. Don't get too stressed out!



Sunday, July 22, 2007

Productivity Tips for Nerds

Everyone wants to be more productive and there are literally thousands of books and web pages to cater to them. In this article, I want to focus on technical people because they exhibit certain special behaviors that get in the way of being productive, even if they want to. Here are some productivity tips for them:

  1. Stop trying to be an early adopter for every product: Technical people go gaga over every new application or consumer electronic product that comes out. They must get a hold of it, even if it means starving for the rest of the month. This is such a waste of time and money. Only 1-2 products truly succeed in any problem domain. Trying out all the possible products consumes enormous amounts of time without much return.

  2. Learn to switch off electronic items: Switch off your TV and your computer. Stop picking up your phone. Most technical people find this impossible to do. One friend told me that the one thing he needed for survival (other than air and water) was an active Internet connection! But if you manage to turn off, suddenly you get this huge slab of free time which you can use to do all sorts of interesting things.

  3. Focus on quality instead of quantity: Don't try to learn 10 different languages or platforms at the same time. At a time, learn one really well and understand its nuances. Don't try to swallow hundreds of feeds, articles and books. Instead, select the few that would be really useful. In any case, life is too short for you to consume everything. So be selective and make effective use of your time.

  4. It is okay if you are not busy: Some technical folks treat busy work as a badge of honor. They actually love complaining that they have no time to do anything because it proves that they are doing something important and they are wanted. So much so that they have withdrawal symptoms anytime the work load comes down. Having free time is not something to be ashamed of. Use it to refresh your mind and body. Plan for future work by learning something new or advanced.

  5. New technology is not necessarily more productive: Email and chat can be more time-consuming than phone calls. It takes less time to call someone and resolve a problem than exchange emails all days long. In development work, a newer technology may have some cool feature that saves some effort, but you also waste a lot of time learning how to do the regular mundane work in it. Choose technology for its utility, not its newness.

The addiction to being connected is something all technical people share. Many people don't switch off because they are afraid of missing an urgent message. But the fact is that if someone sending an email really wanted to get an answer immediately, they would call you. If someone calling you really wanted to talk to you, they would leave a voice message. So most of the time, there is no reason to respond in real time. (This does not mean that you should be a jerk and not pick up the phone at all, just that sometimes you need to be able to get away from the need to be always available.)

Also imagine if you had an accident and were in a hospital bed unable to move. Would you care about calls or emails? You may be worried, but you cannot do anything about it. And your contacts would have to wait until you got better. Most things in life are not really as urgent as you think or as people would like to have you think.

And tell people about when you normally respond. If they expect you to be responding 24 hours a day, they will send emails or call you 24 hours a day. On the other hand, if they know that certain hours are off-limits, your volume of emails and calls will automatically go down. Unless of course, you want to be masochistic.

A final point: Reduce the need to repeat yourself. When 2 people ask you the same question, send the reply to all possible interested parties. Or post it on your website or blog. I have found the last technique quite useful. When people ask me something and I already have an article on it, I just send them the URL. That really saves a lot of time.


Technorati tags: ,

Saturday, July 21, 2007

Coping with Difficult People

I recently heard an audio tape of the book, "Coping with Difficult People" by Robert M. Bramson. This is one book that every manager should read. In fact, probably every person should read this book. If they have to interact with difficult people, then they will learn how to manage such behavior. And if they are themselves difficult people, they may recognize themselves and try to correct their behavior, but perhaps I am being a tad optimistic there.

The author identifies seven different types of difficult behavior:

  1. Hostile-aggressive: These people use hostility as a means to get their agenda done. There are 3 variants of such people - the "Sherman Tank" who rolls over anyone in their path, the snipers who take potshots at people from behind a facade of humor and sarcasm, and finally the exploders who are normal most of the time, but erupt when they are threatened and frustrated.

  2. Complainer: These people keep complaining all the time about silly matters that normal people wouldn't pay attention to. They poison the environment and make it miserable for everyone. I had previously covered a particularly nasty type of complainer in a previous article, "The Martyr Complex".

  3. Clam: This type of person does not open their mouth even when asked direct questions. Normal people cannot bear silence in a conversation and hence the clam's opponents are forced to end discussions without any resolution of outstanding problems. Clams make it impossible to establish trust and transparency in an organization.

  4. Super-agreeable: They cannot say "No" to anyone. They will agree to whatever you say and then fail to deliver. Each time, they will find some excuse to explain their behavior and with their pleasant behavior, make it difficult for you to truly confront them.

  5. Negativist: These are folks who keep throwing a wrench into the works. They oppose any initiative and exaggerate reasons for not doing something. They can destroy the growth of a company by opposing any change, regardless of the advantages.

  6. Know-it-all: This category contains experts who think they are right and bully you with facts and figures. Their fanaticism for their point of view prevents them from seeing opposing arguments and addressing real concerns. Frequently, know-it-all "experts" contain just hot air and use the behavior to seem like experts, instead of actually knowing anything.

  7. Indecisive: They cannot make a decision. They are victims of what is termed as "analysis paralysis" - they analyze everything to death and take forever (sometimes literally forever) to make a decision. When faced with a problem, such people can bring the company to a standstill while they fight with their inner demons.

Most people are not difficult. They may exhibit some difficult behavior from time to time, but it is not a pattern. In fact, the author mentions two possibilities for difficult behavior from non-difficult people. One is that a person may be genuinely blind to his or her faults and you just need to have an honest talk with them. The other case is where the behavior is the result of a negative interaction cycle, triggered by some incident.

With difficult people, fixing problems or talking to them does not help. The root causes of their behavior are deeper and sometimes impossible to change. So the only way to interact with such people is to understand and cope with the behavior. This also helps one from reacting counter-productively and worsening the situation.

The book contains really practical advice. In other books, you read advice that seems to have been written by someone cooking up theories in solitary confinement. Not this book. You really gain insight into what drives the behavior of difficult people. Remember that they have a rationale for doing what they do. Remove the fears that result in such behavior and prevent the reactions that would give an advantage to such behavior, and you can cope better.

A word about the audio format of the book. It uses different narrators to convey a sense of different real-life situations. The example interactions are intriguing and at times, hilarious. I liked the calm, analytical voice of the author as he goes about explaining the behaviors and the techniques for coping with them.

Wednesday, July 18, 2007

Integration between Google applications

The recent acquisition of FeedBurner and the subsequent quick integration with Blogger was a superb move by Google. Recently, Google has made many integration efforts between various applications and many of them have been really beneficial to both web authors and end users.

A few examples from Blogger itself:

  1. Integration with Google Custom Search: With no coding, you can now add a custom search widget for your blog. You can see an example to the right of this post. This is much easier to do than trying to set up a Google Custom Search separately and then include it in the Blogger template.

  2. Search Engine Optimization: Google has included a robots.txt file that now excludes the pages of the various blog categories. This avoids the need for bloggers to do more house-keeping by using sitemaps in tools like Google Webmaster Central. I expect that Google will now start to exclude archive pages and thus avoid duplicate content search result issues. Strictly speaking, this integrates with all search engines supporting robots.txt, not just Google.

  3. Integration with Picasa Web Albums: The images in Blogger posts are now stored in Picasa Web Albums. This has the potential of allowing tools like Windows Live Writer to post images to Blogger, and also allow blog authors to understand how much space they have left to upload images.

Other integrations I liked were the email capability in Google Reader, saving of Google Talk chats in Gmail, Orkut message alerts in Google Talk, Google Maps in Google Search results, etc.

Here are some other possible Google product integrations that would add value and reduce duplication:

  1. FeedBurner statistics and Google Analytics: While FeedBurner does have the functionality of serving feeds, its statistical component could be integrated into Google Analytics so that webmasters could see the information in one place.

  2. Blogger and Google Page Creator: Although blogs can exist as web sites in their own right, sometimes there is the need for creating additional content that exist as static or dynamic web pages. WordPress already allows one to create separate web pages.

  3. Gmail and Google Reader: Many email clients (including Outlook and Thunderbird) already allow one to read blogs. Why not Gmail? Combining it with Reader will make it easier for users and result in a killer application. Gmail has a very rudimentary blog reader - it should be replaced by Google Reader.

An aspect of integration that is not quite getting the press that it deserves is the fact that Google is able to make its flagship Search product much better. The concept of PageRank basically boils down to what content is rated high by persons of authority (primarily web authors) on the web. But web authors are only a very small minority and not even representative of Internet users who are consumers of web search. Content should be really be rated by how users behave when they see search results and choose what they believe is relevant.

The data from Google Reader, Google Analytics and FeedBurner provide valuable information in this regard that keeps Google quite ahead of competitors. These products allow Google to understand what content users find valuable. Spammers may try to game the system, but this does not distract from the fundamental benefits obtained through this integration.

A couple of times, I have stated on this blog that Google is way ahead of competitors on search. I didn't provide any references, but that is what the data shows. My Analytics statistics show that Google currently brings 75% of the traffic to this site - a share that has been growing. Yahoo! is at 1% and Live and Ask are not even in the picture.

Internet users are continuing in increasing numbers to express their confidence in Google results. And all signs indicate that Google Search will be much more relevant than ever before, consolidating Google's hold on the market. Google is doing this not just through algorithmic competence or infrastructure capability, but also through increasing understanding of real end user behavior. And that is a great winning combination.


Sunday, July 15, 2007

High-Class Problems

Nobody wants failure, but success brings its own challenges and problems. I don't know if you have experienced this, but every time you cross a new milestone, there is some other new issue waiting to be resolved. It is not that you don't want to succeed or you would be happier being a failure. It is simply that any success brings you into a different situation with its own issues.

Business situations are like that. If your company is not doing well, then you are constantly worried about paying the bills, keeping employees onboard and getting more funding to keep afloat. But if you are growing, then the previous problems go away, but are replaced by new issues. You are happy that you don't have to worry about money, but you are still fighting with problems.

I have heard these situations referred to as "high-class problems". The reason why they are called so is that they only occur when you have encountered some success and taken care of problems mostly associated with achieving that success. And usually these problems fall under the "we will cross that bridge when we get there" category.

Here are some examples of high-class problems when a business becomes "too" successful:

  • Needing more people than you are actually able to hire.
  • Needing more servers and hardware than you are able to buy or deploy quickly enough.
  • Too many users with more special requirements than you have the ability to address.
  • Conflicts between newly-joined and older employees about strategy, direction and tactics.
  • Insufficient processes to handle new needs.

Why do people and businesses land in such situations?

  1. They don't have time to think about these problems: When a business is struggling, the owners are anxious about how they will release the product or make their next sale. The most important thing at this moment is working hard to make things happen. Even if people think about some issues, they are usually analyzed in the most elementary way.
  2. They don't think they will succeed: At times, success seems like a pipe dream. You have done your best and worked really hard, but nothing seems to happen. Then although sales starts picking up, you don't really believe it for a long time until you finally realize that the success is here to stay. Most people are internally very pessimistic and invariably believe in Murphy's Law.
  3. Success hits them out of the blue: Sometimes a business is on a slow growth strategy when suddenly they hit a really good prospect. Sales may double or triple and the organization is totally unprepared to handle the situation on any front.

Some of these problems can be fixed easily enough if you pay attention to them. In fact, the very fact that a business is successful allows you to spend money to solve some of these issues. Problems around human resource interaction and management are more tricky, and they need more time and thought. Using money to resolve a time allocation problem and vice versa can be harmful in these cases.

Other problems can be very difficult to cope with. For example, fulfilling a very large sales order may be impossible for the company and you may lose a valuable customer and a great opportunity to grow the business. Some issues do not manifest themselves immediately. Problems with processes are usually realized after something bad happens.

Can one be prepared for such situations? Theoretically, of course, you can. Try to predict the possible success scenarios and plan to handle them. Unless something extraordinary happens, you should be well placed.

Practically, most people find it difficult. Planning for success takes a lot of vision and optimism. It is very easy to get frustrated and dragged down by the inevitable troughs and setbacks in business. You don't want to tempt fate by thinking of success. Try asking a student how they plan to reduce their taxes when they get a job and you will probably get the blankest stare you have ever encountered.

The other problem is that success changes some people to raving optimists. At this point, success has spoiled them so much that they think they can handle all the new problems using old techniques and it just doesn't work. When you are successful, you cannot afford to rest on your laurels. The new situation demands new thinking and you will have to work just as hard as, if not more than, you did before.

A final point: Businesses or people who have not experienced the success may find the problems of the successful ironic and funny. They aren't, actually. If left unresolved, the problems during success have a way of destroying what has already been created. For those who encounter them, they are definitely not less serious than the problems before success.


Saturday, July 14, 2007

Startup vs. Non-Startup

There are a lot of useful books and articles on business management. But many of them have a particular problem: The advice works only in a startup or a non-startup, but not both. Unfortunately, many articles do not clearly explain the context under which the advice is applicable. This has the result of confusing readers, who then go about implementing wrong policies in their organizations.

Every company or market goes through 3 distinct phases: rising, stable and declining. The declining company is not of interest in this article. So let us focus on the rising company (or startup situation) and the stable company (or non-startup situation).

Here are some fundamental differences between a startup situation versus a non-startup situation

  1. A startup is about creation: doing something new. A non-startup is about sustaining: maintaining something already created (in addition to any creation work).
  2. A startup has nothing to lose. A non-startup has a lot to lose.
  3. A startup dies by not making decisions. A non-startup can die by making a wrong decision. Sometimes, the best thing for a non-startup is to do nothing.
  4. Every second and every dollar counts for a startup. A non-startup can afford to accept imperfection and wasted time and money.
  5. Lack of passion in a startup can lead to delayed product launches. Passion in a non-startup can result in costly mistakes and cleanup.
  6. You need people with intelligence and ingenuity in a startup. You need people with the ability to follow processes in a non-startup.

Consider an example of the startup vs. non-startup mentality from real life, namely, youth vs. old age. When you are younger, you can take more risks in life because time is on your side. But as you grow older, you start accumulating things and it is much more difficult to make a clean break. Take a look at the following questions:

  1. How much of your wealth are you willing to lose in a disaster? Is it 10%, 25%, 50% or even 100%? When younger, you have more time and opportunity to recreate the wealth you have lost. As you get older, your tolerance limit keeps going down.
  2. How willing are you to relocate to another job or city? Yes, the grass is always greener on the other side. How much greener does it have to be for you to start grazing there?
  3. How difficult is to say you were wrong about a deeply held belief, related to religion, culture or politics? You find the older people get, the more conservative they become because saying you were wrong has a greater cost in social and professional acceptance. Young Turks are not old. :-)

These answers vary from person to person. That is why you have so many different opinions about anything, because each person has a different ratio of startup versus non-startup mentality. The more a person wants to create, the higher the startup mentality. The opposite is true if the person has already created and seeks to maintain.

When you come to business management recommendations, they follow the same pattern. Recommendations that focus on leadership and innovation are meant to increase risk and are ideal for startups. Recommendations that involve management of people, projects and processes are meant to reduce risk and are ideal for stable organizations.

Depending on your personal outlook, you may feel that the startup mentality is better or worse than the non-startup mentality. It may feel good to be the dynamic, risk-taking adventurer or you may like to be the mature, option-weighing strategist. But logically speaking, the choice has been already made for you.

Action is the default choice when you or your company has nothing to lose. Planning is the default choice when you have a lot to protect or maintain. Changing the default choice is an emotional choice that has no foundation in logic.

For example, a startup that spends months implementing internal processes that guarantee excellent quality code is foolish, because it is not creating anything of value that would bring revenue. A stable company that ignores internal processes to speed up work will drown in customer complaints and lower their market share.

This sounds depressingly like a Greek tragedy, where people don't have any control over what they should do. But I think these are just guidelines for better management and have room for initiative. Here is how I interpret it. Startups grow by doing more and taking on greater risk. Non-startups grow by doing better and reducing risk. In each situation, there are many things people can do that can manage the company's destiny.


Tuesday, July 10, 2007

The Full Feed Problem Again

Steve McConnell, the author of the programming Bible, "Code Complete", has a blog called "10x Software Development". I am a huge fan of McConnell and actually buy his books to use as reference material, instead of my usual method of borrowing them from a library. His blog is pretty good and I would encourage you to subscribe to it, except that it has the irritating flaw of not offering a full RSS feed.

So if you want to read his article, you have to click through to the blog website. The only advantage of subscribing to his blog is to know when he has posted a new article. McConnell is not the only one to do this - others include the web design site A List Apart, the New York Times technology Pogue's Posts site and Paul Graham. Also, people like Jakob Nielsen do not even seem to believe in blogs or feeds; instead, Nielsen loves email newsletters.

I don't understand this for several reasons:

  1. First of all, some of these sites do not seem to have any tangible benefit for the author by forcing you to visit the website to read the article. As far as I could see, there didn't seem to be any ads on McConnell's and Graham's sites.

  2. A typical user who reads blogs subscribes to many blogs. It is very tiresome to keep switching from the blog reading software to separate browser windows or tabs to read the articles. This increases the probability of losing readers, especially during inevitable periods of poor quality posts.

  3. The number of feed subscribers is a small minority of the total readers of a blog. So offering full subscription does not hurt page views or visitor count at all. At the same time, it offers a great benefit to people who like your content.

  4. Feed subscribers are more tech-savvy. They may have blogs themselves and link to you, share your post or email it to others. For example, Google Reader offers the ability to email a post directly from within the application. When there is no full feed, it takes more effort to do the same thing and many people do not bother.

  5. Feed subscribers are more likely to participate in the conversation. If you have a good post, they will come to your website and post comments, or email you. That increases the value of your blog.

  6. There are many ways of getting people to visit your website even if you offer full feeds. You can provide links to similar articles in the past. You can also have ads in your feeds if your intention is to make money. You can blog about your work or company if it brings value to your audience.

  7. Finally, offering only partial feeds affects search results in blog search engines like Google Blogsearch, Ask and Technorati. Don't believe me? Search for the heading of the blog - you will find it. Search for some words within the content - the post will be missing.

I could get mad and unsubscribe from these blogs. But that is rash - many of the articles on these sites are really high-quality and I wouldn't want to miss them. But I sincerely wish that they would make it easier. Turning off full feeds just seems like a really unnecessary thing to do.

Technorati tags: , , ,

Sunday, July 08, 2007

Free vs. Getting Paid

In a previous post on making your hobby count, I mentioned that when you start making money, the focus shifts from you to your customers. There are 2 logical objections to a statement like that:

Objection 1: When you start earning money for something, isn't it about you at that point?

It is definitely true that you are benefiting from a commercial activity. But unless you produce something that others need, there will be no money flowing in. Your ideas about your product are incidental to its success or failure - the only thing that matters is whether your customers like it.

Now, there are persons and companies (like Steve Jobs and Apple) whose idea of a product closely matches with that of their customers. But that need not be the case. And if there is a conflict between your idea and what customers expect, you have to be willing to change your idea, not expect the customers to change their wants or needs.

That is why incremental product design works. You identify a customer need. You build something. Customers start using it and/or provide feedback. If you are wise, you will modify the application to suit their needs. The cycle of listening to customer feedback and development continues and your product gains momentum in the market place.

This concept is true of every job, even if you are not in product design. If you are getting paid, the money comes from the customers of your company or organization. Although the company's owners pay the salaries, it really comes from your customers. If your job does not do anything to help your customers, it is actually contributing to reducing the potential revenues for your company and indirectly affecting what you could be paid.

For example, a recruiter is not really hiring a resource to meet a project manager's needs; he is hiring the best resource that can make a product better and more attractive to customers. A secretary at the front desk is not there simply to take calls or receive visitors; she can be an ambassador of the company to create a positive influence on potential employees, customers and partners.

If a company's executives, managers and employees are not customer-oriented, that company will die. No questions about that. It does not matter how big the company is or how brilliant its people are. If customers do not want what the company produces, die it must. That is market reality.

Objection 2: If you are not earning money for something, does it mean that you are not producing any value for others?

Doing free work does not mean you are not producing any value. In fact, open source is all about producing value and giving it away for free. But here is the thing: When you do something for free, it is not necessary to produce anything that someone else values.

You can work on whatever you want. You can spend as much time as you want. You can do 99% of the work and quit without producing anything. You can produce something that solves a problem in a totally inefficient manner. You can even decide to re-create something that has already been done by someone else, just because it is fun.

Since nobody is paying the bills, you have no obligation to anyone. You can do anything you want, within reason and social/legal norms.

Examples abound. People spend a lot of time, effort and money collecting things from stamps to baseball cards. Although sometimes, these activities can be profitable, most of the time they aren't and people don't do it for the money anyway. Many people spend a lot of time playing sports and games. Although playing sports is good for health, the reason most people do it is for enjoyment, not for the health benefits.

Why this concept matters?

  • Many creative people find it difficult to work at a day job because many of their ideas are frequently shot down by customers. My opinion: It doesn't matter. You have a duty to provide the best ideas you can to your customers and argue for them passionately, but ultimately it is the customer's decision. It is their money on the line and they have to make the decision that they are most comfortable with. Whether the customer's decision is ultimately right or wrong (based on the market reaction) is simply irrelevant.

  • Once again, your boss does not pay your salary. Your customers do. Your obligation, whatever your role in the organization, is to meet the needs of your customers. Structure the way you work to provide maximum value to your customers.

  • When you do something that you are not getting paid for, other people's opinions do not matter. You can always listen to people's suggestions and what they do in a similar situation. But such input should be non-binding and only followed if it makes sense for you. This frees you to do what your heart wants and what your mind feels is right. It avoids unnecessary pressure to meet someone's expectations of what you should do. This is not just for hobby projects, but for any activity you do.

  • Do you keep worrying about what other people will think about your actions? Are they paying you? If not, quit caring about them now.

Saturday, July 07, 2007

A Book on Evidence-Based Management

I recently finished reading "Hard Facts, Dangerous Half-Truths and Total Nonsense", a management book by Jeffrey Pfeffer and Robert I. Sutton. In this book, the authors describe how business leaders and managers should use actual evidence as the basis for decisions. You may think that this is the case, but most people actually base their judgments on emotion and intuition than real facts.

The authors discuss a variety of issues such as:

  • Is work very different from other aspects of life and should it be?
  • Do the best companies have the best people?
  • Is company performance driven by financial incentives?
  • How important is strategy to a company's performance?
  • Can a company survive if it doesn't continue to change?
  • How significant is the role of leaders in driving the results produced by their companies?

You may be surprised at some of the conclusions of the authors. They explain how many common assumptions that typical managers have are based on their fears, hopes, experiences and ideologies. Managers generally do not know and do not care to find out if these assumptions are validated across other companies and organizations.

One of the things I liked about the book is its exploration of "half-truths", which it calls "dangerous". A half-truth is a statement that has some truth to it, but has several caveats to it. For example, it is true that financial incentives can drive company performance forward. But what are the side-effects of financial incentives? They have the potential to create friction between colleagues and also create conflicts with customer service which only has an indirect effect on financial performance through building goodwill.

A quote I liked from the book was

Wisdom means ... striking a balance between arrogance (assuming you know more than you do) and insecurity (believing that you know too little to act).

In fact, real management is always about balance. The moment you go crazy about or against something is when you stop being rational and start succumbing to your emotions in guiding you through messy real-life management situations. Such behavior is usually guaranteed to end in tragedy.

I would qualify this book as a must-read. Unlike typical management books, it does not provide any ready-made prescriptions or formulas for solving management problems. Instead, it encourages one to consider making decisions using verifiable facts instead of unproven assumptions. As the authors say: stop and take the time to reflect.

Friday, July 06, 2007

Preparing for a Software Career

I sometimes get questions from computer science students about what to study. What they want to know is whether they should learn Java, .NET, or some other language. Most of them are only familiar with a programming career, so their questions center on that. They also look at newspaper advertisements to figure out what is hot in the market.

My answer about what to study usually disappoints them, because it is not as straightforward as they would like. It is also a little difficult to follow because it takes significant and sustained effort over a long period. Here is the gist of what I tell people:

  1. Improve your communication: It doesn't matter what you know. What really matters is how well you are able to communicate to people. This includes your first job interview too. The interviewer does not know what is in your mind. You have to be able to express your thoughts clearly. When you do get your job, you should be able to understand, write and speak well. Otherwise you will be ineffective at your job.

    Learning to communicate does not come naturally. You have to work hard at it. You must read a lot to write well. You have to keep talking to people in various formal and informal settings to be comfortable doing it. In India, a particular challenge is finding the opportunity to speak English since everyone uses their mother tongue in regular conversations. This can be remedied to some extent by only using English in official settings. (Since a significant amount of software development in India is for English-speaking countries, using English makes sense. Otherwise use whatever language is appropriate.)

  2. Learn to work with people: Most people have little experience dealing with the power structures of a typical organization. You have to manage relationships with your boss, your subordinates, your colleagues, and other departments over which you have no power. One of the most common reasons for attrition in organizations is fractured inter-personal relationships and lack of inter-group coordination.

    As people gain experience, some of them understand how the dynamics work and are better able to handle and navigate various situations. However, other people continue to find this difficult and fall back on emotions such as indifference, anger, or frustration. Needless to say, that is not the best way to pursue a career.

    How does one build up this strength? Taking part in group activities while at school or college is a good start. Playing sports is especially good because you have to play similar roles to what you would in an organization. You also understand how to take success and failure in your stride and learn the value of teamwork and co-operation.

  3. Never stop learning: Software development is not a skill you learn at school and then use at work. You have to keep learning always. And you cannot rely on your employer to provide you training for everything, simply because even your employer does not really know what is round the corner. No one can make the training decisions for you. You have to find time and do it.

    The other thing about learning is to look out for learning opportunities. This is actually easier when you don't know anything. It becomes more difficult when you think that you do know something. Then you stop learning. Also it is easier to learn a new technology than it is to understand a new methodology or follow a new way of thinking. You have to mentally remain the same age you were in school to maintain this attitude.

After I say all this, most people still ask, "That is great. But what should I focus on: Java or .NET?" Well, the answer to that is: Learn one thing really well. It does not matter what it is. Learn the ins and outs of it. Then when you pick up a book for another technology, you can relate quite a lot from what you know to that and then just learn the difference.

But that really sounds like hard work, doesn't it? And that is the final word: The original question about the career really is a trick question. The person is actually only looking for a shortcut. There is a different path - a straightforward one. It is tough, but it is guaranteed to produce results. And in the long run, trying to cover up shoddy results and making excuses to people is actually more work. Making the effort now will bring greater satisfaction in one's career.

The shortcut is, in fact, the straight road.

Making Money from a Hobby

Sometime back, I discussed how doing a hobby project can help one learn many new things regarding a particular subject. When a hobby becomes a passion, you quickly become an expert at it and it is possible to turn the hobby into something that can help you earn money on the side. For example, if you are interested in photography, you could actually try to sell some of your photographs to somebody who is interested.

Doing your hobby as a day job may not be possible, as the amount of money you can make may not replace your regular salary. Although some people are able to make a hobby their full-time occupation, realistically, most people can mostly hope only to augment their income. Doing this is a good thing. Additional income will help you justify the time you spend on the hobby as well as buy or do useful or entertaining things.

There are many hobbies that you can make money off, especially if you are in the technology field. Creating programs or content on the web and using advertisements to gain revenue. Teaching people about computers or programming languages. Giving speeches and taking seminars. Trouble-shooting problems for people. I used to do some of these activities in the past.

Doing a hobby for money does bring a few challenges:

  1. There is a direct relationship between how hard you work and how much money you earn. Well almost - the more you work, the greater the possibility of earning more money (not necessarily actually earning). So it is difficult to avoid spending a lot of time on the particular activity and becoming a workaholic. Soon, a hobby can become pretty consuming. Even holidays and weekends can get filled with activities.

  2. The focus changes from you to your customers or consumers. A non-commercialized hobby can be pursued without consideration for what other people think. When you are trying to earn money, your preferences may not match the people who are contributing to your income. So you will have to adapt or perish. The hobby becomes more work than a relaxing pastime.

  3. At some point, you will hit a plateau where more work doesn't result in more revenue. You may need to start looking at advertising or marketing or even change various attributes of your products. Thus the actual creativity work becomes less, and more time is spent on selling. In fact, the more successful you are, the less you would actually spend on the core of your hobby and more on publicizing and monetizing it.

  4. The ups and downs of income can create additional pressure and stress. When you have a bad day or week where you have less income, you can feel dejected and frustrated, even though the factors that contributed to this may be totally outside your control. It may take time to understand and realize that this is all part of a typical business.

I don't mean to mention these challenges as a way of discouraging someone from commercializing their hobby. In fact, realizing that you could have earned (and didn't try to earn) a significant amount of money from something you were just doing for fun can make you feel stupid and foolish. By all means, use your full potential to earn as much money as you can.

But do understand that the process of making money can change the dynamics, make it less fun and create more work and tension. Once you learn to accept this, then it becomes much smoother as you can be better prepared.

Wednesday, July 04, 2007

Cell Phones - The Future of Computing

It looks like the iPhone has made a great start with an estimated 700,000 iPhones sold. I suppose the world is now divided into the following camps:

  1. People who have an iPhone.
  2. People who don't have one, but wish they had.
  3. People who will keep complaining about the iPhone hype, until they finally give in.
  4. People who don't know about the iPhone yet.

Regardless of the iPhone's merits or demerits, it is part of a trend towards making the cell phone increasingly powerful. Six months ago, I wrote a post on the "cell phone computer" where I discussed how the cell phone is increasingly taking over many functions that were done by other devices or equipment. Today, that is even more so. Although the primary selling point of the iPhone is its design, it also has significant new features.

Why should the cell phone be the core component around which other technologies are assimilated? Why not the computer or the TV? Here are a few reasons:

  1. Cell phones are mass-market consumer products. Even people who are not tech-savvy can use them.
  2. Being electronic gadgets, they are very reliable, unlike computers.
  3. They are rugged and portable. Since they run on batteries, you don't need to worry about power sources most of the time.
  4. Business models of cell phone companies are built around charging for the phone service. So, you can get very inexpensive, but capable phones.

As technology advances, cell phone service costs will continue to decrease and coverage areas will increase. This not only means a large consumer base, but also greater usage. In simple terms, everyone will have a cell phone with them and be connected all the time.

With increasing and better Internet availability, cell phones will replace desktop and laptop computers as the primary device for accessing the Internet. Why do most people use the Internet? Read email, play games, check the weather, browse the news - you can do that and more on cell phones now. The only obstacle is consistent good Internet access and that will only improve as time goes.

The main problem with cell phones, as I mentioned in my previous point, is the fact that they are small. Although people like smaller cell phones because of the convenience, they like seeing things on larger screens. The two are not mutually exclusive. A small piece of equipment can produce a large image by using projection on a wall. Or it could be docked to a large screen display, thus reducing battery power needs.

My feeling is that the latter is most likely to happen. You would have stand-alone screens that could easily connect to different cell phone models through a common interface. You would get your movies from the cell phones. In the future, you probably will never buy any movies in a physical medium like DVDs. You would stream movies from a central library using your cell phone as a conduit to the Internet.

Although people are getting better at entering data into a cell phone, the keyboard and mouse will not go away soon because they are perhaps the most efficient input devices available. Multiple touch screens are great, but people will continue to have a need to enter text. This is true even after high-precision voice technology is commonly available.

One reason why many programmers don't see this trend is the fact that our whole careers have been in front of a desktop or a laptop. We have been creating applications that run on a personal computer or on a server. Server computing and development will continue as applications and data become centralized. But the clients will shift from a PC or Mac to a cell phone.

The one major difference between developing for a desktop system and developing for a cell phone is the fact that cell phones must continue to be reliable. You probably cannot have Norton Anti-Virus or other protection programs running on your cell phone. Users won't stand for that sort of stuff on an electronic gadget. What this means is a fundamental change in how you create programs.

Other differences are disappearing.

With the iPhone, we just saw the integration of the iPod with the cell phone. What is next? I think the next stop is integration of Web 2.0 sites with cell phones. We will increasingly start seeing user-generated content coming from cell phones. For example, you go to a restaurant, it sucks and you post the review right then and there as you wait for your check. The first web sites that enable this capability will win, and they will win big.

Watch this space in another six months.

Technorati tags: , ,

The Logic Box

The logic box is a technique that I read in some management book or article sometime back. I tried Googling for the original source, but failed - there is a blog that has the same name. Anyway, the idea is rather simple and probably doesn't even need a special name. Here is what a logic box is:

Suppose you have a problem and you want to find a solution. You cannot just pick the first thing that pops into your head because every action has consequences. There are also many constraints to what you can do.

So you start building a closed box where the sides of the box represent your constraints. When you enumerate every constraint, you have a closed box containing a set of solutions from which you can choose. You cannot choose anything outside the box without violating one or more constraints.

Let me take a simple example. You want to buy a car. One important constraint is how much money you can spend. Other constraints are safety, size, comfort, performance, etc. If you have a family of five, you obviously cannot buy a two-seater. If you go camping in the mountains, you want a vehicle that performs well off the road.

So mentally you start putting together the logic box. There are some things you need, but there is a limit to what you can do. As you start building the box, you suddenly realize that the sides of the box are not fitting together. For example, the high-performance car that you want is unaffordable. What do you do then?

This is a sign that you need to change some constraint. Either you need to decide for a lower-performing car or you need to find more money somehow. When you adjust the constraints accordingly, the logic box comes together and you make a logical decision.

Now let us say that you don't change any constraint and you have an open box. You go ahead and buy the car which you cannot afford. This is an irrational thing to do. What happens then is that reality starts tinkering with your constraints, forcing them on you, whether you like it or not. To make the payments, you will have to do with less stuff you were buying or enjoying, start making more money or default on your payments.

So, ultimately the logic box always wins.

You decide whether you want to understand how it works and adapt your behavior accordingly. Or you can ignore it and then be forced to adapt.

Of course, no one really thinks about building a "logic box" and "making the sides fit". The concept of a logic box is to suggest that if we hope to make a logical and careful decision, we must consider all our desires and all our constraints and have them be compatible with our decision.

If our decisions maximize what we desire while considering all the practical constraints we know about, our decision will more likely to succeed in the long run. Wishful thinking that ignores constraints can only lead to problems when those constraints show up.

Technorati tags: ,

The Convenient Death

One of the favorite tactics that story writers use to resolve a dilemma is to kill off someone. I can't begin to count how many love triangle movies I have seen where the 3rd person is thrown under the bus so that the other two can go live happily ever after. In comparison, real life rarely works out that way. Problems don't resolve themselves automatically and you are never left with a simple, neat choice. Instead, you are faced with a dilemma - sometimes having to choose between two really good options and occasionally between two distasteful choices.

Here are some examples:

  1. You want to hire someone for an important project and you have to choose between two people. One is a hard-working programming genius who has no experience in the chosen technologies. The other is a competent, but average person with a proven record and years of experience in the relevant technologies. Who would you choose? Think again.

  2. A developer under you is incredibly hard-working and very sincere and co-operative. However, his work leaves much to be desired. He tries to improve, but it is not enough. It is affecting your budget and deadlines. Furthermore, other team members have to help him out, affecting and delaying their work. What do you do?

  3. Consider the opposite case. There is a prima donna in your team who produces excellent work. Without her contribution, you would be hard pressed to meet any demands on your team. But she is terribly difficult to manage. She behaves badly towards other members of the team. Overall, the team would be very happy to see her go, but everyone knows that she would be very hard to replace. Without her, you would have to re-negotiate all of your promised delivery dates with very unhappy stakeholders. What do you do?

  4. A production application built several years ago is in maintenance. You know that you must re-engineer the application in newer technologies; otherwise it would be impossible to support the application in a few months' time. At the same time, you have to make changes in the application to cater to business needs; otherwise the company would lose money and opportunities. You have a limited budget. How do you balance the different demands?

Most business management and software development situations are filled with choices like these, where you don't have a straightforward solution. As I mentioned, sometimes you have two or more attractive choices and you are not sure which to choose. Each choice has great advantages and perhaps a few minor weaknesses. Usually, whatever choice you make doesn't harm you, but you still have the feeling that you are leaving something on the table.

The other dilemma is worse. You have two situations, both of which are unpleasant. Either way, you are going to suffer in some form and usually it is peace of mind. While dealing with dilemmas surrounding resource and budget allocation are tough enough, it becomes even more difficult when you have to deal with personnel problems, because human beings can react to what you do.

What do you do? I think the best way to handle such situations is to look internally and try to act in the most ethical manner possible. What is good for all people concerned? What is the truth? What situation is sustainable in the long run? Recognize other factors like fear, pride and ego that may conflict with making a right decision.

You can gain a better understanding of how to handle such decision by learning the guidelines of business ethics. Although most of us have a good moral framework for making decisions, learning about ethical dilemmas other people have faced can help us understand the real choices that we can make. It can also help us gain closure when and if we have to make tough decisions.

Postscript: The really great movies (like "Casablanca") handle dilemmas the right way by forcing the characters, instead of the plot, to make the choice.

Monday, July 02, 2007

Software Metrics - Incremental Use

My last post on software metrics was about how we should attempt to measure only those metrics over which people have control and feel they have control. In this post, I will discuss how metrics should be used incrementally to understand the actual processes and dynamics within a team or organization and thus be in a position to improve them.

Let us say that you want to measure the quality of a software product you are building. You are not collecting any metrics yet, but you want to get started. Let us say that you start with a simple measurement, "number of bugs discovered in every build". It looks simple enough - the fewer bugs reported each build, the more stable the product is.

However, when you start measuring something, it affects the behavior of the people. This is the classic Hawthorne effect, namely, people change their performance when they are being observed. You may think this is a good thing - people will reduce the number of bugs because that is what is being measured. Isn't that good? Yes, if that is what people actually do.

In reality, people behave in strange ways when you start measuring something. Instead of actually trying to reduce bugs, some of the developers may try to reduce the number of reported bugs. How can one do this? Well, the developer may decide to work on areas that are likely to yield a great count of bugs, like user interface level bugs, while ignoring more critical areas where bugs are harder to find because of complicated logic.

A more dangerous situation is where the developer tells testers to inform them about bugs, but keep them outside the bug tracking software. You will see less bugs being reported, but in reality nothing has actually changed with respect to quality. To prevent this from happening, you may decide to reward testers for reporting more bugs. But that can also backfire, since testers will now start to report trivial bugs as well as issues that are really not bugs, but different interpretations of expected functionality.

At this point, you will realize that what matters is not just the count of overall bugs, but also the quality of bugs found. A low count of severe bugs is more critical than a greater number of simple bugs. Severity could be measured in different ways. It could mean an important user function working improperly. It could mean that a particular module has been designed entirely wrong and has to be coded again from scratch.

When you start collecting this metric, you gain some insight into the actual quality of the software. But then you have more questions: Even though the severity bug count is going down, how many bugs are still outstanding? Are you winning the battle with the bugs, meaning are you fixing more than you can find? Did you spend more time fixing bugs than you could have spent redoing the work?

You realize that one metric alone will not cut it. You need to collect more information to manage the work better and also find out if any changes you are making are improving things or making them worse. The good thing about things like bugs is that if you already have an automated bug tracking system, you can get most of the information from the software itself.

For example, a typical bug tracking system should have various bug statuses from Reported to Closed. If you have access to the data repository or if the software allows you to do reporting, you can find out how much time it takes for a bug to go from being reported to closed, or how much time an average bug takes in development time. By setting this up properly, you can have up-to-the-minute statistics on your hand at all times.

Looking at one particular aspect (in this example, bugs) from different angles can allow you to understand how to improve your project. For example, if you notice a certain type of bug being reported frequently, that should ring an alarm bell in your head - maybe it is time to design something that can take care of that particular issue forever instead of fixing one bug at a time.

Although many people frown at this, looking at statistics of each individual can also be illuminating. You can find out if a particular developer is having a problem with a certain type of error checking. Sometimes, an individual tester may be accidentally missing some types of scenarios that other testers are working with. Looking at data the right way can provide insight into each person's performance and way of working. Just be careful to do it sincerely for the project's sake instead of using it as a weapon for manipulative purposes.

Many software departments in companies and even software companies themselves do not collect metrics. This is understandable because software metrics can require significant resources. However metrics can help one do a better job. Incrementally collecting metrics and continually tweaking the collection process and the metric itself can be a good strategy. This avoids a huge up-front investment and at the same time, helps one learn more about one's own processes and organization.

Sunday, July 01, 2007

Software Metrics - The Rule of Control

Without measuring something, it is difficult to manage and improve it. When software is developed commercially, it has to manage several needs, including quality, time-to-market, production costs, etc. Many of these goals are set by the market place. For example, if only "x" people will pay for your software and you can only sell the software for a maximum of $y, then there is a limit on how much you can spend for creating it.

Many programmers, including skilled ones, instinctively object to any sort of metrics collection. One reason is that they feel that collecting metrics and preparing reports is an overhead and a distraction from their primary job of development. In their view, they are already doing the best job they can do. Any further improvements to the project could only be achieved by adding more resources, buying better tools and extending project deadlines to reduce pressure.

Having worked as a developer, I have some sympathy with such arguments. However, after managing other developers, I can also see the other side of the picture, which is that programmers can become very blind to their faults. Most developers have no real way of understanding how effective they are at their jobs and so they overestimate their capabilities. This is even more so true of programmers who rely on heroics to do development, debugging and bug fixing.

Let us consider the scenario of a programmer who just manages to meet his deadlines by working 12-hour days and weekends.

If you talk to such a programmer, he could object to metrics collection on many grounds. First of all, he is really hard-working and committed to the project. He also meets all his deadlines. He probably also writes good quality code and follows standards and best practices. He may be the person who volunteers for the really challenging tasks on the project. To spend time on metrics would be distracting and reduce his level of output, meaning he would be less efficient.

However, the situation also creates many problems. Foremost, this programmer's way of working is not sustainable or replicable. The programmer would burn out within a few weeks and cannot sustain the same level of effort. Other developers may not be able to exert the same amount of effort. Therefore, you can only guess at how much time a similar task would take in the future. And this does not include any buffer time for unexpected technical difficulties. Finally, work done in such trying circumstances is likely to be buggy.

Metrics can actually expose the problems here. For example, asking the programmer to specify an estimate in hours and then comparing it with the hours he actually worked can very illuminating. You may think that the programmer already knows the number of hours he worked, but in my experience, they never do. A programmer may have spent 3 hours debugging a technical issue, but does not recall spending that much time.

Don't think that you have solved the problem by obtaining this metric. Your work has just started. Confronting the developer with the discrepancy between estimated and actual hours opens up a new can of worms. Suddenly, you are given reasons about unanticipated technical issues or unrealistic deadlines, or even some philosophy that software development is intellectual work done by humans, not physical tasks on a machine at a manufacturing facility that can be estimated. Oy vey!

You can get into an argument with the developer, but arguments have a bad habit of never ending cleanly - the other person never really accepts your point. What you can do is actually try to accept what the developer is saying and give him control over the various issues that he is complaining about.

Ask the developer to give the deadline for a specific calendar day, assuming a proper 40-hour week and considering any holiday time. Ask the developer to put a buffer for technical difficulties. Ask the developer to add time for non-development activities, including documentation, meetings and metrics collection. Involve the developer in activities that could affect the development time. When the constraints and goals are created by the developer, he has an incentive to perform according to those goals.

This is not to say that now automatically the goals will be achieved, but you have made a start. So first rule of metrics: Give people control over factors affecting their metrics. When people have such control over the constraints affecting their work, they are the first to ask you to measure them, because they have the capability to improve upon them.

Technorati tags: ,