Comments (3)

By Krishna, February 26, 2007

I have both Microsoft Internet Explorer 7.0 and Mozilla Firefox on the computers I use. There are many reasons why you may want to have and use both browsers. Here are five reasons:

1. Different Sites Don’t Render Properly: Some websites work only in IE, while others are built only for Firefox. This happens when the development team prefers a particular platform and didn’t have or didn’t want to spend resources on getting it working on the other platform. Most of the issues I encounter have to do with JavaScript errors and CSS layouts, rendering the site useless in one browser. However the other browser works just fine. In some cases, the website’s functionality is fine in both browsers, but it is faster in another. For example, Google Reader works much faster in Firefox.
2. Security: Regardless of anti-virus and anti-spy software, it is useful to keep one browser for visiting untrusted sites and the other for critical things like bank transactions. Since IE is known for ActiveX exploits, it makes sense to use Firefox for browsing search results, especially if you are searching for results on “ActiveX exploits”. :-) This is not as critical as it used to be. IE 7.0 does a much better job on security. Also if you have protection software like Norton Internet Security, it has an add-on in your browser for displaying whether a website can be trusted. Still, you never know…
3. Forgetting Saved Passwords: When you have the browser remember your password for certain sites, those sites appear differently than if you were logged in. For example, when I am editing our product blog on WordPress, it shows a toolbar at the top for “My Account” and “My Dashboard”. This prevents me from seeing what it would look like if someone else is viewing that page. So I use the other browser to view the website. This is the same for Blogger too. They have the Edit icons all over the place when I am logged in.
4. Google Search History: I like it when my Google Personalized Home “Interesting Items for You” gadget offers me suggestions on Searches, Pages, Gadgets and Videos based on my past queries. For example, they had this video of Matt Cutts and an ASP.NET video. The problem is that I don’t always search on technology. Like for instance, I did a search for Vietnamese food in Nashua, NH. That confuses the engine and I have to go and delete those searches, which can be a pain. Yes, I can log out, but then I have to login back for other Google services. Much easier to load the other browser and do searches.
5. Minor Conveniences: Firefox offers an easy Google-Suggest-like search box. The search for text capability is dynamic. You can easily close tab windows without clicking them first. The add-ons are better. Internet Explorer 7.0 offers some more screen real estate. The website source opens up in Notepad. The RSS feed reader has certain interesting capabilities. Stuff like that.

There were very good reasons why you should have used only Firefox when IE 6.0 was around. But now, the two browsers are almost comparable. Since there is hardly any cost in downloading, installing and keeping both of them on your computer, it is probably helpful to figure out what you can do with the situation, instead of spending time researching which browser is better.

Let us look at this way: Say you have a sports car and a family sedan in your garage. You may prefer one over the other. But isn’t it worthwhile that you use each of them in some capacity or the other, considering that you own them and they are lying on your property? Yes, use one more, but maybe there is something you can do with the other.

Same here.

Comments (0)

By Krishna, February 25, 2007

“Featuritis” is a term used to describe the condition when the software product undergoes multiple rapid changes in functionality that were not anticipated during the initial stages of the project. This happens very frequently for in-house projects, but by means restricted to them only – any software product development may exhibit signs of featuritis. The typical scenario goes like this:

1. The software project starts with the intention of solving a few simple problems.
2. The development team gathers and analyzes the requirements. They come up with a development and rollout plan.
3. As the product shapes up, end users are requested to look at the product and provide feedback.
4. If there are many suggestions and complaints, the team is now forced to include some of the high-priority ones in the rollout.
5. This affects the original plan and also sometimes plays havoc with the design and logic assumptions in the product.

It goes with saying that most development teams usually get really upset and frustrated with changing requirements. Just when they thought that they had a good handle on what and when they were going to deliver, the rug is pulled under them.

Even worse is the fact that some suggestions may actually conflict with the original assumptions or requirements on the project. For example, the original requirement was “We just need one address for a contact – just the permanent address.” Now that changes to “We should have multiple addresses per contact.” Such changes can require extensive rework on the application.

Here are some common suggestions regarding how to avoid featuritis and what I think are their limitations.

