A Strategy for Code Reviews

I was coaching an organization the other day where they are trying to increase code quality. They believe they can accomplish this by increasing the frequency of code reviews. Currently, their solution is to get everyone into a room on a weekly basis, with junior developers demonstrating what they did and senior developers offering constructive feedback. If you've been reading my blog for a while now, you'll know that I usually find structured lengthy meetings as a wasteful activity. I'm not saying there isn't value in them. I'm just saying their cost is too much, relative to the value.

Weekly Code Review

Because the teams are trying to increase their delivery velocity, they are being forced to review their code delivery policies and rules. The weekly code reviews are creating too much of a delay. If a developer finished his or her feature on day one, they have a whole week to wait for the code review. If any changes are recommended, they lose an entire week because they still have to make the updates and get another review. The quality may be high but the velocity is low.

Pairing

My recommendation was the teams should begin pairing.  Upon review of their defined policies, it did not say they had to have a formal weekly code review meeting.  What it did say was no code would be merged into the trunk until another set of eyes had reviewed it.  By having a "code review" developer sit with the active developer, as he or she wrote code, it could be reviewed in real time and satisfy the policy.  The one week feedback loop would be shortened to an immediate feedback loop.

The Compromise

Paired programming can be a hard sell.  Management can find it hard to understand having two perfectly capable developers working on one piece of code.  But, if you look at the cost of waiting an entire week to get feedback and also having a group of developers stop work to attend a code review meeting, you can see there is a lot of wasted time and effort.  When I asked about this, I was told that the meeting was also an opportunity for developers to learn about other areas of the system.  My counterpoint was to rotate the pairs, to also offer a learning opportunity.

Because the teams would not agree to do formal pairing, but they certainly see the value in it, they decided to have a different (floating) code reviewer every day.  He or she will make themselves available the entire day to review code as needed.  I don't completely agree with this approach but it's certainly better then a weekly code review meeting.  They will be exposed to new areas of the system and the feedback loop will be shortened.  My hope is, in time, they will realize that having that second set of eyes sitting there full time will be the most efficient appraoch.

Image Quality by Pictofigo

Technical Debt

Technical debt and design debt are synonymous  metaphors referring to the eventual consequences of sloppy software architecture and rushed software development. Code debt refers to technical debt within a codebase. Ward Cunningham first drew the comparison between technical complexity and debt in a 1992 experience report:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

Ongoing development in the upstream project can increase the cost of "paying off the debt" in the future.  A team should take opportunities, on a regular basis, to pay back (or pay off) this debt.  Either reserve a percentage of your development cycle or dedicate an entire cycle to complete this work.  If you don't, it will come back to haunt you.  If your kludge of a solution doesn't come back to bite the development team, it will probably haunt the help desk, support team, or someone else downstream.

Just like regular debt, you're going to have to pay it back sooner or later.  As a former Manager of Software Engineering and now as an advisor to a customer, I've seen (and see) what technical debt can do to the velocity of a team.  It robs them of precious time, after the fact. The development team buys into the idea that doing things the wrong way, to save some time in the interim, is worth the risks and the overall cost.  This is a really short-sided thought process.  Technical debt is like getting a loan from loan shark who roles dice to decide what your interest rate is.  So, if you don't need to take the risk, don't do it.

Be honest with your customer, your team, and yourself.  Estimate your work and stand by your estimate.  Don't let someone else tell you how long it will take to deliver quality work.  If you have to, you'll just have to deliver less work.  That is, don't take on the debt in the first place.

[HT]: Wikipedia

Like the image? Find it at Pictofigo

Expert Judgment and Passing the Sniff Test

Looking for two very informative posts on estimating?  Check out one by Josh Nankivel of pmStudent and Glen Alleman of Herding Cats.  Both are discussing estimating techniques that work for them. I wanted to take a moment to add my two cents. Though I certainly believe estimating should be more science than art, I look at estimates from a different perspective. As a disclosure, I'm not the one doing the estimating on this project, therefore I'm not going to say I agree or disagree with any one technique.  Depending on your situation, one estimating technique may provide more accurate results than the other.

What I would like to add, from my perspective, is the need for expert judgment. If you are an expert in a given estimating technique and it gives you the results you and your customer(s) need, does that not validate it as an acceptable estimating choice?

