Tuesday, November 15, 2011

Nuggets from the book - The Checklist Manifesto



I have listening to the audio-book - The Checklist Manifesto: How to Get Things Right  by Atul Gawande. I definitely recommend the book, as it is a fascinating read.


In the book Gawande says “The checklist gets the dumb stuff out of the way, the routines your brain shouldn’t have to occupy itself with, and lets it rise above to focus on the hard stuff…” 

In other words, a checklist can help you

  • work smarter
  • get all necessary tasks completed, 
  • avoid overlooking the little things that can unravel an entire project, and 
  • ensure that you’ve got key information available, 
  • remind you to communicate with all key stakeholders. 

The Checklist Manifesto looks at the use of checklists in surgery, construction, investment banking, and aviation. Gawande provides some very compelling arguments for using checklists from the simple to the most complex of situations.


DEVELOPING A CHECKLIST 


  • Decide whether the situation calls for a DO-CONFIRM checklist or a READ-DO checklist 
  • Outline all the steps in a process that need to be followed 
    • Review situations that went wrong, identify overlooked steps and ensure those are included on the checklist 
  • Ensure the right people are reviewing and approving the checklist components 
  • Include a publication date on the checklist, as it will be revised often 
  • Add “pause points” at which you or the team must pause and run through a set of checks before moving onto your next steps 
    • Especially pertains to a DO-CONFIRM checklist type, where one distinct group of critical steps have to be completed before another set of tasks should be undertaken 
  • Include a ‘communication’ check to ensure that at necessary points in a process key stakeholders are communicating about the project status, next steps, and so forth 
  • Keep checklists simple, to one page, and with an easy to read font type 
  • As needed, get leadership onboard with embracing and promoting the use of checklists 
  • Test the checklist in actual, real-life situations 
  • Refine and test the checklist until it succeeds at consistently improving the process and outcomes for which it is being applied 
  • Schedule a regular checklist review schedule 
  • Determine if using the checklist in one business unit or team will require other process changes to be implemented elsewhere in the company (and make a checklist for them!)


Golden Nuggest from the book - PeopleWare (By Tom DeMarco and Timothy Lister)



Summed up in one sentence, Peopleware: Productive Projects and Teams (Second Edition)
say: 
Give smart people physical space, intellectual responsibility and strategic direction



DeMarco and Lister advocate: 
  • private offices and windows. 
  • creating teams with aligned goals and limited non-team work. 
  • managers finding good staff and putting their fate in the hands of those staff
  • The manager's function is not to make people work but to make it possible for people to work
  • managers should help programmers, designers, writers and other brainworkers to reach a state that psychologists call "flow" - an almost meditative condition where people can achieve important leaps towards solving complex problems

The best way to describe this book would be as an Anti-Dilbert Manifesto

DeMarco and Lister attack cubicles, dress codes, telephones, hiring policies, and company core hours and demonstrate how managers who are not insecure about their positions, who shelter their employees from corporate politics, who, in short, make it possible for people to work are the ones who complete projects and whose employees have fun doing so.

Programming languages come and go with an occasional paradigm shift thrown in. However, the thought processes and the mental gyrations needed to complete large software projects remain largely unchanged


Top Ten Idea Killers in Software Development


Software engineers start out as being curious, enthusiastic and gung-ho about getting things done. Somewhere along the way, they butt heads against a world that doesn't understand software development: systems that count engineers by numbers, productivity by lines of code and quality by process; a world where software development is a "risk-management" bureaucracy rather than a creative endeavor that can solve customer problems.
Unfortunately, many engineers consider this a wake-up call to shed their energy and adopt those bureaucratic ways, convinced that they have stepped into a new, adult world of "management". Some who manage to resist that misstep become disillusioned and don the garbs of martyrdom, ascribing every failure to something that management did or did not do.   
If you are a software engineer, or an engineering manager, here's a list to help you identify if you still retain your software development genes or have morphed into someone that brings out a worn out list of cliches to robotically throw into every meeting, killing every idea and the morale behind it:
10. "This is good enough" : The fact is that nothing is ever good enough, least of all software. It may be good enough for today, or this release, but if your product has had the same problem for the last decade 1, some other company has already taken your customer away because of this feature. Fix it before you reach the point where you cannot.2
9. "This is how it was always done": This is an anachronism in any competitive, rapidly changing field but particularly in software. Software companies are not like automobile companies that can set an assembly line in place and forget about it for a hundred years. Oh, wait-a-minute! Even automobile companies cannot do that anymore! Today's problems require a new set of solutions because in an industry fantastically bound to Moore's Law, machines, along with people's expectations from them, set a terrific pace of change.

8. "There isn't enough time to do it right": This is how you get into Technical Debt; some of it may be inevitable due to business pressures or working with a new piece of hardware or technology. As long as you repay this debt in the immediate future, this is part of the process; but if this is how you avoid making the right decision and the responsibility that goes with it, you are not being true to your engineering origins.

