A well-known authority in the world of software development, “Uncle Bob” Martin, has come out with a new book, The Clean Coder. Filled with anecdotes and lessons on professionalism and discipline in software development, the book is the type managers and decision makers might easily be enticed to read cover-to-cover. In this exclusive interview, we’ll explore some of Martin’s recommendations and find out more about his thoughts on some of the more controversial topics of software development.
SSQ: In the chapter on saying ‘No,’ you write that developers should be more assertive about speaking up when they’re given an aggressive deadline by management. You recommend saying ‘No’ rather than ‘I’ll try.’ However, most people have trouble going against the demands of their management for fear that they will get on the manager’s bad side (or even fired.) Do you have any advice for these people?
Bob Martin: The question here is whether to lie or to tell the truth. “I’ll try” is a lie of the most insidious form because it’s also the truth. If you say you’ll try, you will, of course, try. However, it is very unlikely that any part of your behavior will change just because you said you’d try. You will do precisely what you would have done before you said you’d try. So the words suggest that something different will happen. And that’s the lie.
Why do we tell this lie? We tell it to end the discussion. The discussion is uncomfortable and we want it
Business is not easy; it’s hard. Business is full of risks and tough decisions. Managers need help with those decisions. The only thing that can help managers make good decisions is the truth. So when a manager confronts you with an impossible deadline, you have to tell that manager the truth. If you don’t believe you can meet that deadline, you have to say so in no uncertain terms.
It’s true that this might put you on the “bad side” of that manager. It’s true that telling the truth might be uncomfortable, or make you look bad. Welcome to business. Business is hard. Business is full of risks. Nobody gets a free pass. There are no guarantees.So you do what you must to help drive the business in the best possible direction.You tell the truth and absorb the risks because, in the long term, the risks of lying are much, much higher.
SSQ: You talk about the importance of test-driven development and how the goal of development is that nothing would be found in test. With such improvements do you see a day when manual testers will no longer be needed?
Martin: No, but I see their job changing a great deal. Any tests that can be scripted should be automated. We don’t need humans doing something that a machine can do. What we do want the human testers doing is exploratory testing. Exploratory testing is a creative endeavor in which human testers explore the behavior of the system in an attempt to characterize its behaviors; both documented and undocumented.
SSQ: You talk about the automation pyramid and say the development team uses TDD, acceptance tests and regression tests through continuous integration. Then you say, “But these are only part of the story. As good as it is, we also need, higher-level tests to ensure that QA finds nothing.” Do you see QA taking part in automation efforts? If so, what automation skills do you think would be most beneficial for testers?
Martin: I certainly see QA taking part in the automation effort; but in an entirely different role. QA should be the authors of the automated acceptance tests. Those tests will become the true requirements document. So QA moves from a verification role to a specification role. It is their job to interpret the business requirements and precisely specify the behaviors of the system.
SSQ: On the topic of estimates, you seem to advise erring on the side of giving later estimates rather than early estimates which may lead to cutting corners. However, in my experience, some developers are overly aggressive when giving estimates and others are overly cautious. How can managers make sure developers aren’t adding too much buffer time to their estimates?
Martin: You don’t need to buffer estimates. You need to buffer commitments. If managers ask
for estimates, then developers should provide their best guess and a measure of uncertainty.
For example, a developer might estimate a task at 10 days, with a 90% uncertainty of two days. No
commitment is implied by such an estimate. The task might take 10 days, it might take 12, it might
even take 14. The point is to give the manager a reasonable measure of the uncertainty.
When managers ask for certainty, then of course developers will add buffer time. How could it be otherwise? A commitment is something you must meet; therefore you have to remove all the uncertainty. The only way to do that is to add a buffer. If I were asked for a hard commitment for the previous task, I’d have to add four or five days of buffer just to be sure I did not miss my commitment.
So, the direct answer to your question is that managers should expect buffers if they ask for commitments. If they ask for estimates, then they should expect uncertainty. Those are the only two options. Read the second part of this interview.
This Q&A is based on the book, The Clean Coder: A Code of Conduct for Professional Programmersby Bob Martin, published by Pearson/Prentice Hall Professional, ISBN 0137081073, Copyright 2011 Pearson Education, Inc. For more info please visit: www.informit.com/title/0137081073