If the estimating technique does not produce the desired results, wouldn't it fail the metaphorical sniff test?

Recently, I questioned a vendor's estimate based on a different technique.  I used a parametric estimate to see if the vendor's estimate would pass or fail my sniff test.

What exactly is a parametric estimate?

An estimating technique that uses a statistical relationship between historical data and other variables to calculate an estimate for activity parameters, such as scope, cost, budget, and duration.  Source: PMBOK Page 439

So, why did the vendor's estimate not pass my sniff test?  As part of a standard estimating practice, software vendors should include time for fixing bugs. Upon review of a recent status report, I noticed the vendor reporting half as many bugs were discovered in a current build than had been estimated. When asked about this, the vendor was very excited to confirm that they indeed found half as many defects in the code they originally estimated and predicted a cost savings of several hundred thousand dollars to the project.  Going into the current build, I knew what the standard deviation was and considered the possible variance.  This fell way below that.

So, why were they discovering so few bugs?  At first glance, I would predict two possible reasons.  [1] Quality through development improved.  [2] Quality through testing worsened.  Either way, you get the same initial result of fewer defects identified.

We'll know the true answer once initial user acceptance testing begins.  If there were no baselines to compare the actuals to, I might not have given it a second thought.

Graphic source via Flickr: pump

Listen to your Customer on her Birthday

In celebration of my wife's birthday, I figured I would make her a homemade birthday cake.  I haven't done that since before we got married 5+ years ago.  This time, however, I actually asked her what she wanted.  That's right.  The first birthday cake that I made for her, I didn't even ask what she would like.  If you were the customer, wouldn't that kind of tick you off?  Thanks for the cake but... I don't like that kind. Getting input (and listening) to your customer goes a long way.

Sure, I could have ordered a cake from the local (and now famous) Charm City Cakes but she didn't ask for that.  She wanted a chocolate cake with butter cream frosting.  So, last night, our 4-year-old son and I made her a chocolate cake with butter cream frosting.  We even cleaned up the mess after!  But, it wasn't completely uneventful.  All I can say is I'm glad there were well documented instructions.

Me: Are we a pair of knuckleheads or what? My son:  I think we're a pair of clowns, Daddy.

Here is my Project Management Spin

1. Find out what your customer wants.
2. Deliver what your customer wants, not what you want.
3. You'll spend more money if you want a chef to bake and decorate your cake.
4. You'll save more time if you want a chef to bake and decorate your cake.
5. Even a pair of clowns can bake and decorate a cake (if instructions are good).
6. You should expect lower quality from a pair of clowns.

Product Delivery

• Both cake and frosting passed unit testing. (Mmmmmm)
• We did a little beta testing last night before the final build.
• The final build was successful.
• We delivered on time.
• We delivered below budget.
• The good news is, I'm pretty sure we'll pass user acceptance testing.

Happy Birthday to my beautiful and wonderful wife!

Process Improvement and Grilling Steak

What's a weekend without grilling steak?  I would say a weekend without a good blog post idea.  Some things in life are an art and some a science.  It doesn't matter if it's project management/leadership or grilling a steak. So, what is a geeky way to write about grilling the perfect steak?  I would say compare it to the Deming cycle, or PDCA (Plan-Do-Check-Act) cycle to illustrate the point.  PDCA is a continuous quality improvement model consisting of a logical sequence of four repetitive steps for continuous improvement.

• Plan what you intend to do. In this step assess where you are, where you need to be, why it is important, and plan how to close the gap. Identify some potential solutions.
• Do try out or test the solutions.
• Check to see if the changes you tried had the effect you hoped for, and make sure that there are no negative consequences associated with them. Assess if you have accomplished your objective.
• Act on what you have learned. If you have accomplished your objective, put controls into place so the issue never happens again. If you have not accomplished your objective, go through the cycle again, starting with the Plan step.

PDCA applies to entrepreneurial ideas, application development, and anything that happens to do with my grill.  Realistically, you can apply it to anything where unknowns exist.  There are just so many variables, you need to be prepared to act and pivot.  I have grilled countless steaks and have refined my process to the point that it finally meets my quality standards.  On occasion, I do check to see if my process holds true and all I do is mess up a good steak.  I won't go into specifics as to what my perfect grilled steak process is.  (Unless someone asks)  Rather, I'll say I documented it and saved it in Evernote.