1. Say “no” to changes until the current plan is fully executed: This may work out well for the development team, but it can be very detrimental to the company’s marketing efforts. Some new features are driven by competitors. Even when the product is only used in-house, the value of a certain unavailable feature may make a lot of difference to the company’s bottom line.
2. Design for changes in the system: For instance, in the earlier example, what is stopping the team from creating a DB design that allows 1-to-many relationships between contacts and addresses. The problem is that anticipating and designing for all such changes can expand the development effort considerably – this translates into greater expense.
3. Design a flexible system: The plethora of application frameworks is a testament to the failures of developers to build code foundations that can support any change. It is very difficult to build a system that is completely flexible – simply because of the fact that humans build them and they cannot anticipate what the future holds.
4. Do a better job of collecting requirements: This is a good way of ensuring that some basic wrong assumptions don’t get written into the system. However, sometimes, even with good prototyping, end users don’t really know what they need until they actually use the system. The reason is that when people actually have to use the system to solve their problems, there is a fundamental change in their attitude towards the software. They are much more demanding and passionate about missing features.

I think that one way to this problem is to expect change and embrace it when it happens. As a development team, do not get emotionally attached to a particular design or project schedule. Make the development process dynamic by constantly revisiting the planned tasks and their priorities.

This requires a fundamental shift in the outlook of the development team. Instead of working towards a complete system on a certain date, there is an indefinite development cycle where each feature is prioritized and done. By doing this, the project plan becomes subservient to the interests of the end users, which can contribute significantly to the success of the product.

People familiar with Agile methodology will definitely see the similarity here. I am not advocating a wholesale migration to Agile or rejecting the other suggestions (1 to 4 above) outright. They have their place. It is sometimes necessary to reject some features as not meeting the project goals. It is important to do a good job of requirements and design for change. But all this should be done without rejecting the reality that change will occur, no matter what.

Comments (0)

By Krishna, February 25, 2007

Having subscribed and unsubscribed to several different blogs over the last few months and using different feed readers (Google Reader, Internet Explorer 7 RSS Reader, Thunderbird, intraVnews, etc.) and tools like Yahoo Pipes, I thought I would take a stab at the kind of blogs that I don’t really like. Here is some bad behavior – though not in any particular order of dislike.

1. Lack of Conversations and Community: A good blog encourages conversations between the author and the readers. A blog that doesn’t allow comments makes it a monologue. A blog with moderated comments or one that only accepts comments from logged-in users is a little better, but it still makes it difficult to establish a community. Because I only have 24 hours a day, I can only participate in a limited number of sites. The more logins and passwords I have to create and remember, the greater the burden – it is not really worth my while to do that.

   Another situation is where the author gets into arguments with the commenters on the site and even writes blog posts on the commenters. This has been happening a few times recently on Robert Scoble’s blog. My feeling is that an author should be grateful for all the readers he or she has and improve using their comments. Getting into fights with abusive commenters only brings one down to their level.

2. Lack of Full RSS feeds: I really don’t understand why people would put up blogs with poor syndication capabilities. A blog without a feed is nothing more than a static website. In terms of search engine optimization, it plays poorly with regard to blog search engines like Google Blogsearch or Technorati. A partial RSS feed may seem like a cunning way to get the subscribers to visit the website often (thus boosting the page views), but it can backfire very quickly.Sometimes the partial feed has little content to help me understand what the author was trying to say and doesn’t excite me enough to make me visit the site. Also, I just tune out the person after sometime and cancel my subscription. The truth is – there are other ways to get people visit your blog site like providing links to other interesting content on the blog. As an author, I must do something that appeals to you enough to make you visit my site.
3. Inaccuracy: A good blog must always strive, within reason, to research an issue and explore all aspects of it. Sometimes time constraints may not make this feasible. But if the author decides to use generalizations without backing them up with facts, it lowers the value of the blog. Furthermore, if the author hasn’t been forthcoming about the limited research done, he or she can be easily exposed.A form of this problem happens when the author has a conflict of interest, such as being employed at or affiliated with a company or product that is being reviewed. Wrong facts can also occur if the blogger has a beef with or personal agenda against the company or product. And I don’t even want to get started on blogs that support hate and prejudice based on race, language, geographic region, color, gender, caste, etc.
4. Lack of Originality: Sometimes I like it when a blogger points me to a useful website or interesting YouTube video. But when the blog is just about links and contains nothing from the author’s brain, I wonder why I bother to read that person. I read blogs to learn something from that author – something entertaining, refreshing, surprising – whatever, but it should be something new and original at least most of the time.I sometimes run across blogs that display content from other sites without any attribution to the original author or website. It is actually pretty easy to figure out if the content has been stolen. The writing will be quite different from the author’s regular style and a quick search on Google is enough to confirm the suspicion. I am not really sure why people do this – is it ignorance of copyright rules or do they think they can get away with it?
5. Poor Content: Frequently, a blog author really tries hard. They have frequent posts. They have a good web design. But the content and writing just doesn’t cut it. Perhaps it is because I am not the target audience, but sometimes I see sites on technology and management where the content doesn’t appeal to me.There is no one particular cause. Sometimes it is the frequent use of clichés and catch-phrases. At other times, it is lack of language appropriate for the blog content – like using out-of-place slang and colloquialisms. That is the low end of the spectrum. On the other side, we have very erudite academic posts that need to be labored through to understand the point they are trying to make.

