In a previous post I wrote about the uncompromising artistry of Stanley Kubrick, who produced film classics at the cost of wildly unpredictable schedules and budgets. You can reach for similar brilliance in programming, but you had better do it on your own time or with a generous CFO. There is a different, more workable, and healthier attitude towards our craft. Just keep at it, enjoy it, and don’t worry about making a dent in the universe. Reading Woody Allen’s autobiography over the holidays, indulge me to draw another cinematic parallel with this veteran New York writer/director. Don’t worry, it will also be about coding.
Woody Allen (1935) is one of the most consistently prolific cinematographers in the business. He has written and directed over fifty films over an equal number of years, almost like clockwork and at 85 shows no intention of stopping. He doesn’t approach his oeuvre as a project with a culmination. His business is about keeping busy. He is in it for the long run, if only to act as an antidote to the unavoidable spectre of death and oblivion. But let’s not get into his glum outlook on life here.
Today I want to talk about the widespread Scrum practice of demoing new user-facing features to key stakeholders after every Sprint. I consider it a dubious practice because it can prevent and degrade a culture of quality. Neither the Scrum guide nor common sense demands that you should strive to hold such a demo at regular intervals. The Agile 2 movement understands that turning teams into feature factories kills quiet reflection, adaptation and true agility.
There’s a lot that people think the Scrum guide dictates which is in fact not in it. There are no story points, no poker planning sessions, and no Fibonacci ranges. Like religions accrue articles of faith that are in no holy book, so Scrum has given rise to received practices based on wrong assumptions. One belief is that you must hold a demo at the end of the Sprint. There is no such mandatory demo. There is a review, during which you inspect the outcome of the Sprint and determine future adaptations. [..] The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation. There you have it, straight from the horse’s mouth.
Let’s talk about artistry, craftsmanship and software quality. Writing code has been compared to an art as well as a craft. I love discussing the difference between the two and their relationship to quality. Software quality is a multi-faceted beast (functional correctness, usability, maintainability and all the other ilities). It’s impossible to judge the quality of a program by only looking at its source code, but it’s easy to recognise a clear lack of quality from any illegible tangle of spaghetti. Tools for quality metrics can point to such potential trouble but won’t guarantee that you’re building the right thing.
Anyway, if you take pride in your work, you don’t need tools to keep you on the straight and narrow. A true craftswoman always does the best she can. There is no such thing as too much quality, is there? Perhaps talk to the person who’s putting up the money. Quality saves money later, but it will cost you right now. From a business perspective the product needs to make money long enough to justify that expense. From an artistic perspective none of that matters. The true artist pursues quality for its own sake. Allow me a little segue into film and music.
Earlier this year I wrote an outspoken post following the online protests when the young author Marieke Lucas Rijneveld was commissioned to translate Amanda Gorman’s poem The Hill We Climb into Dutch. Rather than pointing out their non-existing experience as a literary translator, the protest centered around their clear lack of epidermal pigmentation. The job should have been given to a person of color. Rijneveld returned the assignment with the usual undignified and probably disingenuous apologies for having wounded certain sensitivities. I side with Ricky Gervais on this one: just because you’re offended doesn’t mean you’re right.
You may think this is the typical stance of a white Gen-X male, university educated and raised in an affluent, traditional rural Dutch milieu. And you would be spot on. My background colors everything I do and opine, including the previous paragraph, the next ones and everything I have written and will write on this blog. I could not be neutral if I wanted to.
All software teams I have worked in over the last ten years practiced some sort of Agile, sometimes effectively, sometimes in-name-only. I discovered a lot about the value of teamwork and leadership and I increasingly side with the Agile2 movement that the original ideas expressed in the Agile manifesto on these topics are routinely misinterpreted and misapplied. Software teams are not like sports teams. Not a bit.