You Are Not Your Code

The last thing I would ever suggest would be holding more meaningless meetings … the problem is not meetings, per se, rather the challenge is ensuring they are meaningful.

Once you learn to accept the fact that you are a fallible human being you will not get into a defensive crouch whenever somebody criticizes your work product (whatever it is).  Generally, your life is improved with the growth of any virtue – in this case, humility.  The big win is that your willing cooperation will help you become a better programmer/developer.

It is popularly – and incorrectly – believed that programmers have to be introverts.  An extroverted programmer is somebody who looks at your shoes when talking with you.  But programming, software development or engineering, is a people business .  Somebody who has trouble communicating with customers or other team members – is a liability – no matter how fast they can sling code.  In fact, they may be more of a liability the faster they sling code.

Recently, we were cleaning up some code that had been written by a former team mate and discovered that they had imported a bunch of complexity into a project to solve a fairly simple problem.  Two problems there … first, it indicated a massive failure of our code inspection process which we immediately moved to fix (that won’t happen again) … second,  the programmer was running open loop and had failed to consider what would happen if they weren’t the one maintaining the code.  Clearly, this could have been prevented by doing code reviews/inspections.

Not every organization is ready to implement inspections (a/k/a peer reviews).  A certain amount of preparation is needed.  Here is an inspection readiness framework to see if your team is ready. 

People

  • Champion
  • Management/leadership commitment
    • No commitment = lack of involvement, motivation
    • Do not proceed without upper level management commitment
  • Team member understanding
    • You are not your code – egoless programming
    • Personal commitment to quality above “being right”

Process

  • Policy structures
    • Review the code, not the person
    • Results not used for personnel measurement (may be used to direct remediation)
  • Training
    • Effective meetings (please!)
    • Inspection process

Technology

  • Tools – issue tracking, etc.
  • Measurement/metrics – defect rates/types
  • #1 Challenge / thing to overcome
    • Convincing management that a quality process – especially one that appears to be manpower-intensive – is crucial to the success of the product and, ultimately, the company.  Inspections, in particular, have a proven track record in the industry.
    • A decision of how much effort to spend on inspections comes from evaluating the risk-reward trade-off … time-to-market vs quality.  Note that even early adopters are unlikely to appreciate a product that produces wrong results or crashes often.

To review:

  • Inspections help us improve as programmers/developers
  • Even introverts can benefit from attending review meetings
  • We discovered – too late – that our inspection process failed and it caused rework reducing unneeded complexity introduced to a project by a now-departed programmer

Inspection readiness boils down to people – process – technology … each are important and the approach needs to be balanced

Convincing management to make a commitment to inspections will be the most significant challenge to overcome in getting an inspection process stood up.