So what constitutes good blogging behavior? I would say it is about writing content that has meaning. Write with good flow and language. Write from your heart and what you believe in. Be humble. Be honest. Converse with your audience. Open up. People like me will rush in to hang onto every word you say.

Comments (0)

By Krishna, February 23, 2007

When it comes to documentation, software development teams follow two different schools of thought. I am oversimplifying below, but bear with me:

1. Documentation is good: For every process, there is a document to plan it, define it, record it and audit it. Every line of code generated will have several lines of corresponding documentation. Likewise, there are more managers, analysts, designers and technical writers than programmers.
2. Documentation is bad: Why waste time writing documents when the coding is so easy? Besides, good programs should be self-documenting. The market doesn’t reward technical documents – it only pays to deliver faster.

Like every black-and-white scenario, each side has good arguments. Before we start on that, let us establish some premises:

1. Every software application exists to provide a solution to a problem. It will have one or more end users who need it.
2. The sooner the application development is complete, the more likely the product will be used. Otherwise, there will be substitutes in the form of competing software products, manual processes to resolve the problem, etc. Hence, a necessary aim of the product development should be to deliver it as quickly as possible with the necessary functionality.
3. Unless the software application is reasonably stable and consistent, it cannot be termed as providing a solution. Hence, the other necessary goal of product development should be good quality.
4. It is possible to achieve a high score in one goal (delivery speed, software quality) at the expense of the other, but that only defeats the primary purpose of end users using the application.
5. Hence software development of any application should strive to find a medium – necessary quality delivered within a reasonable timeframe.

Software documentation should be subject to meet that fine balance. Hence the two questions are

• How little documentation do you need to maintain without sacrificing the necessary quality?
• How much documentation can you do without exceeding a reasonable timeframe?

Asking the opposite question in each case will lead to what we discussed at the beginning of this article. For example, you can maintain high levels of quality by having all sorts of documents. And you can also shorten delivery timelines by deciding to do very little documentation. To achieve both, you need to strike a balance and find how to do effective documentation.

A simple set of rules I recommend to people is:

• Easy to write, easy to understand and easy to maintain: Reduce redundancy – this will reduce the need to update multiple places in the document. Follow common documentation conventions (industry, company or project-level documentation standards). Write in simple English. Find out from your team if they understand what you are writing.
• High level of accuracy and completeness: Make sure what you write is correct and comprehensive as far as you know. Verify the documentation with end users, if possible. Get frequent feedback from your team. A common issue I find in requirements documentation is “logic fatigue” – sometimes the person just writes a heavily-loaded sentence with no explanation because they are too tired to explore all ramifications of a particular functionality.
• Fewer documents with greater depth: Maintain a small set of documents with more detail instead of producing more shallow documents. This makes it more efficient and easier to manage when change requests come in.
• Control change management: Although it is hard to prepare good documentation in the first place, it is even harder to maintain them when the inevitable changes come. Use tracking features in your task management and bug tracking tool to ensure that all changes are reflected in the documentation.

Many aspects of documentation, especially audit-related documents, can be reduced, at least in frequency, by proper resource allocation and training. Development staff members, who are very knowledgeable in standards and best practices, need less process and, by extension, less documentation.

Now an observation to round off this article: Although more documentation is directly related to good quality and inversely related to delivery times, nearing the boundary conditions of 100% or 0% documentation may sometimes result in both poor quality and poor delivery schedules.

When the team tries to have 100% documentation (without any streamlining of the process), change management can be overwhelming. Minor changes in the application can result in disproportionately large changes in the documentation. At this point, the team is under greater pressure from the end user to close bugs and release the software.

