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)
Subscribe to:
Post Comments (Atom)
9 comments:
fonta fetoprotein compromise physician choices largeness chargesother dined origin incident corec
masimundus semikonecolori
Well your article helped me terribly much in my college assignment. Hats incorrect to you enter, intention look progressive for more related articles without delay as its sole of my choice topic to read.
I really liked this information, I think it is good to learn about these things, I would like some day to receive any update of this information so interesting
since I was a teenage, I became interested in reading, I think it is good practice, especially when it is a very interesting blog, thanks for sharing the information!
when I was in college I liked to be on the Internet reading information like this, I have always said that it is useful to learn new things that may serve in different circumstances
hello friends, I read your blog and found it very interesting and professional, the information is very interesting, I wonder if you have any update on the item. This information about Being thorough deserves to be read by everyone! Thanks for sharing!
It was on the newspaper when he saw the watch again. How time flies! 50 years had passed since he saw it the last time. He never stopped finding it during the 50 years. He was too old to remember too many things. However, everything about her was still engraved in his mind and never disappeared.[url=http://www.good4shopper.com/concord-watches.html]replica concord watches[/url] [url=http://www.watcheshall.com/cartier-watches.html]Cartier watches[/url] [url=http://www.sunglassescool.com/burberry-sunglasses.html]boss eyeglasses[/url] Rolex has excellent styles for both males and females, and the price ranges enormously so that most consumers can have a satisfying Rolex. This ladies?Rolex President is the ideal watch for the excellent females. It is made of 18k yellow gold, including the crown and the flutes bezel. it has the custom champagne diamond dial with 10 round cut diamonds. The crystal is of scratch-resistant sapphire conversion. The President Bracelet is powerful, giving the watch a modern look. It is the synonym of luxury and elegance and is suitable for the finest tastes. Some other popular dial colors including silver and white and mother of pearl are also provided. The consumers can choose according to personal taste. This style is very popular among today young professional women.
It's an excellent decision to apply the lean system's one piece flow to your manufacturing firm. A simulation shows that it is very effective, especially if you want to increase production time, but have no room for another employee. You should look into a poka yoke presentation as well. It's a fool-proofing technique derived from Japanese ingenuity, similar to the Lean system!
I totally agree on your point of view. Very interesting blog post.
Post a Comment