Clean Coder, The: A Code of Conduct for Professional Programmers (Robert C. Martin Series)

by Robert C. Martin

It should be QA’s role to work with business to create the automated acceptance tests that become the true specification and requirements document for the system.

The other role for QA is to use the discipline of exploratory testing1 to characterize the true behavior of the running system and report that behavior back to development and business.

Professionals are aware of the high cost of meetings. They are also aware that their own time is precious; they have code to write and schedules to meet. Therefore, they actively resist attending meetings that don’t have an immediate and significant benefit.

You do not have to attend every meeting to which you are invited. Indeed, it is unprofessional to go to too many meetings.

One of the most important duties of your manager is to keep you out of meetings. A good manager will be more than willing to defend your decision to decline attendance because that manager is just as concerned about your time as you are.

When the meeting gets boring, leave.

My rule of thumb is that the meeting should take no more than 5% of the total time in the iteration. So for a one week iteration (forty hours) the meeting should be over within two hours.

“Any argument that can’t be settled in five minutes can’t be settled by arguing.”

This is called priority inversion. You raise the priority of a task so that you can postpone the task that has the true priority.

The Rule of Holes: When you are in one, stop digging.

Business likes to view estimates as commitments. Developers like to view estimates as guesses.

Commitment is about certainty.

An estimate is a guess. No commitment is implied. No promise is made.

When you estimate a task, you provide three numbers. This is called trivariate analysis: • O: Optimistic Estimate. This number is wildly optimistic. You could only get the task done this quickly if absolutely everything went right. Indeed, in order for the math to work this number should have much less than a 1% chance of occurrence.2 In Peter’s case, this would be 1 day, as shown in Figure 10-1. • N: Nominal Estimate. This is the estimate with the greatest chance of success. If you were to draw a bar chart, it would be the highest bar, as shown in Figure 10-1. It is 3 days. • P: Pessimistic Estimate. Once again this is wildly pessimistic. It should include everything except hurricanes, nuclear war, stray black holes, and other catastrophes. Again, the math only works if this number has much less than a 1% chance of success. In Peter’s case this number is off the chart on the right. So 12 days.

Given these three estimates, we can describe the probability distribution as follows: • μ is the expected duration of the task.

σ is the standard deviation4 of the probability distribution for the task. It is a measure of how uncertain the task is.

The strategy is simple. A team of people assemble, discuss a task, estimate the task, and iterate the discussion and estimation until they reach agreement.

Law of Large Numbers.8 An implication of this law is that if you break up a large task into many smaller tasks and estimate them independently, the sum of the estimates of the small tasks will be more accurate than a single estimate of the larger task.

Sometimes we find that our business has made promises to the customers without consulting us. When this happens we are honor bound to help the business find a way to meet those commitments. However, we are not honor bound to accept the commitments.

I prefer teams in which any team member can check out any module and make any changes they think are appropriate. I want the team to own the code, not the individuals.

Professionals also pair because it is the best way to share knowledge with each other. Professionals don’t create knowledge silos. Rather, they learn the different parts of the system and business by pairing with each other.

Professionals pair because it is the best way to review code.

It take time for a team to form. The team members start to form relationships. They learn how to collaborate with each other. They learn each other’s quirks, strengths, and weaknesses. Eventually the team begins to gel.

The analysts develop the requirements and write automated acceptance tests for them. The testers also write automated acceptance tests. The difference between the two is perspective. Both are writing requirements. But analysts focus on business value; testers focus on correctness. Analysts write the happy path cases; testers worry about what might go wrong, and write the failure and boundary cases.

The business should not have its hands tied by the artificial difficulty of forming and disbanding teams.

A craftsman is someone who works quickly, but without rushing, who provides reasonable estimates and meets commitments. A craftsman knows when to say no, but tries hard to say yes. A craftsman is a professional.

The craftsmanship meme is handed from one person to another. It is taught by elders to the young. It is exchanged between peers. It is observed and relearned, as elders observe the young.

The acceptance of a meme is not so much a rational decision as an emotional one. This is a very human thing.

So you make the meme observable. You act as a role model. You become a craftsman first, and let your craftsmanship show. Then just let the meme do the rest of the work.