Without high discipline, there may be inconsistencies in making changes in all parts of the documentation, which again results in wrong specifications or design - further leading to confusion. A cumbersome process easily lends itself to being violated easily. And suddenly the whole pack of cards comes falling down, because no one knows which document is the right one.

The 0% documentation is also severely affected by change management. Although the software development team initially had a quick grasp on the project details, once changes start coming in bits and pieces, miscommunication becomes the norm. Some developers know more than the others and they start stepping on each other’s toes in the code. Functionality starts degrading. The problem is that no documents exists that can serve as the central guide for the team.

So the extremes don’t really work. The best way to run a project is somewhere in between. What that is depends a lot on the capability, maturity and experience of your team. For example, when I use a term “easy to understand”, that can translate into entirely different things for different people. It is up to you to figure out what that means in your context and put the right effective process in place.

Comments (0)

By Krishna, February 21, 2007

To be really effective in your work, one must learn to do the following:

1. Cancel tasks that do not have any value.
2. If any remaining tasks can be delegated, move them to someone else.
3. Then, prioritize the remaining ones in order of importance and urgency.
4. Start working on the tasks in order of priority.

The more one can delegate, the more one can focus on important items, increasing the value created. So, let us talk about delegation. Here are some common questions and misconceptions I hear about delegation:

Question: I can do the work better than “X”. Why should I delegate to him/her?

This is usually true about any work that you plan to delegate. You got the task in the first place because you could do it. If you have someone to delegate to, it is very likely that the other person is less experienced than you and probably reporting to you. The question is not whether ”X” can do the work better. The right question is: Whether X can do it well enough? Don’t get hung up on perfection.

What you should do though is make the “acceptance criteria” clear. This means what measures would you apply to the person’s work to qualify whether the task is complete. For example, you may assert that a report must be at least 10 pages, must have an Executive Summary, Table of Contents, etc. When you spell this out, it makes it simpler for both the person and you to wrap up the task correctly and with the necessary quality.

Question: I can do the work in less time than X. Why should I delegate?

True, but the right question to ask is: But do I personally have that time? The reason why you are thinking of delegating in the first place is because you are swamped for time. And X has been chosen because he has more time. X can work on that task while you are doing something else. Yes, he may take longer, but how critical is that additional delay?

Also realistically, how much longer is the other person going to take? If it is going to be several times what you would take, then you are probably looking at the wrong person. Find the appropriate person. Provide them tips and suggestions to help them do it faster.

Question: I will make less mistakes than X.

Again, true – because you are more experienced than X. But if you never give another person an opportunity, she will never learn to improve. Let the person make mistakes and learn from them. That way, they will continue to improve and then you can give them increasingly challenging tasks.

Now, you may be faced with a situation where you have a critical task and there is no one with the right experience to delegate that task to. How did you land in that situation? Maybe because you didn’t spend enough time helping your subordinates grow by providing them simple opportunities where they could afford to make mistakes and learn. Nurture your team today.

Question: I don’t have anyone to delegate to.

Sometimes, even if you helped your team members learn and become more capable, they may still be not ready for a task. The reality is that there are some tasks that only you can do. That is why you are the boss.

So maybe the problem is: Should I be looking at some other task to delegate? It is very unlikely that everything you do is something that only you can do. The main reason why you are probably looking at this task is that it is the most distasteful one at the moment. However, the right criterion for delegating a task is not whether you like it or not, but whether somebody else can do it sufficiently well.

Also, ask around. Maybe there is someone you have overlooked who may be both interested in and capable of doing the work. You never know.

Question: My past experience with delegation has been bad. It doesn’t work.

Unless you are born with amazing judgment, you will make mistakes when delegating. You will delegate critical things to people who let you down. You will land in hot water because of their mistakes. You will miss deadlines. But if you quit now, you would have wasted all that learning experience.

Instead, by maintaining a bias towards delegation, you will have an incentive to learn more about how you can effectively delegate. You will learn who you can delegate to, when you can delegate to them and what you can delegate. You will also learn when NOT to delegate – which is arguably the most important thing you need to know.

Final Word: The biggest block that managers have when delegating is related to the concept of “responsibility”. People think that when they delegate a task, they delegate responsibility. So when the person fails them, the manager feels that life is unjust because they have to take the responsibility for someone else’s shortcomings or mistakes. That is so self-defeating.

When you delegate, you remain responsible for the task, its delivery and its quality. You must provide as much information and support to the person as necessary for the success of the task, while striking a balance with the need to avoid eating away your time. There are risks involved in delegating. When you delegate, you must consider yourself personally accountable at all times. Such an outlook will avoid frustration and empower you.