Now if only I could do the same with a hamburger.

How To Prevent Your Project From Hemorrhaging

This post is in response to a post written by Jennifer Bedell on the PMStudent blog about goldplating. Goldplating is very common in application development and can be very expensive. If you're dealing with Waterfall, it's a little more obvious when it's happening.  Some may argue, but I've seen it happen in Agile as well.  I've sat across the table from a vendor and asked, are you prepared to roll back every one of these changes?  Their eyes get big because why wouldn't the client want these changes?  Well, too many times a developer is in the code and they think, while here, why not make this additional change we planned to do next month.  Or, now that I'm here, it makes a lot more sense if I do it like this versus what we originally thought.

In short, Jennifer wrote about goldplating caused by testers. She asked

why is it always the developers who get blamed for goldplating? When you consider the cost of change increases as the project timeline progresses, it becomes evident that, in addition to increasing scope, goldplating by a developer can also be costly. Goldplating by a tester can occur when a tester goes beyond the stated requirements in an effort to produce a “quality” product. A tester may feel that their suggestion would improve the customer experience so they log this in the defect log.  While their suggestion may do exactly what they envisioned, if it was not within the scope of the stated requirements, it becomes a form of goldplating or “feature creep”.   A tester’s job is to ensure that a quality product is delivered, but many testers rely on their own definition of quality rather than using the requirements to define quality...

I’ve seen team members at every stage of the Software Development Life Cycle (SDLC) attempt to goldplate, with the best of intentions. Regardless of where you are in your development process, any time there is a requested change to the baseline, there should be a control mechanism.  I call that mechanism a triage. Be it the customer or a customer representative (Project Manager, Product Owner, or BA), someone needs to vet anything and everything which could impact the baseline.  These changes need to be prioritized and reviewed.  I'm not saying changes should not be made.  I'm saying they need to be properly vetted.  Changes impact the schedule, the budget, and in the end...customer satisfaction.

Without this control point, I think you’re guaranteed to see creep somewhere in your project and you will see it begin to bleed time, money, or both.

Yes, we certainly want to deliver the greatest value to the customer. But, creep increases risk and that’s not value.

Am I just a control freak or do you agree with me?

Free Total Project Status Report Template

TPS Report

As I study the collection and reporting of metrics and project statuses, I find many reports just do not deliver what they should. I believe there should be a stand-alone deliverable that a project manager is able to provide to a stakeholder at any time, illustrating the total project status.  I created a report and used the name "TPS Report" from the movie Office Space.  I try to interject a little humor into a project, where I can, without raising too many eyebrows.  Because I do not think I should keep all of the good stuff for myself, I hope others will download my free template.  It captures everything from overall project status to schedule, budget, scope, and quality, including a RAG (Red, Amber or Green) status.  What milestones were planned and accomplished?  What is planned for the next period?  Though I believe a subjective narrative does have its place in project reporting, I like the more objective approach.  Give your stakeholders the facts!Please enjoy this free copy of  my Total Project Status Report Template.

GQM: If you can not measure it, you can not improve it

In trying to determine what to measure in order to achieve the goals of a project, a Goal-Question-Metric (GQM) paradigm should be used.  It can actually be applied to all life-cycle products, processes, and resources.  The GQM paradigm is based on the theory that all measurement should be [1]goal-oriented i.e., there has to be some rationale and need for collecting measurements, rather than collecting for the sake of collecting. Each metric collected is stated in terms of the major goals of the project or program. [2] Questions are then derived from the goals and help to refine, articulate, and determine if the goals can be achieved. [3] The metrics or measurements that are collected are then used to answer the questions in a quantifiable manner.

Image based on Basili, Caldiera, and Rombach "The Goal Question Metric Approach", 1990

Here is an example of the GQM in action:

Goal 1 (use this 4-step process to shape a goal) [1] Purpose [2] Issue [3] Object (process) [4] Viewpoint

Goal 1 [1] Maintain [2] a maximum level of [3] customer satisfaction [4] from the Help Desk user’s viewpoint

Question 1 What is the current help desk ticket trend?

Metric 1, 2, 3, 4 Number of help desk tickets closed Number of new help desk tickets % tickets outside of the upper limit Subjective rating of satisfaction

As the great Lord Kelvin once said, "If you can not measure it, you can not improve it."