Do stakeholders ever need even to hear the word “refactoring”? At all? Can’t we just consider it “part of the job of building software”? If we seek permission to refactor, then shouldn’t we also seek permission to use “if” statements? How extreme a view is this?

In a world in which programmers have never in the history of history let stakeholders down, no stakeholder would ever feel the need to inquire about the details of the programmers’ work. A programmer could easily brush such an inquiry aside as irrelevant, even cheeky. Sadly, we do not live in that world. At least, I don’t.

Stakeholders don’t trust programmers in part because programmers have trained stakeholders to expect substandard, low-quality work delivered late and with a fight at every turn. Or so it seems to me. On the other hand, programmers don’t trust stakeholders in part because stakeholders have trained programmers to expect far too many unrealistic demands, delivered harshly, under threat of some kind of enforcement including, but not limited to, being fired. It feels like a terribly unequal relationship.

Even if we ignore all this, programmers’ work looks mysterious to stakeholders. They literally cannot—in many cases—understand what the programmers do. Moreover, the programmers can’t point to a physical object and say, “There is my work.” The intangible nature of the work makes it harder for the average person to contemplate and the (generally) complicated nature of the work makes it tedious to inspect for problems. If I didn’t understand programming, then I’d feel really worried about the imbalance: once we agree to start a project and I invest my money, the programmer holds all the leverage. I can only hope for the best.

It reminds me a lot of working with building contractors. I can inspect their work, but for much of it, I simply have to trust that the contractor is making decisions in our mutual best interest. I can notice when things slow down or go wrong, but I have a hard time arguing with their justifications. At some point, I have to trust them and hope for the best, and that frightens me when I decide to invest two years’ household profit into a single project!

This imbalance demands our attention. If it stays as is, it will blow up in our collective faces. Accordingly, I can think of options along the continuum of transparency.

  1. Increase transparency in order to improve trust.
  2. Decrease transparency in order to protect ourselves from scrutiny and rely on our leverage to enforce the situation.

I prefer to increase transparency, but I have felt the need to protect myself by decreasing it, and I expect to feel that need at least one more time in my life.

I don’t mind stakeholders asking me questions to gain insight into how I work and what it costs them. I don’t mind stakeholders asking me to “please control costs carefully; I have less cash than usual.” These things sound perfectly reasonable to me, and I hope that my stakeholders generally feel comfortable enough with me to open up a little and share more about their constraints. This helps me make decisions in our mutual best interests.

On the other hand, I do mind stakeholders trying to direct the techniques I use. In particular, when stakeholders suggest a change to my work that they believe reduces cost, but actually increases cost (perhaps over a different time horizon), then we have a problem. Even if we ignore the matter of respect, when stakeholders direct work this way, they lead to a classic responsibility imbalance of the type you can read about in detail in The Responsibility Virus. It simply doesn’t help.

That said, when stakeholders are desperate about cash, then I can understand their concern.

So… we’re here. Some stakeholders believe that they have the right to direct programmers on the techniques they use, and some programmers—say those with not enough money slack don’t have the leverage to refuse the demand. Where do we go? Eventually we end up either with very low or very high trust. What else would work?

Of course, there are other ways to build trust, such as delivering consistent results. I’m only trying to justify the choice of entertaining the debate with your stakeholders over whether to refactor. We could eliminate this debate by explaining how refactoring benefits the stakeholder and that programmers don’t refactor merely to satisfy some vague notion of elegance or perfectionism or, Universe help me, “professionalism”. Honestly.

References

J. B. Rainsberger, “The Eternal Struggle Between Business and Programmers”. Why do we debate refactoring when it’s clearly in our mutual best interests?!

Roger Martin, The Responsibility Virus. Every so often I come across a model that so perfectly crystallizes an idea in my head. Martin’s “over-responsibility/under-responsibility” model did that instantly for me.