One day, the organs decided to hold a meeting to determine who should be boss.
The brain said, “I have the capacity for abstract thought, and I also control the autonomic processes of the body. Clearly, I should be boss.”
The heart said, “I pump the blood, taking oxygen to all the parts of the body. Brain, without oxygen you die before anyone else. Clearly, I should be boss.”
The stomach said, “Without me, none of you could function. I process food and convert it into the energy you all require. Heart, without energy you stop pumping. Brain, you consume energy even when the body sleeps. Clearly, I should be boss.”
The sphincter said nothing, and remained closed. After a couple of days, the brain had a headache, the blood was toxic, and the stomach was bloated. The brain, heart, and stomach unanimously declared the sphincter boss.
Although a useful, valuable, and high-quality software product requires the collective efforts of people who have a variety of skills, ultimately a software product is code. Without the user documentation, you could still have something usable. Without testing, you could still have something functional. Without analysis, you might be able to come up with something valuable. But without the code, there is no product at all, good, bad, or indifferent.
Maybe the primary stakeholder is the heart. Maybe the business analyst is the brain. Maybe the testers are the stomach. But ultimately the programmers are the sphincter. If the sphincter chooses to remain closed, the rest of the body will become progressively less comfortable.
Tempting as it may be from a Taylorist point of view, it isn’t really practical to pry the sphincter open by force. That would do more harm than good. If you don’t believe me, then just close your eyes and imagine someone prying your sphincter open by force. Did you enjoy it? Right, I didn’t think so. The only rational remedy is to feed the body whatever it needs to establish and maintain healthy flow.
What the sphincter needs…er, I mean, what programmers need…is an unambiguous definition of “done.” Based on that, they can determine what code to write and how to prove it is correct. Without it, they are doomed from the start.
The funny thing is that most programmers in most organizations would never dream of telling their colleagues that they will not proceed with coding until they get a clear definition of “done.” What they do instead is try their best to write whatever code seems to be wanted, and then deal with the inevitable game of bring me a rock until they can’t stand their jobs anymore. It’s a tragic and heartbreaking pattern, and it’s entirely unnecessary.
If you’re a programmer and you aren’t getting what you need from the other parts of the body, I suggest you just remain closed. According to French and Raven’s model of power bases, you lack the Legitimate Power to tell anyone what to do, by virtue of your position in the pecking order. You certainly don’t have any Reward Power or Coercive Power. You may have a degree of Expert Power based on your knowledge and experience, and maybe even Referent Power, depending on your interpersonal skills.
But your real power comes from the fact you are a sphincter. So, start acting like one. Don’t start on a work item until you understand exactly what “done” looks like. You might be surprised at the effect it will have on other participants in the development process.