There is a consistent thread in my career, other than not having been fired from a project since 2001. It is the repeated failure to carry an Open-Source project that deserves to be called more than an amateur attempt. I throw in the towel. I’m not going to breathe new life into my Hibernate-killing polyglot ORM framework for the JVM. And if I do, I won’t share it with the world. I have given up and given in, and I know exactly why it happened – or rather didn’t happen.
We’ve all heard and probably repeat the claim that any serious developer should boast an impressive portfolio of Open-Source work. I’m not talking about being a core contributor to the likes of Spring or the Apache foundation. If that were a prerequisite to landing a job, I think few of us would work at all. I mean the thousands of one-man-band projects out there on github in varying stages of abandonment. Merely showing your job is also your hobby doesn’t make you special.
In some of my recent posts on Agile I voiced my excitement and support for the Agile 2 movement. Indeed, after many years in software a breath of fresh air can still get me motivated. Agile 2 has given a renewed incentive to everyone’s favorite waste of time: quarreling in comment threads about the True interpretation of the Agile Path. “Folks, can we please stop going around in circles. Agile is perfectly straightforward if you do it our way. Just come back from the Dark Side and get certified with us”.
Forgive my tongue in cheek. Disagreement is not a waste of time. It’s the foundation of any democratic process. Software projects are still being scrapped midway or delivered with huge overruns, and Agile has notbrought us the magic bullet. Have you not been involved in those projects, or been partly responsible? We still haven’t found what we’re looking for, as Bono sang. Every proposal to improve out methods, from modest to maverick, deserves to be heard.
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.