Accountability
in Software Development
Kent Beck,
Once, a farmer interviewed a young man for a job as a farm hand. One thing the young man said particularly puzzled the farmer, “I can sleep when the wind blows.” The farmer didn’t know what this meant, but the young man seemed competent and knowledgeable and so he was hired.
A few months later the farmer was awakened in the middle of the night by a thunderous wind storm. Panicked, he raced to the cot where he found the farm hand fast asleep. Shaking him roughly awake, he demanded, “We have to bring in the animals!”
“They are already in.”
“We need to fasten the windows.”
“They are already fastened.”
“We need to tarp the hay.”
“It’s done.”
After going down his list of worries and being reassured that they were already taken care of, the farmer finally realized the meaning of the young man’s puzzling statement. By taking care to finish every job and leave the farm safe every night, the farm hand could sleep when the wind blew.
The farmer went back to bed and told his wife what he had just learned. She just smiled knowingly and the two of them went back to sleep, lulled by the music of the storm.
Software development goes better when I work so I can “sleep when the wind blows”. I am more comfortable with myself and my work, my customers are more satisfied with the results they see, and my teammates can trust me. However, I find it difficult to achieve this level of performance on willpower alone. I need support, encouragement, and accountability. I need to be a member of a community to do my best. A key to performing well is accountability: making commitments, working in ways I am proud of, and rendering account of my activities clearly and directly.
When I first started talking about accountability, I met a lot of resistance from programmers who said they hated the idea of accountability. They told stories that sounded like this, “… and then he says, ‘I’m holding you accountable for this schedule slip.’” This not what I am talking about. This is blame, the attempt to avoid or deflect consequences. Blame is a poor premise from which to work. Blame requires that you spend time and energy protecting yourself. In an environment of blame it is not safe to say what you do and don’t know. Blame leaves everyone worried about who is out to get them. All the energy they spend hiding could be spent interacting and adding value to the project. Work gets done much less efficiently. Accountability is a powerful premise from which to work. Working well and visibly builds strong relationships. Accepting responsibility sets the stage for satisfaction in a job well done. It’s a pity that the word “accountability” is misused, because the misuse obscures a useful concept.
Accountability can be offered, asked, even demanded, but it cannot be forced. “I hold you accountable,” doesn’t make sense. “I blame you,” or, “I hope you will accept the consequences,” at least make sense, even if they are a poor basis for a working relationship. Managers can request or demand accountability. For example, a manager could ask that the software be ready to deploy at the end of every week so that the team’s progress is visible. From the other side, accountability can be offered even if it isn’t requested. “I can show you a log of how I spent my time last week,” is an offer of accountability.
I offer accountability to demonstrate my trustworthiness and encourage myself to behave my best. For example, when I am accountable to my spouse for finances, we discuss how to spend money. We agree on goals and principles for our finances. I render account to her of how I actually spend money. If I waste ten dollars buying something useless, I just say so and listen to her response. Having those preliminary discussions and knowing I am going to render account helps me spend money wisely and builds our relationship
Similarly, while programming I offer accountability as a way of demonstrating my trustworthiness and encouraging my own best behavior. Pair programming; test-first programming; continuous integration; visible daily, weekly, and quarterly cycles; slack; and estimation are some of the way I make public commitments and render account of my activities. Knowing I will be honest and accountable affects how I do my work, just as knowing that I am hiding and concealing negatively affects how I do my work. Taking responsibility for my choices and actions deflects blame. There is no hidden shame if everything I do is above board.
When I program with a partner, I make my thinking visible to them and I listen to their thinking. If I am muddled, I say so. If I don’t like our design, I say so. We are free to ask for clarification or ideas from others. If we can come up with nothing better, we go ahead doing the best we can. There is nothing hidden about this process, no blame, no shame.
Test-first programming is a form of accountability, especially when practiced in its pure form where no application code is written without a failing test. The tests are an account of my thoughts as I program. They record the problems I considered. If a problem isn’t represented by a test, it is safe to assume that I didn’t consider that as I was programming.
Continuous integration renders account to the team every hour or so of what I have been doing to the system. Pausing in my work to make sure the tests all run adds to the accountability, ensuring that if I created a problem in the system I will fix it before proceeding.
Visible planning cycles provide an opportunity to make public commitments and, at the end of the cycle, render account for those commitments. I am much less likely to waste time, to not ask for needed help, to move forward with shaky information if I know I am going to render account at the end of the day or the week. “I spent three days not fixing defect 142 because I was too afraid to ask for help,” is embarrassing enough that I’d rather ask for help.
Making estimates is part of making commitments. Without estimates I don’t know how much to commit to doing. Without some slack in my schedule, however, I also know that I regularly won’t meet those commitments. Making and meeting commitments is an important part of building strong relationships during development, relationships that will sustain the team during difficult times.
Sometimes I am afraid of the consequences of offering accountability (“if they only knew how long fixing that defect took they’d think I was an idiot”) I do better the more accountable I am. If I am an idiot we’re all better off acknowledging that fact and acting on it rather than trying to pretend it isn’t true. If I have done the best I can do, I don’t have anything to fear from the judgments of others. If I say with confidence that a job will take four months, then when someone tells me they would really like it in two months I can listen to what they are really saying. I can respect their position without necessarily agreeing with it. I can listen for needs, not just for words or tone. I can look for mutually beneficial ways of getting those needs met. If I am confident in my estimates and my work, then I can “sleep when the wind blows”.
When I look at the shifts in global IT employment I see a shift of jobs towards teams and organizations that offer accountability. CMMi level 5 has many pros and cons, but one thing it definitely offers is visibility. Teams at that level say what they are going to do and report what they really do. Then they reflect on that experience to improve.
Accountability isn’t simply a matter of reporting facts. If I know that I created 40 defects this week and accurately report that, I have been honest but not responsible. I have not completed my work in a way I can comfortably live with. I am not behaving in a way that builds relationships, relationships necessary for good software development. Extreme Programming is my way of working. Its principles and practices contribute to my ability to be accountable while developing. Accountability encourages me to do my best work. I resist the urge to take shortcuts or leave ugly code when I know others will see it and care.
Accountability is important at many different levels. Being accountable to myself, even if it is just making and reviewing daily to-do lists, helps me focus my efforts and take satisfaction from my accomplishments. Inside a team, accountability encourages trust to form, trust that frees energy to be used accomplishing shared goals instead of protecting individual turf. Teams offering accountability to their customers and their organization also build trust. When an accountable teams says “six months”, others can trust that information and act on it, confident that the team is acting in our mutual interest. Some development organizations have even gone so far as to make their internal quality metrics publicly accessible, offering accountability to the world at large to demonstrate their trustworthiness, communicate their belief in what they are doing, and encourage their own best efforts.
My experience is that the further my accountability goes, the more openly and directly I express my commitments and report my activities, the more empathically I listen to others, the better the results I see. The more accountable I am, the more creative I am, the more work I accomplish, the more value I create, the faster I learn, the more I can “sleep when the wind blows”.