As software developers, we all have clients.
At a consultancy, our clients are the company’s clients. Inside of a product or service company, our clients are the other departments of the company with which we must cooperate. In either situation, we want to have the buy-in of our clients so we can write clean code that works. But when clients are used to squeezing developers on deadlines and features, or when they’ve seen developers fail to deliver on promises in the past, that buy-in can be difficult to get.
Uncle Bob’s The Clean Coder explores the concept of professionalism—or, for the software consultant, “how to earn the trust and respect of your clients.” I don’t, in fact, recommend this book. Uncle Bob has proven time and time again to make misogynistic and classist assumptions about who gets to be a ‘software craftsman.’ This dude is not an exemplary professional, and he regularly attacks people on Twitter for promoting inclusion in tech.
I did find a few poignant lessons in this book, and I put them here so you don’t have to buy this book or accidentally happen across any of the deeply misogynistic and classist examples he uses in it.
1. “Professionalism” is not tantamount to “acquiescence to whomever fancies themselves your boss.” (Chapter 2: Saying No)
It seems cliché to say that professionals stick to their commitments, but clients often come to us with stories and fears of missed deadlines and poor code shipments. Does this happen because all the other developers have drastically misestimated the workload, or messed up the code? No. The problem, Uncle Bob points out, often arises when clients make commitments for the development team and the development team accepts those commitments. He points out that it is a client’s job to defend his or her interests: to get all of the features he or she wants, and to get them as early as possible. Likewise, it is the developers’ job to defend his or her interests: to do the features that serve the clients’ needs in a way that makes the code maintainable over the long term. The developers’ interests, in fact, serve the client, but they limit the scope of what can be delivered in a given amount of time.
This can frustrate the client. It can force them to renege on promises they’ve made to their bosses or their customers. But, Bob argues, it is the role of a professional developer to remain firm if, say, the client asks to see ten weeks’ worth of work in six weeks. The options are to move the deadline further out, or to limit the scope of the code to be delivered in six weeks. It is neither sustainable nor wise, for either the developer or the code, to “try” to meet the deadline. “Trying” implies expending extra effort that would not have otherwise been expended—and in so doing, it implies that a developer does not already expend the appropriate amount of effort. Instead, we should offer clear estimates of the scope we can complete, and how long it might take. Then, when we make commitments, we stick to them.
2. Estimation is not the same as commitment. (Chapter 10: Estimation)
When we estimate the amount of time that a given scope of work might take, we usually estimate the amount of time it is most likely to take. Then the client assumes that that is the amount of time it will take and imagines that to be the deadline for the scope. The problem with this is that the amount of time it is most likely to take is in the middle of a bell curve representing the amount of time it could take—so anything toward the tail end of that looks to the client like lateness.
Uncle Bob recommends an interesting method of communicating this uncertainty to clients—trivariate estimation, adopted from American naval planning and estimation schemes. For this type of estimation, a developer comes up with three estimates instead of just one: an optimistic one (O), a “most likely” one (N), and a pessimistic one (P). Then, we can use those estimates to describe to clients what to expect within a given bracket of uncertainty.
- expected duration of the task = (O + 4N + P)/6
First, we get the expected duration. In the proposed formula, the “most likely” estimate gets the most weight. That said, the resulting estimate usually falls a little higher than the most likely estimate, purely because the pessimistic estimate is usually farther away from the most likely estimate than the optimistic one is.
- standard deviation = (P-O)/6
The standard deviation takes the total range of times it might take and describes just how uncertain we are about our estimates. If P and O are further apart, it’s bigger.*
*For those interested in the actual statistics: the standard deviation describes a normal distribution of outcomes—that is, a very specific shape of bell curve. It predicts that there’s a 68% chance of your actual time to completion falling within one standard deviation of your expected duration and a 95% chance of your actual time to completion falling within two standard deviations of your expected duration. So if your expected duration is 6 days and your standard deviation is 2 days, then it predicts the following completion times:
- 2-4 days: 13% probability
- 4-6 days: 34% probability
- 6-8 days: 34% probability
- 8-10 days: 13% probability
Estimating an epic (or a list of several tasks) at once for a client:
- For a set of tasks, the estimated sum time to complete is the sum of the estimates of time to complete.
- The sum’s standard deviation is the square root of the sum of the squares of the standard deviations of the component tasks.
The above makes a lot of sense to me. I do have a question, though: how can/should/might we go about convincing our clients to work this way?
It seems like it might make our workflow harder to sell to clients—not because it’s bad, but because clients get used to pushing for (and only buying once they receive) a commitment to a given amount of work in a given period of time.
In order to sell work, companies might acquiesce to commitments to the client without consulting the developers responsible for fulfilling those commitments. In this scenario, Bob explains that we should do all we can to help a company meet its commitments, but we should not accept them. That way, worst case scenario, we can keep our heads held high as we hunt for a new job.
That makes professionalism and job security sound like a zero sum game, unless a developer is his or her own boss.
Is it possible to maintain this standard of professionalism while working as an employee? Perhaps for a consultant this is possible, but it’s telling that Uncle Bob specifically mentions being fired as a potential consequence of maintaining these values. That doesn’t mean they’re bad. If employees must fear being fired over refusing to acquiesce to achieving more than is reasonable because their bosses committed them to it, then we’re clearly dealing with a broken system. Can we fix it? How could we fix it? Is it a matter of selling clients what they want, then backing off those commitments and giving them what they need? Is that false advertising? Must we then lie until we reach a critical mass of satisfied clients so we can then rely on referrals?
What isn’t being surfaced here? It’s the degree to which companies meet their commitments. If we’re known for meeting ours and other companies are known for going way over deadline and over budget, then clients will trust us more. But those numbers don’t get surfaced, do they? And bringing them up in a sales meeting would be like politicians who stake their campaigns on throwing their opponents under the bus. That’s not professional, either. I’m not saying I have the answers, here. This is a true conundrum.
That said, onward.
3. When under pressure, stick to the practices that you have found to be helpful for use all the time. (Chapter 11: Pressure)
That is, if you think pairing is the most effective way to code, pair in a crisis. If you think TDD is the most effective way to code, use TDD in a crisis. Or, said differently, find those practices to which you resort in a crisis, and use them all the time. They’re clearly the most effective for you, since that’s where you turn when things go sour. We often change our behavior from low pressure to high pressure situations. Uncle Bob argues that we do better to keep it consistent.
So, I used to be a coxswain. For the first five years, I would frequently try to break out new moves and techniques during races that I had never tried in practice before. I thought the creative mojo would help us win…or something. I guess.
In the sixth year, I started to back off of that. By the eighth year, I had learned to test lots of new, crazy ideas in practice every day—and on race day, only use the ones that I had perfected, and the ones that I knew worked.
We won a lot more races that way. Also, I felt a lot less stressed out—which allowed me to focus on doing all the parts of my job to the best of my ability.
So, although it’s from a different life experience, I can vouch for what Bob is saying here.
4. A team takes a long time to gel (6-12 months), but when you have a gelled team, it works miracles. (Chapter 13: Teams and Projects)
Rather than structure teams around projects, Uncle Bob recommends first forming a cohesive team. Once that is done, you can throw a number of projects at it—even at once—and it can do amazing things.
I see how this works in theory. I’ve been a part of friend groups and teams that found their stride and became seemingly unstoppable.
But I wonder: how do you get that team to gel? Is it a matter of finding the right people? Is it a matter of teaching those people skills, or uniting them under a common set of values? Is it a matter of just letting them get to know each other? What kinds of personalities make such a team—or break it? Can anyone be part of such a team—and if so, are they born, or is it a learnable skill set? And how to we teach it? And how much time do we give a team to gel, if it’s possible that no amount of time will get just any group of people to gel? When will we know we have messed up?
Sometimes, we end up with a dream team, and it’s fantastic. But on the occasions when I’ve seen that happen, the team’s formation was mostly…well, luck. And luck isn’t very reliable. I’d love to know how we can improve the chances of this happening.
5. “It seems to me that companies who hire [junior developers] ought to invest more in their training than McDonald’s invests in their servers[‘ training].” (Chapter 14: Mentorship, Apprenticeship, and Craftsmanship).
One day, I will tell you a story about mentorship. That day is not today. Suffice it to say, though, that:
a) yes, there is a giant lack of mentorship in the software community,
b) yes, every company has some reason why it in particular can’t mentor junior developers, but other companies should*
*and, IMHO, any company that complains about this abdicates its privilege to complain about the scarcity of decent senior developers, as it is clearly a part of the reason for that scarcity. But I’ll get off my soapbox so we can move on.
c) mentorship can come from self-driven learning with the help of resources created by other people at some other time and place, without 1 on 1 supervision. Uncle Bob did this with a small, $1 manual for a computer toy his mother bought him when he was 12 years old. The manual, which he still keeps on a shelf, explained boolean logic in a way that a 12 year old could understand, and in so doing empowered him to write his first program.*
*That was the program that gave 12 year old Bob the jolt—that very first moment that a nascent computer programmer gets a program to work. For him, like for many programmers, the jolt changed his life. The $1 manual does not list the names of its authors. Imagine that: somewhere out there, an anonymous author who worked for a toy-making company launched the career of Uncle Bob Martin, y’all, and that person is completely unaware of it.
But back to mentorship and training: companies and schools of all kinds have made an attempt to come up with a viable training scheme for developers. I’m interested to know if any company has found such a program to be particularly effective. Uncle Bob recommends in the book a program that bears some resemblance to the apprentice/residency scheme from medical education. It sounds like it would have a high return on investment, but it also sounds like a high investment. For that reason, I imagine companies might need a precedent of high returns on such an investment in order to make it themselves. The closest thing I’ve heard of is The Ada Academy, which follows 6 months of study with a 6 month internship at a company. That program just finished its first cohort this past year, so perhaps it would be worth watching its graduates for these returns. If you know of a program that you’ve seen work, I’d be fascinated to hear about it.