7. "This requires core architectural changes": What doesn't? Ideally, a well-designed piece of software should be flexible and amenable to changes as the product develops. But as we've said, demands on software change rapidly and every piece of software written will need to be rewritten. This is the nature of the work, not an anomaly to be used as an excuse!

6. "Management has not prioritized it": I always want to ask: what exactly hasn't management prioritized -- making a good product? writing error-free code? reducing bugs in the field? making the customer happy? Agreed that sometimes we inherit legacy code and there is juggling to be done between fixing what exists versus writing new code but this is a specious argument as we will see below. Suffice it to say that engineering needs to set and execute its own priorities, however small, every day, instead of waiting for some giant, magical mandate from above, because that's never going to happen.

5. "There is already a lot on our plate": This is one of those nonsense tautologies that add nothing to the discussion. The focus is no longer the idea or how it should be executed but some longstanding grouse about 'having no resources' or some customer's bug list. Of course you have a lot on your plate! You are being paid to have that stuff on your plate -- start chowing down!

If an idea is worth executing, its adoption should not depend on whether you have a lot on your plate; if you fill your plate at the buffet with junk and decide you can't have a desired dish because your plate is full, you have done two things wrong: you chose the wrong things to begin with and then haven't done the simple math that you have to throw the junk off your plate to get what you want. You don't kill the idea, you clean your plate.

4. "Our software is very complex; we have to be careful about making changes": Check another nonsense tautology off the list. What enterprise software isn't complex? Are you saying you are usually not careful when writing code? You are a software engineer -- you are expected to deal with complexity and be careful about making changes -- that's a basic requirement. If this is a reason we as engineers cannot execute an idea, we need to go back to relearn the basics.

3. "No one is asking for it": This reminds me of Henry Ford's wry comment "If I’d asked people what they wanted, they would have said 'a faster horse'." Human beings are incredibly adaptable -- they will live with anything, including, as Ford observed, horse manure. If you give your customers a substandard product, they will live with it. But remember that humans are incredibly fickle, too; an idea you kill will only bloom in another company's garden. Being sloppy just because our software is "sticky" -- short for "the customer hates us but can't change because it's too much work" -- is setting the bar at a level that's not worthy of a true engineer.

2. "We have to have consensus": This is at number two for a reason -- it's a seemingly innocuous statement with noble intent that is insidious and on closer inspection, meaningless in the software context. Consensus is given undue importance in everything from design meetings, SRS/SDS3 reviews, documentation, QA practices etc. Software development is an expertise-driven exercise. Someone has spent years studying, learning and working in a specific field, and to not defer to that person for the final decision is to waste all that expertise, not to mention deliver a bad product, demoralize the expert, adopt the safest and most timid way and most insidious of all, diffuse accountability.

A group decision is a way to duck responsibility for the outcome. "We all decided together" is a way of saying "No one is responsible". We have a presidential system instead of a parliamentary system for a reason: the congress advises the president but the president makes the decision. Unless the decision is so obviously horrendous that 2/3rds of congress decides to override the decision, the president's decision stands. This is the only way the buck can stop at the president's desk.

And the #1 idea killer in software development is
1. "It can't be done": There is nothing that cannot be done in software. Non-engineers kid around with "It's only software, right?" as a way to gently provoke engineers but it's true! It is indeed only software. Engineers should respond with specifics of what it takes to implement rather than say something cannot be done. A statement like "It will take 15 engineers, with individual licenses for software xyz, with 30 Model ABC machines, each with 2 TB of storage with at least 250GB in SSD storage and 5 QA personnel for a period of 1 year to deliver this software" instead of "it can't be done."
Everything can be done; let's get into that mindset first. The rest will fall into place.

Footnotes
1. Anyone who has worked on enterprise software can give you a long list of "known bugs" that have been around for more than a decade
2. Sometimes you cannot because too much code has grown around the defect and changing it is just too darn difficult at this point; or because the software died under the burden of too many such defects; or you no longer have a job because the company folded. It happens.
3. Software Requirements Specification/Software Design Specification





Source: Navneeth Mandavilli @ computer.org


Navneeth Mandavilli is a senior technologist and innovator with experience ranging from hands-on development to the management of multi-national engineering teams building enterprise applications and system software. His most recent focus has been on helping others build development organizations that can successfully innovate, creating incubation teams that select projects based more on the promise of technology than proof. His approach has resulted in ground-breaking solutions, valuable acquisitions, and interesting failures.
Navneeth believes a successful career is rooted in two words: Know Thyself. He hopes that sharing his thoughts on what he learned about himself as he succeeded, and failed, in his career is helpful to the readers of this blog. He currently works in the Office of the CTO for EMC Corporation and is based in Santa Clara, California.
Follow Navneeth on Twitter @nmandavilli.