Advocate, educator, and authorial stance

19 July 2022

If you look at recent articles on this site, you might notice that I’m not writing very much these days. Instead, most of my energy is helping others with articles they publish here and elsewhere. I’m happy with this state of affairs, I’ve been getting increasingly distant from the day-to-day of software development, so my priority is to help those who are closer to the work share their ideas.

Often these ideas come in the form of describing a new technique or tool, perhaps not new in the general sense, but at least new to the author or the teams they’ve worked with. The reason the author wants to write about this technique is because they’ve found it worked really well, and believe that their readers can improve their software development experience by using it.

This naturally leads to many authors adopting an advocate stance. They’ll stress all the positive things they’ve gained from using the technique. In addition they’ll spend time detailing the problems of the alternatives, stressing why their preferred option is better.

I’m wary of this stance. I’m the kind of person who gets suspicious whenever someone advocates a simple solution to a complex problem. In these situations it's too easy to debate a straw man version of the alternative technique.

This leads me to a different stance to take as an author, one that I’ll call the trade-off stance. In this I assume that this promising technique has advantages compared with the alternatives, but also some weaknesses. My aim as an author is to ensure the reader takes into account all of these factors when deciding whether they want to use the technique themselves. Anything we write has lots of readers (we hope), who each have their own particular context. It’s up to them to evaluate whether a technique that worked well for us will transplant effectively to their context. By priming them with all the factors we know about, we increase the chances of them making a wise decision.

I see this as part of the difference between an advocate and an educator. The advocate wants the reader to agree with them, they succeed when the reader uses the technique that’s being advocated. I prefer the role of an educator, I succeed if the reader makes a well-informed decision, even if the reader chooses a different path to the one that I would choose in their situation. (This also means that if the reader does the exact same thing I would have done, but does it just because “Martin said so”, not understanding the trade-offs properly - then I’ve failed.)

Authors often make straw men of the alternatives in good faith because they have encountered them done poorly or in the wrong context. Such advocacy can often undermine its own position by not fully considering the advantages of the alternative technique. If a reader spots this, then they start to judge the article by the weakness of the arguments against the alternative, rather than focusing on the genuine capabilities of the new technique.

When writing with a trade-offs stance I like to start with the assumption that folks using a poor technique are doing so for sensible reasons, and my job as an author is to understand and explain those reasons. Even if the alternative is genuinely poor in most contexts, it's valuable to understand what leads people to adopt it. That empathy is a vital foundation to properly communicating the trade-offs that could lead the reader to a better technique.

A common reason to use a technique inappropriately is when it worked well at one time, but the context altered without the user fully understanding the change. The recent article series on bottlenecks of scaleups are an example of exploring this phenomenon. Many people use techniques that work well in early stages of a product, but these techniques break down as they scale. It’s tricky to navigate changes in context like this, particularly if you haven’t been through it before.

The trade-offs stance isn't the only way to take an educator’s role. Another stance, which I call the merits stance, is to explain the merits of the new technique without comparing it to alternatives at all. The advantage of the merits stance is that it avoids spending the author’s (and readers’) time and energy on going through a detailed set of trade-offs within the article itself. Instead the author concentrates on the characteristics of the new technique and leaves it to the reader to make the comparison based on their knowledge of the alternatives.

A good example of the merits stance is Kent Beck’s original book on Extreme Programming. He didn’t spend pages belaboring the downsides of waterfall processes, instead he presented Extreme Programming in a style that allowed the reader to see how it developed in response to the problems of team development. This allowed the book to be so wonderfully short and focused - which was a major reason why it was so influential.

The merits stance is much less comprehensive than a trade-offs stance, but that shouldn't deter writers from taking it. A well presented merits stance can play a vital role in kindling further discussion, which can explore more trade-offs and contexts. Such further discussion is more likely to be productive if the initial presentation is a clear exposition of the new technique. A critique of alternatives, even if well-done, usually muddies the waters.

A merits stance usually presents the new technique in a context that's well-suited for it. The author should explain that context clearly, so that the reader can judge any contextual differences to the reader's situation. While the article naturally focuses on the strengths of the technique, it should also describe any weaknesses and also any insight the author has to contra-indications for using it.

A merits stance places less demands on the author, who only needs expertise in the new technique, not in the alternatives. While we'd always prefer more expertise in our writers, I'd rather learn from someone who has a good understanding of some dimensions of a problem than wait for a Godot who understands them all. 1

1: For those unfamiliar with the play - Godot never comes.

Whenever I'm working with someone who's spending a lot of time explaining the problems of an established approach, I try to nudge them into the trade-offs or merits stances instead. Which direction to go depends on what author wants to produce, and what they are up for - but either is a step up from the advocate stance.


Acknowledgements

Rebecca Parsons and Sumeet Moghe gave some helpful feedback on my drafts

Footnotes

1: For those unfamiliar with the play - Godot never comes.

Significant Revisions

19 July 2022: published

16 June 2022: sent for internal review

09 June 2022: starting drafting