Comments (0)

By Krishna, February 18, 2007

People working in a software development environment find it really hard to lead a healthy lifestyle. As developers, we are so enamored with the technology that we sacrifice sleep and exercise. We binge on fast and fatty foods. So we are out of shape and suffering for it.

When I used to work in Bangalore and Chennai (Madras) as a developer, I didn’t have a vehicle and had to walk a long distance to the bus stand. In Chennai, the buses were so crowded that sometimes I used to walk a couple of kilometers with my friend Vijil (also colleague and roommate) to the office and back. It was good exercise and the conversations with Vijil (who now works at IBM Software Labs) were very interesting.

However, in the US, since we travel all the time by car and there are no ready opportunities for exercising, I started putting on the pounds. It is not easy to get rid of them unless I take time out to visit the gym. That can be difficult sometimes. So I thought: what are the easy ways to remain healthy without too much effort?

Here are some tips based on those experiences:

1. Don’t remain hungry: Always keep something on hand to eat. When you eat small snacks or fruits, your hunger remains in check and you will eat smaller meals.
2. Don’t shop for groceries while you are hungry or tired: Otherwise, you will end up buying junk or fattening food that you will start devouring when you reach home.
3. Sleep well: Being tired or having body pains makes you eat or drink more.
4. Reduce eating out: It is difficult to control food intake when eating in a restaurant. However, cooking at home doesn’t necessarily mean eating less. It is better to have some snacks before cooking so that you don’t cook a lot. If you have to eat out, have a good snack before going out. One way to eat less in a restaurant is to decide (before eating) to take home the rest – you will leave more on the plate that way.
5. Buy healthy foods: Buy diet soda. Get fat-free milk and yogurt. Buy fresh fruit and fresh juice (NOT from concentrate). Buy whole wheat bread. Spend a few seconds to read the labels about calories and ingredients before putting it in your cart. Spend more money on your health.
6. Eat more veggies: Add more vegetables and fruits to your non-vegetarian diet.
7. Exercise when watching TV: Instead of eating while watching TV, do some simple exercises like stretching or lifting weights. This makes the TV time more productive. Don’t start exercising with any goals – they will only de-motivate you if you don’t make enough progress quickly. Just focus on doing the exercise – results will follow eventually.
8. Drink enough water: This helps your body functions.
9. Reduce unhealthy habits: If you are addicted to any unhealthy habit like smoking, try reducing it. Get the help of family and friends to help you quit.
10. Think about your health: The best way to become healthier to make that a focus in life. If you start thinking of everything in terms of good health, you will slowly form good habits and live better.

I am not a physician or dietician – so this is not comprehensive. Do explore other resources on the Internet regarding diet, exercise, illness, etc. It is worth the time.

Comments (3)

By Krishna, February 18, 2007

Ever since I started blogging in earnest since December, part of my brain is always looking for blog post ideas. The problem is not that there is nothing to blog about - rather there is an abundance of topics to blog about. Some of them require more time for analysis – so I just add them to Windows Live Writer as a new draft and then follow up later.

Other ideas are too short for a full-fledged post and, since I am interested in writing longer posts, I tend to ignore or reject them. But I feel that some of these observations may be useful to someone out there. So here we go with some “thought clusters”:

1. I found a link to a useful shortcut in Google Reader. If you press “u”, it hides and shows the left frame. This is very convenient if you are using the Expanded View or a smaller monitor. It is not so helpful if the authors of the blogs you read use short sentences and small paragraphs.
2. Using the Google Webmaster tool, I found that one of the search queries for this blog was “snow googles“. That is obviously a misspelling of “snow goggles“. Which lead to me to thinking about other commonly misspelled words like “accommodate” (mistake is “accomodate”), “occurrence” (not “occurence” or “ocurrence”), “privilege” (not “privelege”) or “pronunciation” (not “pronounciation”), and how much traffic they contribute to a website.
3. On the same topic, Google Search now provides search results on the right word even when misspelled. It continues to offer suggestions. Since I get some traffic from vanity searches on “krishna kumar”, it will be nice to know whether part of it is because of when people type “krshna” or “kirhsna” or something like that.
4. A belated thanks to “New Hampshire Blogging” for a review of my blog and “Cow Hampshire” for adding me to their favorites. For those interested in knowing more about New Hampshire and the people here, please do visit those sites.
5. Yahoo! Mail has a new update integrating Messenger and Mail. It is not available to everyone yet, but from the video I saw, it has many interesting features. You can open a new chat in a tab. There are buttons for “Convert to Email” and “Convert to Chat” depending on what you are doing. You can set the status of Messenger within Yahoo! Mail itself. The poor (IMO) feature release progress on Google Talk and the lack of tabs in Gmail is providing an easy opening for Yahoo! to corner this segment of the Internet audience.
6. In Yuvi’s post on Raymond Chen’s blog stats, he shows that 77% of Chen’s posts are at 7 am. This is remarkable. One explanation is that Chen does his blogging in the morning and then moves on to other tasks. The other possibility is that he writes his blogs at different times and then posts them at 7 am. Which made me think – why not write more posts when I am free and then post one each day? Also, the 7 am intrigues me. Is that the best time for making a blog post visible? I do my posting during the weekends and nights – which is not exactly a good time for US-based audience.

