A friend was asked to translate the following sentence to another language. The author was an "experienced senior software engineer" in a large Indian software services company.
"We were bit used to use remote desktop, but I will do the necessary actions to check this option and shift the full activity independent for the remote option."
Showing posts with label work. Show all posts
Showing posts with label work. Show all posts
Friday, June 25, 2010
Monday, February 02, 2009
Customer Support @ Megacorp
First, about Megacorp: there is no such thing. Megacorp is an imaginary organization which represents all organizations where I or my friends have worked at some point. Many thanks to Ravi Mohan for coming up with the idea.
Megacorp developed a tool/product which was mostly used by its own employees. As the tool was fairly useful it came to be widely adopted. Soon enough there were bug reports, requests for new features and general questions. Initially these requests were managed through phone calls and emails. While convenient in the beginning the situation soon became worse with customers ringing up arbitrary team members to demand help. As things got close to crazy the development team suggested using a single point of contact and some tool like Trac to track such requests.
The new manager heard them out and decided to implement it - albeit with some variations. For starters Trac would not be used. Instead a new all-round-management-reporting system would be "adapted". Said system was the brainchild of the manager, purchased by paying extravagant costs and took months to get up and running. All the while the mayhem continued. Eventually the new system was inaugurated. Users could log new tickets, engineers could view them and so on. There was one major feature change courtesy the Manager. The tickets could only be closed by *whoever initiated it*.
A month or so later the development team got a memo from the manager asking about the large number of open tickets. "Because we can't close them" came the reply. Manager seemed bemused. "Of course *you* cannot close them. I wanted to know why you are not getting them closed by asking the customers". Explanations about the difficulty in doing this were brushed off. Soon the development team were back to working the phones - except this time they were calling the customers and asking them to close the tickets. As most of the customers traveled around for work it was difficult to reach them. Many also seemed reluctant to close tickets as they had not been fixed to "their satisfaction". Some customers had forgotten how to log in or their passwords had expired (the system forced you to change your password every month). They could do nothing until the log in problem had been fixed. Most developers soon gave up.
Several months later it was time for the audit. Manager was surprised to see open tickets which were months old. Finally realizing the futility of trying to get the tickets closed she asked the system administrators to close ALL of them - even those which had legitimate reasons to be open. Ta da! The audit was a huge success.
Last heard the manager was rewarded for successfully introducing the all-round-management-reporting system. The developers and the customers alike dumped the system and were back to calling each other.
Megacorp developed a tool/product which was mostly used by its own employees. As the tool was fairly useful it came to be widely adopted. Soon enough there were bug reports, requests for new features and general questions. Initially these requests were managed through phone calls and emails. While convenient in the beginning the situation soon became worse with customers ringing up arbitrary team members to demand help. As things got close to crazy the development team suggested using a single point of contact and some tool like Trac to track such requests.
The new manager heard them out and decided to implement it - albeit with some variations. For starters Trac would not be used. Instead a new all-round-management-reporting system would be "adapted". Said system was the brainchild of the manager, purchased by paying extravagant costs and took months to get up and running. All the while the mayhem continued. Eventually the new system was inaugurated. Users could log new tickets, engineers could view them and so on. There was one major feature change courtesy the Manager. The tickets could only be closed by *whoever initiated it*.
A month or so later the development team got a memo from the manager asking about the large number of open tickets. "Because we can't close them" came the reply. Manager seemed bemused. "Of course *you* cannot close them. I wanted to know why you are not getting them closed by asking the customers". Explanations about the difficulty in doing this were brushed off. Soon the development team were back to working the phones - except this time they were calling the customers and asking them to close the tickets. As most of the customers traveled around for work it was difficult to reach them. Many also seemed reluctant to close tickets as they had not been fixed to "their satisfaction". Some customers had forgotten how to log in or their passwords had expired (the system forced you to change your password every month). They could do nothing until the log in problem had been fixed. Most developers soon gave up.
Several months later it was time for the audit. Manager was surprised to see open tickets which were months old. Finally realizing the futility of trying to get the tickets closed she asked the system administrators to close ALL of them - even those which had legitimate reasons to be open. Ta da! The audit was a huge success.
Last heard the manager was rewarded for successfully introducing the all-round-management-reporting system. The developers and the customers alike dumped the system and were back to calling each other.
Wednesday, August 13, 2008
Another Recital and Related Thoughts
I played the Piano at a small recital organised in my teacher's home last month. This was my second recital this year. I played two pieces - Theme and Variations by Theodore Kullak and Rocking Horse Ride (Opus 98, No. 5) by Alexander Gretchaninov. Kullak's piece presents a theme followed by five variations of that theme. The hand positions are fixed and the tempo increases in the fourth and fifth variations. 'Rocking Horse Ride' is taken from Gretchaninov's 'Children's Book'. It tells about a rocking horse that starts off slowly enough but soon accelerates and almost rocks too far. But all is well in the end.
The single most important difference from my previous recital was my increased confidence. This was not entirely surprising given that I had prepared myself better this time around. It helped that I had been out of work for a couple of weeks before D-Day. And I forced myself to take a quick nap in the afternoon before the event. It was a refreshing contrast from the previous before-recital afternoon when I was tightly wound up and excited.
All of it paid off in the end. I did not mess up any notes but I did feel that I could have done better on the dynamics.
On a related note I was told that my music practice had noticeably improved ever since I left my job. This was a bit surprising especially since I had not drastically lengthened my practice sessions. I think reduced stress levels made most of the difference. In retrospect I can see that work had been so draining that I had become used to being perpetually wound up and did not notice how it was degrading the quality of my life.
I don't seem to be the alone in being stressed out. I learned from my teacher that there was a time when recitals were far more frequent. According to her pupils these days (that includes me) take much longer to get ready for a recital. She stressed how barely half a generation ago pupils - who were also at school, had a job or were otherwise busy - were somehow able to find time to do justice to music. With every passing year pupils seem to have less and less time to practice, or indeed to focus on anything much outside work.
I have decided to actively combat stress the next time I start working a job. This would mean working regular hours, leaving work behind on stepping out of the office, learning to turn off my phone after hours and during weekends. I don't know how I'll achieve all these but I certainly am not going to let work deprive me of life again.
The single most important difference from my previous recital was my increased confidence. This was not entirely surprising given that I had prepared myself better this time around. It helped that I had been out of work for a couple of weeks before D-Day. And I forced myself to take a quick nap in the afternoon before the event. It was a refreshing contrast from the previous before-recital afternoon when I was tightly wound up and excited.
All of it paid off in the end. I did not mess up any notes but I did feel that I could have done better on the dynamics.
On a related note I was told that my music practice had noticeably improved ever since I left my job. This was a bit surprising especially since I had not drastically lengthened my practice sessions. I think reduced stress levels made most of the difference. In retrospect I can see that work had been so draining that I had become used to being perpetually wound up and did not notice how it was degrading the quality of my life.
I don't seem to be the alone in being stressed out. I learned from my teacher that there was a time when recitals were far more frequent. According to her pupils these days (that includes me) take much longer to get ready for a recital. She stressed how barely half a generation ago pupils - who were also at school, had a job or were otherwise busy - were somehow able to find time to do justice to music. With every passing year pupils seem to have less and less time to practice, or indeed to focus on anything much outside work.
I have decided to actively combat stress the next time I start working a job. This would mean working regular hours, leaving work behind on stepping out of the office, learning to turn off my phone after hours and during weekends. I don't know how I'll achieve all these but I certainly am not going to let work deprive me of life again.
Wednesday, April 16, 2008
Extreme Programming in Action
Extreme Programming has become more "mainstream" in the Indian software industry over the past couple of years. For many companies their agile development practices have provided a reason to brag and to attract recruits. One of my friends works for such a company and recently narrated an incident highlighting how "XP" is used in his workplace. I thought I should share it with the rest of the world to provide another perspective on how XP is actually used in Bangalore.
The specific case involved a particular task which came up for development. One of the developers said that it would take him 2 days to finish the task while another thought he could complete it in 3 days. A third predicted four days if he were to do the task. The team leader heard them all out and proceeded to *assign* the task to the third guy. If you are thinking "that's not how it is done in XP" - wait, the best is yet to come. The "leader" expected the "assigned" developer to finish the task in 2 days!
From what I heard the practice is not only widespread in the said organisation but some managers actually *coach* sceptical newcomers to believe that this "auction model" is a core tenet of XP. Those who disagreed are reprimanded for unwillingness to adhere to XP.
The next time someone from this place says "we follow XP" I am going to burst a gut laughing :)
The specific case involved a particular task which came up for development. One of the developers said that it would take him 2 days to finish the task while another thought he could complete it in 3 days. A third predicted four days if he were to do the task. The team leader heard them all out and proceeded to *assign* the task to the third guy. If you are thinking "that's not how it is done in XP" - wait, the best is yet to come. The "leader" expected the "assigned" developer to finish the task in 2 days!
From what I heard the practice is not only widespread in the said organisation but some managers actually *coach* sceptical newcomers to believe that this "auction model" is a core tenet of XP. Those who disagreed are reprimanded for unwillingness to adhere to XP.
The next time someone from this place says "we follow XP" I am going to burst a gut laughing :)
Friday, March 14, 2008
A Sabbatical Test
One of my friends recently acted on his wish to take some time off from work. He just started a three month break from work. Every now and then I think about taking some time off from work myself. After watching my friend leave town for his sabbatical I gave the topic some active consideration. I realised that while the idea of taking time off from work was very tempting I would have to plan extensively to make it serve my purpose. Following a thought exercise I came up with a check list of things to accomplish before I can take time off. Note that the ordering is random.
1. Build A Monetary Base. I should have enough dough in the bank to cruise for the duration of my sabbatical. The time frame I have in mind is about a year. Whether I plan to leave Bangalore or stay in town makes a big difference in the estimate. I can think of a couple of other places that are cheaper but have other, outweighing disadvantages. For instance Chennai is too hot, Trivandrum is too remote and I don't know anyone in Pune :)
2. Plan Ahead. I have wasted far too many weekends for lack of proper planning. I do not wish to repeat this mistake during my sabbatical. I will have to work out a clear, weekly (or at least monthly) plan before I start my break.
3. Establish Habits In Advance. This follows from #2. I know from experience that even optimistic plans fail because I am not used performing a particular set of tasks regularly. Mental exercise is similar to physical exercise in this context. Even a modestly mind-intensive schedule needs a period of "warming up". I would rather do all the warming up work before I start rather than use the first days/weeks/months of the sabbatical for the same. This involves enforcing basic habits like going to bed and getting up at regular times, not getting "lost" for (unplanned)hours in a task however exciting it is etc.
4. Establish A Ready-to-expand Routine. This derives from #2 and #3. I spend around 10 hours at work each day including getting there and back. While all non-work activities look very attractive from the workplace it is not easy to effectively use the 10 hour or so of daily unstructured time that follows leaving work. One solution for the weak minded like me would be to establish in advance a routine that is "ready to expand". In other words I should use the time available to me *after work* every day to the maximum extent possible. Ideally this should lead to a point where any time off from work would be easily filled by one or more of the activities I have been doing.
Good examples include music practice and coding. Say I can spare 90 minutes for music practice each day, split into two 45 minute sessions before and after work. If I can take up a suitably complex piece that demands more than 90 minutes daily and work on it regularly for exactly 90 minutes a day then I would be making progress on conditions #3 and #4.
Similarly I should be able to pick up a a challenging programming goal and spend a fixed quantity of time, say 90 minutes, each day for a suitably long period.
Another important aspect in my case would be to perform *all* tasks *every* day. I don't think it would be realistic to divide a sabbatical into two or more consecutive periods where I only work on any one thing at a time. IMHO the key to making a sabbatical work is to make a little progress on all fronts every day.
5. Set "Service Level Agreements" For Friends And Family. IMHO a sabbatical is *not* a vacation. It is a life project with specific time duration and goals. I should make it clear to friends and family that just because I am "out of a job" they shouldn't expect me to spend additional time/energy thus gained on lengthy visits or other activities. If anything I expect to be busier during a sabbatical than I would have been while working.
Update: One of my friends who wishes to remain anonymous had this useful point to add: "Having a test (to be taken at the end of the period or at specific times) to check whether the purpose of the sabbatical has been achieved will be useful too. The act of coming up with the test will bring the why (take the sabbatical) question into focus. I suppose this will be an outcome of the planning activity."
1. Build A Monetary Base. I should have enough dough in the bank to cruise for the duration of my sabbatical. The time frame I have in mind is about a year. Whether I plan to leave Bangalore or stay in town makes a big difference in the estimate. I can think of a couple of other places that are cheaper but have other, outweighing disadvantages. For instance Chennai is too hot, Trivandrum is too remote and I don't know anyone in Pune :)
2. Plan Ahead. I have wasted far too many weekends for lack of proper planning. I do not wish to repeat this mistake during my sabbatical. I will have to work out a clear, weekly (or at least monthly) plan before I start my break.
3. Establish Habits In Advance. This follows from #2. I know from experience that even optimistic plans fail because I am not used performing a particular set of tasks regularly. Mental exercise is similar to physical exercise in this context. Even a modestly mind-intensive schedule needs a period of "warming up". I would rather do all the warming up work before I start rather than use the first days/weeks/months of the sabbatical for the same. This involves enforcing basic habits like going to bed and getting up at regular times, not getting "lost" for (unplanned)hours in a task however exciting it is etc.
4. Establish A Ready-to-expand Routine. This derives from #2 and #3. I spend around 10 hours at work each day including getting there and back. While all non-work activities look very attractive from the workplace it is not easy to effectively use the 10 hour or so of daily unstructured time that follows leaving work. One solution for the weak minded like me would be to establish in advance a routine that is "ready to expand". In other words I should use the time available to me *after work* every day to the maximum extent possible. Ideally this should lead to a point where any time off from work would be easily filled by one or more of the activities I have been doing.
Good examples include music practice and coding. Say I can spare 90 minutes for music practice each day, split into two 45 minute sessions before and after work. If I can take up a suitably complex piece that demands more than 90 minutes daily and work on it regularly for exactly 90 minutes a day then I would be making progress on conditions #3 and #4.
Similarly I should be able to pick up a a challenging programming goal and spend a fixed quantity of time, say 90 minutes, each day for a suitably long period.
Another important aspect in my case would be to perform *all* tasks *every* day. I don't think it would be realistic to divide a sabbatical into two or more consecutive periods where I only work on any one thing at a time. IMHO the key to making a sabbatical work is to make a little progress on all fronts every day.
5. Set "Service Level Agreements" For Friends And Family. IMHO a sabbatical is *not* a vacation. It is a life project with specific time duration and goals. I should make it clear to friends and family that just because I am "out of a job" they shouldn't expect me to spend additional time/energy thus gained on lengthy visits or other activities. If anything I expect to be busier during a sabbatical than I would have been while working.
Update: One of my friends who wishes to remain anonymous had this useful point to add: "Having a test (to be taken at the end of the period or at specific times) to check whether the purpose of the sabbatical has been achieved will be useful too. The act of coming up with the test will bring the why (take the sabbatical) question into focus. I suppose this will be an outcome of the planning activity."
Thursday, September 14, 2006
Advantages of working on Decent Code
I recently switched employers for the first time in my working career. After spending six and a half years with a huge (tens of thousands of employees) software services company I recently moved to a much smaller product company. After the initial few weeks getting acquainted, trained etcetera, I recently started hacking away at the code base. It came as a surprise to me that after three days spent adding enhancements to an existing (mostly Java) application I was no where near as stressed as I would have been in the past. I realised that this was mostly thanks to the decent code base that the application's developers had created in the first place. The code did nothing extraordinary; it was merely well structured, cleanly packaged and came with a good many automated tests. And boy, what a change it made. No need to spend days merely building the app; no more personal source code repositories (I have been forced to install CVS in my machine on several occasions in the past thanks to general ignorance about SCM tools).
The contrast with what I have been through while with my previous employer could not have been starker. I have worked in half a dozen 'legacy' applications for my previous employer and not once have I not been frustrated by poorly written code. Adding insult to injury were the indifferent "developers" who had created the monster in the first place.
The moral of the story is that good code goes a long way towards stress reduction and boosting employee happiness. Should I need to change jobs in the future, I will ask any potential employer to show me their existing code base. If the code sucks, I will politely bow out.
The contrast with what I have been through while with my previous employer could not have been starker. I have worked in half a dozen 'legacy' applications for my previous employer and not once have I not been frustrated by poorly written code. Adding insult to injury were the indifferent "developers" who had created the monster in the first place.
The moral of the story is that good code goes a long way towards stress reduction and boosting employee happiness. Should I need to change jobs in the future, I will ask any potential employer to show me their existing code base. If the code sucks, I will politely bow out.
Saturday, April 22, 2006
Taking the Joel Test
Recently I had a chance to read Joel Splosky's article 'The Joel Test: 12 Steps to Better Code' After reading through the article I took a few minutes to evaluate a software services company that I am familiar with using the 12 questions that constitute the test. I have reproduced the questions and my answers below.
Do you use source control? - No. Most projects that use source control tools do not use them the proper way. Archiving and taking back-ups is NOT Version Control.
Can you make a build in one step? - No.
Do you make daily builds? - No. Build process starts several days (or hours) before delivery. It starts 'offshore' and continues 'on-site'.
Do you have a bug database? - Not in all projects. In fact only a minority of the projects use any kind of bug tracker.
Do you fix bugs before writing new code? - No!
Do you have an up-to-date schedule? - Not really.
Do you have a spec? - Yes.
Do programmers have quiet working conditions? - No!
Do you use the best tools money can buy? - No. (Tools?! *Buy* tools? Are you crazy?)
Do you have testers? - Yes.
Do new candidates write code during their interview? - No! (Code?! Are you crazy?)
Do you do hallway usability testing? - What's that???? Oh you want an answer? Well, the answer is No.
According to Joel, A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.
This particular company rated 2. It would rate 3 if I grudgingly treat a partial 'Yes' as a full 'Yes' for Question #4 (Bug Database).
Try this for yourself. Be honest. Look long and hard at the results. If you are employed in the Indian software services industry, you have permission to weep.
Do you use source control? - No. Most projects that use source control tools do not use them the proper way. Archiving and taking back-ups is NOT Version Control.
Can you make a build in one step? - No.
Do you make daily builds? - No. Build process starts several days (or hours) before delivery. It starts 'offshore' and continues 'on-site'.
Do you have a bug database? - Not in all projects. In fact only a minority of the projects use any kind of bug tracker.
Do you fix bugs before writing new code? - No!
Do you have an up-to-date schedule? - Not really.
Do you have a spec? - Yes.
Do programmers have quiet working conditions? - No!
Do you use the best tools money can buy? - No. (Tools?! *Buy* tools? Are you crazy?)
Do you have testers? - Yes.
Do new candidates write code during their interview? - No! (Code?! Are you crazy?)
Do you do hallway usability testing? - What's that???? Oh you want an answer? Well, the answer is No.
According to Joel, A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.
This particular company rated 2. It would rate 3 if I grudgingly treat a partial 'Yes' as a full 'Yes' for Question #4 (Bug Database).
Try this for yourself. Be honest. Look long and hard at the results. If you are employed in the Indian software services industry, you have permission to weep.
Monday, March 06, 2006
The Reverse Truck Factor
The speaker at a recent technology user group meeting introduced me to the concept of "Truck Factor" of software projects. The Truck Factor (TF) is defined as the number of people who would need to be hit by a Truck to seriously jeopardize the project. It is a measure of the number of people the project cannot do without; the higher the number the better. Interesting.
I quickly did a mental exercise to find out the TF for the projects that I have worked in. It dawned on me that not only was the TF very small, there was a Reverse Truck Factor (RTF) in play. I define RTF as the number of people who need to be hit by a truck (or several, just to be sure) for the project to stabilise and have anywhere near a decent chance of achieving what it is supposed to. The lower the RTF, the better are the chances of a project to succeed.
Unfortunately for me, the RTF has been consistently high in almost all the projects that I have worked in as part of the software "services" industry. With just one or two notable exceptions, Managers could always be counted while deriving the RTF.
I quickly did a mental exercise to find out the TF for the projects that I have worked in. It dawned on me that not only was the TF very small, there was a Reverse Truck Factor (RTF) in play. I define RTF as the number of people who need to be hit by a truck (or several, just to be sure) for the project to stabilise and have anywhere near a decent chance of achieving what it is supposed to. The lower the RTF, the better are the chances of a project to succeed.
Unfortunately for me, the RTF has been consistently high in almost all the projects that I have worked in as part of the software "services" industry. With just one or two notable exceptions, Managers could always be counted while deriving the RTF.
Subscribe to:
Posts (Atom)
Posts
