Everybody goes through this phase (some stay in it forever) where maximum amount of time is spent in conceptualizing, ideating, and discussing the new thoughts. We as a team also used to do a lot of it previously. Undoubtedly an idea can be powerful, can provide breakthroughs, and we as humans are lucky to be the rare gifted species who can imagine things and conjure up images about the future. There was a time when just discussing an idea would provide immense excitement.
However, of late I realized that my attitude towards a good idea (or ideas in general) had become quite subdued. In my job, I am grappling on a daily basis with the just GTD (Getting things done)/execution. We learn daily about how complex it is to convert an idea to reality which is marketable, usable, scalable. For me an idea will excite me no end if I see it executed at least partially if not fully.
In my sphere of influence, I find that many people are caught up in idealogical world where they spend a lot of time thinking about the future (read dreaming), marveling at the creation of other people/companies (grass is greener on the other side of the fence), reading a lot about new technologies (mostly out of context and more than required) and doing precious little themselves to get any substantial work done.
Mind you, I am not disputing the power of an idea...but nothing can beat the power of a well executed idea. So what am I saying?
1. Think and learn in the context of the work in hand. (Lean thinking, lean learning, lean execution)
2. Execute it with demonic focus (read my previous blogs for some tips on how to do this)
3. Marvel at your own creation (Let other lazy people also marvel at your creation)
OK so lets get back to work now :-)
Friday, March 31, 2006
Tuesday, March 21, 2006
Being thorough
It was close to 10 P.M., with a release in progress. All the issues pertaining to the current development/checkin had passed the QA. But as part of the elaborate QA process, one of the elements is a smoke test of the entire product (recently introduced step, previously we would smoke only the changed areas of the code since we have a very dense automated testing system). During the 'full' smoke test the QA team started reporting issues unrelated to the current checkin and as I kept analyzing each issue to see where it originated, I discovered that these were a result of our old bad habits (quick development where the developer declares the code complete as soon as the file has been saved, cursory reviews with no review checklist/framework, hurried checkins, hurried or incidental QA with inadequate support via test cases, or automation etc.).
Of course we have come a long way and now (thanks to continuous and relentless improvements) can boast of a formal and very elaborate process for development, reviews, documentation and QA. As described in my previous blog posts, we have introduced templates (forms) for each stage and formalized the process to prevent slippages. As a result each checkin goes through heat treatment and typically results in almost no kickback in terms of reopened issues. In fact our lean production system with one piece flow allows us to make a strong release almost every week.
But last night, I realized something very important - after working with many developers during my tenure as a product manager, I can recall only a handful who were really thorough. This handful of guys, without any formal process, could produce high quality stuff, checkin all by themselves and get that code released. Today some of the reviews I do make me wonder, as to what would happen if I would let that get checked in as is (used to happen before and would cause Murphy's law to apply all the time - if anything can go wrong it will). Mind you, we are talking about really smart, intelligent and capable programmers who can design and construct good code but miss on the details/or are too distracted to be thorough in completion of their work or dont know what is completion.
I am sure if you are a product manager, project lead or development lead, you might have faced this type problem in your work...So how do we tackle this issue. I feel that being thorough is a habit/style of work that can be cultivated. Its not a genetic encoding.
For you the manager, you have to foster a culture of thoroughness:
1. Formalise the processes to define completion. Have forms which prompt and trap information which would otherwise be incidental. This makes quality consistent and not 'one of'.
2. Record the filled up forms with the checkin/release to help do post mortem analysis in case a problem is to surface later. This will help you identify process improvements, or genuine lapses in following the process.
3. Don't fix the code given to you for review - return it for rework with honest feedback to the developers on the problems, good points and recommendations. Use this as a way of mentoring. If you tend to take a shortcut and fix the code, you are actually leaving the developers with the impression that they have done a great job.
4. Stop when you face any problem and immediately fix the process, templates, infrastructure or whatever is required.
For the developer, be a hawk with an eye for detail:
1. Just coding is not enough: Please understand that just writing and compiling code successfully is not enough. You need to ensure it integrates well, all connections to other code are maintained, test cases are thorough, documentation of the design and code is done to promote easy maintenance, coding standards are followed, an honest self review is done etc.
2. Be thorough: Develop this habit (was the motto of my school) to get a grip on the details (remember god lies in the details and BTW the devil also lies in the details :-), make notes, search through code to handle changed connections (many times a product has modules/components written in different programming languages, legacy code, and a certain change may not get directly caught by a compilation e.g. dropping a database table from the storage but having the code still refer to it, will not get caught by a normal build of the code and if you are unlucky may never get caught unless it is too late).
3. Stay focused: Keep disturbances away (refer to my earlier blog posting)
4. Throw a challenge: for the lead/reviewer/qa to find bugs in your code (For this you have to be really confident...comes from following my tips above)
I hope the above tips help you grow as an individual and also contribute better to the company where you are working...All the best (P.S. I am toying with idea of rating developments and also reviews on a scale of 1-10)
Of course we have come a long way and now (thanks to continuous and relentless improvements) can boast of a formal and very elaborate process for development, reviews, documentation and QA. As described in my previous blog posts, we have introduced templates (forms) for each stage and formalized the process to prevent slippages. As a result each checkin goes through heat treatment and typically results in almost no kickback in terms of reopened issues. In fact our lean production system with one piece flow allows us to make a strong release almost every week.
But last night, I realized something very important - after working with many developers during my tenure as a product manager, I can recall only a handful who were really thorough. This handful of guys, without any formal process, could produce high quality stuff, checkin all by themselves and get that code released. Today some of the reviews I do make me wonder, as to what would happen if I would let that get checked in as is (used to happen before and would cause Murphy's law to apply all the time - if anything can go wrong it will). Mind you, we are talking about really smart, intelligent and capable programmers who can design and construct good code but miss on the details/or are too distracted to be thorough in completion of their work or dont know what is completion.
I am sure if you are a product manager, project lead or development lead, you might have faced this type problem in your work...So how do we tackle this issue. I feel that being thorough is a habit/style of work that can be cultivated. Its not a genetic encoding.
For you the manager, you have to foster a culture of thoroughness:
1. Formalise the processes to define completion. Have forms which prompt and trap information which would otherwise be incidental. This makes quality consistent and not 'one of'.
2. Record the filled up forms with the checkin/release to help do post mortem analysis in case a problem is to surface later. This will help you identify process improvements, or genuine lapses in following the process.
3. Don't fix the code given to you for review - return it for rework with honest feedback to the developers on the problems, good points and recommendations. Use this as a way of mentoring. If you tend to take a shortcut and fix the code, you are actually leaving the developers with the impression that they have done a great job.
4. Stop when you face any problem and immediately fix the process, templates, infrastructure or whatever is required.
For the developer, be a hawk with an eye for detail:
1. Just coding is not enough: Please understand that just writing and compiling code successfully is not enough. You need to ensure it integrates well, all connections to other code are maintained, test cases are thorough, documentation of the design and code is done to promote easy maintenance, coding standards are followed, an honest self review is done etc.
2. Be thorough: Develop this habit (was the motto of my school) to get a grip on the details (remember god lies in the details and BTW the devil also lies in the details :-), make notes, search through code to handle changed connections (many times a product has modules/components written in different programming languages, legacy code, and a certain change may not get directly caught by a compilation e.g. dropping a database table from the storage but having the code still refer to it, will not get caught by a normal build of the code and if you are unlucky may never get caught unless it is too late).
3. Stay focused: Keep disturbances away (refer to my earlier blog posting)
4. Throw a challenge: for the lead/reviewer/qa to find bugs in your code (For this you have to be really confident...comes from following my tips above)
I hope the above tips help you grow as an individual and also contribute better to the company where you are working...All the best (P.S. I am toying with idea of rating developments and also reviews on a scale of 1-10)
Friday, March 17, 2006
Keeping disturbances handy
It was noon and I sat down to do a design/code review as part of our development process. I had just wrapped up my sundry tasks of responding to mail, checking the status of ongoing projects, going to the loo, drinking water before settling into the review. Yes, for me a review of design and code before it goes further down the pipe is the most important part of the process. (Refer to my earlier postings about the importance of reviews, or where it is cheapest to fix bugs). Just as I started reading the specifications and design, my cell rang. It was one of our deployment engineers onsite at a customer location asking for some help in using one of the new features. After I finished the call and struggled to revert my attention to the review (yes its very difficult to switch your mind amongst activities easily), one of my team members called out to me for some quick help on some design decisions (Yes I don't have a cabin and sit in the middle of my group and am easily accessible - a boon and a bane). Once done with that, I again struggled and restarted the review. But by now my initial focus was disturbed and the two discussions (during the disturbances) were coming back to me to think about. It was like not being able to work at work.
I stopped what I was doing to reflect on this. I looked around and observed what other people in my team were doing. I also walked around to other divisions to see what those teams were doing. I saw one set of people intently doing their work (coding, diagramming, documenting, invoicing, selling etc) and another set of people talking to friends, chatting with friends on IM, browsing unrelated sites, and generally appearing to wile away their time. This was of course a sampler at a given moment but I also realized that these are the same set of people who keep their "disturbances handy" like I did when I started my review. i.e. Make it easy to be disturbed ( I am assuming that they are committed to the job; there are a set of people who wait for the day to end... this article is not about them). I also realized that there are two basic types of activities one where you create (a document, code, design, review...) and another were you maintain (run a process like front desk, recruitment, etc). In the case of the former, being disturbed is sure to bring down the quality of the work since the very nature of that work demands undivided attention and laser like focus to get it done (no wonder that Bill Gates takes two weeks off by himself on an island to figure out the future of Microsoft). As for the latter, the mind is not creating and is not in a stressed state trying to retain connections, make logical links, theorize etc so it can afford to be disturbed)
My recommendations while creating:
1. Isolate yourself so you will not be disturbed during that time.
2. Schedule such work at times when you are least likely to be needed urgently.
3. Turn off the phone, email and chat pop ups since these are like the door bell (Humans are inadvertently trained to respond to the doorbell and phone ring, dropping whatever they are doing, literally).
4. Focus on the task at hand.
5. Divide your time into sections where you are available for discussions, you respond to mail, return phone calls etc and sections where you are invisible.
Even as I write this, I was disturbed thrice...hope you will excuse any break in the flow due to that :-). I am going home now to complete the review...at least there only my dog will disturb me.
I stopped what I was doing to reflect on this. I looked around and observed what other people in my team were doing. I also walked around to other divisions to see what those teams were doing. I saw one set of people intently doing their work (coding, diagramming, documenting, invoicing, selling etc) and another set of people talking to friends, chatting with friends on IM, browsing unrelated sites, and generally appearing to wile away their time. This was of course a sampler at a given moment but I also realized that these are the same set of people who keep their "disturbances handy" like I did when I started my review. i.e. Make it easy to be disturbed ( I am assuming that they are committed to the job; there are a set of people who wait for the day to end... this article is not about them). I also realized that there are two basic types of activities one where you create (a document, code, design, review...) and another were you maintain (run a process like front desk, recruitment, etc). In the case of the former, being disturbed is sure to bring down the quality of the work since the very nature of that work demands undivided attention and laser like focus to get it done (no wonder that Bill Gates takes two weeks off by himself on an island to figure out the future of Microsoft). As for the latter, the mind is not creating and is not in a stressed state trying to retain connections, make logical links, theorize etc so it can afford to be disturbed)
My recommendations while creating:
1. Isolate yourself so you will not be disturbed during that time.
2. Schedule such work at times when you are least likely to be needed urgently.
3. Turn off the phone, email and chat pop ups since these are like the door bell (Humans are inadvertently trained to respond to the doorbell and phone ring, dropping whatever they are doing, literally).
4. Focus on the task at hand.
5. Divide your time into sections where you are available for discussions, you respond to mail, return phone calls etc and sections where you are invisible.
Even as I write this, I was disturbed thrice...hope you will excuse any break in the flow due to that :-). I am going home now to complete the review...at least there only my dog will disturb me.
Subscribe to:
Posts (Atom)