More in future posts. The spell checker was tough on this post.

Comments (0)

By Krishna, February 18, 2007

I have been increasingly using the RSS Feed Reader in Internet Explorer 7.0. While IE7 came out, I was very dismissive of its feed capability because Google Reader was miles ahead of it.

But because it is less powerful, I find it becoming more useful for certain types of feeds. Confused? Well, here are my reasons:

I keep a browser window open on the “All Items” screen of Google Reader. The window title (and the taskbar) reads “Google Reader (count)” where count is the number of unread items. When I subscribe to news sites which have a large number of daily posts, this becomes very distracting. Many of the news articles are of little interest to me, which adds to the pain.

With IE 7, I have to manually open the “Feeds” tab to see if a new post has come in. I could have the feed tab open by default, but since it takes away the real estate for viewing other websites, I don’t do that. So, I can now view those feeds at own leisure. Also, as far as I know, IE doesn’t show all the posts from different blogs in the same page.

Google Reader allows one to mark feeds as unread. IE doesn’t allow that. So I only look at the feeds when I am sure that I will either read or discard them. I don’t have the ability to archive or star them either. So IE prevents me from hanging onto posts long after I really need them.

IE has a feature of creating a custom schedule for the retrieval of posts. So if you are only interested in reading feeds in the early morning, you can set IE to just fetch the posts then instead of every few minutes,

This does not mean that I am abandoning Google Reader. I am only moving some feeds, mostly the ones with higher frequency of postings like news feeds, into Internet Explorer. Previously, I had consolidated my infrequently updated feeds using Yahoo! Pipes. Being able to assimilate the content I read within Google Reader has become much easier now.

Now, I could easily close the Google Reader window and achieve a similar effect. But some blogs are different than others and hence it makes sense to keep the window open for them. For example, it makes sense to always read one technology blog in Google Reader – most of the others will be repetitions and they should be kept away. Certain blogs have a smaller ratio of interesting content and they should be kept hidden until you want to see a longer list of unread items and read the ones you want.

I guess this is an example of where a feature-poor product takes share away from a powerful one because its limitations match up with the needs of its users.

Comments (0)

By Krishna, February 16, 2007

Several years ago, in college, I stayed back during a spring break to develop a cricket score management program in C using the Unix Curses library for the user interface. At that time, I was a huge cricket addict and spent (“wasted”) amazing amounts of time collecting cricket trivia. This application was an effort to record the scores during a cricket series and report all sorts of statistics like batting averages, top scores, etc. [Doing such fun projects is IMO a more enjoyable and better way to learn coding than official assignments.]

If you are familiar with the Unix environment, you will recall that compiling a C program results in an “a.out” executable and that the extension of a file really does not matter. I was in the habit of deleting the executable whenever my OCD kicked in. As I got lazy, I started using the “rm” command with wildcards and then one fine day, I missed a letter before hitting the ENTER key. I wasn’t using a source control system at that time. It felt pretty brutal losing that much work.

An incident like that can make one very scared of deleting anything and become obsessed with backups. For a while, that is exactly what I did. I grew into a master of storing copies of work in multiple places – local system, source control, email, backup tapes, etc. The pendulum had swung to the other extreme. But as time passed, I learned to stop worrying so much and start adopting different tactics. Here are some things I do now:

1. All work-related documents and code is in a version control system. We use Sourcegear Vault which, like most version control systems, offers different repositories and levels of access permissions. The version control system is itself backed up by the system administration team using enterprise backup software.
2. We have developed an internal project management tool that helps keep track of tasks and bugs and allows us to customize their workflow. If I want to give a task to someone, I or that person records it in this tool. We can add notes and attachments and also collaborate on content using wiki pages. This system acts like a separate hard disk for my brain. I also don’t have to keep MS Project files around and I just need a browser to access this application.
3. A lot of my personal stuff like email, contacts and calendar is online with various vendors like Yahoo! and Google. I keep a local copy – it is rather unlikely that the two sides will lose data at the same time. I use Intellisync to sync contact information between the online store and my desktop.
4. Once a month, I write everything onto a DVD and keep that in a safe place. That is a worst-case scenario backup.
5. Thanks to web search and easy Internet access, I no longer collect trivia and useless facts. Usually anything I want to know about is available online. Why waste time and money copying that knowledge again? The only stuff that I note down nowadays are important points from books that I read and saved in a private blog/website.
6. For the same reason, once I process information available on the Web, I delete the document or hyperlink. If the information is interesting, I add the link to my bookmark collection or del.icio.us. If it is really interesting, I blog about it.
7. I have been throwing out information I captured before. This is not an easy thing to do since I remember the effort I took to record it in the first place. So the information has to be available elsewhere or outdated for me to do this.

The balance feels good. I know that my data is secure. At the same time, I don’t have to worry about multiple copies lying all over the place and worrying which is the most recent one.

Comments (0)

By Krishna, February 14, 2007

Change management is difficult. But it doesn’t end after you make the change. After that, comes the often-overlooked and complicated challenge of communicating to stakeholders about the change and what it means for them. Convincing them is yet another uphill battle.

Usually, an organization initiates a change process with the purpose of bringing benefits to various people affected by its activities. For example, a quality process is launched so that the company can deliver products that perform better with lower rate of defects. Let us say that that quality process was successful and the company achieved its goals.

The problem is that most of the customers who buy the products generally have no idea about the new initiative or the fact that the quality of the product has improved. Matters are worse when there is already another company that leads the market with respect to the product attribute that has been improved. Take the case of the automobile industry or online search engines, where Japanese cars and Google respectively dominate the discussion on quality while others fail to impress despite their constant efforts to improve.

But even in the absence of a competitor, once a company or organization has acquired a negative reputation, it takes a lot of effort to dispel those impressions. A scandal, a product-related injury or even a prominent news review can set a company back years in the eyes of customers.

This is also true for individuals in a society. When an individual has committed errors in the past from simple bad behavior to serious crimes, society tends to view that individual through the same lens even as the person is trying to change their character. The lack of support makes the transition even more difficult. People are quick to condemn – it is easy and takes less effort than trying to know a person and help them change.

A particular case in business is the problem of a manager or employee who has not performed well in the past. The manager may have mismanaged projects and alienated his subordinates through indecision, anger or incompetence. The employee may not have delivered what she promised which may have caused heartburn for other employees.

Now the person realizes this and decides to improve themselves through self-learning or by attending a study program. Through various means, the individual becomes better at managing his or her work. But the deep-rooted mistrust of fellow workers is tough to overcome. There is an initial disbelief that the person has indeed changed, followed by questions about his or her motivations.

When co-workers think that the changed behavior is due to some mercenary intention on the part of the reformed employee, any support that they may offer that person is grudgingly given. This makes co-operation and team work very difficult.

If you were in the place of the newly changed manager or employee, what would you do? One step is to swallow one’s pride and acknowledge the truth, which is that mistakes (gross and egregious) were made in the past. Also instead of providing excuses for such errors, point to the root cause inside you: character flaws, lack of empathy, etc. Also explain to people about how you are trying to change yourself and what steps you are taking. The more humility and sincerity you can display, the better support you can get.

This is sometimes easier said than done. If you have hurt or treated a person very badly in the past, sometimes no amount of apologies may change that person’s feelings toward you. Life is like that: Even when you repent, you will continue to be haunted by the ghosts of your past. The best thing one can do for people in that case is to remove oneself from that environment so that one will no longer be an irritant. Make a fresh start and try to make good use of a second chance.

To summarize: Bad impressions formed over a long period of a person, department or company can be very difficult to change. When the cause is bad behavior itself, changing actions or becoming better is not enough to dispel such feelings. The person has to do a lot of convincing and demonstrate good behavior consistently for a long time before people start forgetting and forgiving the past.