Yesterday we watched the Netflix documentary The Ripper about Peter Sutcliffe, a.k.a. the Yorkshire Ripper, who was found guilty of thirteen unspeakably violent murders and seven attempts between 1975 and 1980. Last November he succumbed to covid, 76 years old. I am not a particular fan of true crime stories, but it ties in with my previous post about failure.
The police authorities failed miserably. The huge workforce dedicated to cracking the case was plagued by tunnel vision, herd mentality and sexist attitudes that frustrated the investigation, costing millions of pounds and probably several lives while looking for the wrong man. At first it was roundly assumed and put about that the killer only targeted prostitutes, giving rise to the callous sentiment that decent women had nothing to fear. It turned out the attacks were in fact indiscriminate. Even more harmful was the misguided attention given to a number of letters and tapes the police received, allegedly recorded by the killer himself, in which he taunted the force for their lack of progress. Dialectologists pinpointed the very pronounced accent to a region in Sunderland. The tapes turned out to be a hoax. Anyway, read the Wikipedia page if you have neither time nor Netflix, and prepare to be amazed.
We like success stories. Dished up well and accompanied by a slick Ted-talk they turn into best seller books, heaping success upon success. Tales like that make generous people feel good and jealous people feel miserable. Anyhow, I think we should read more about failure, especially in IT. It has much more to teach us.
Failure is everywhere and the longer you live the more failures you can chalk up. Half of all marriages fail. Most professional actors and musicians fail to make a decent living. I failed my driving test three times. Before his glorious revenge Steve Jobs failed pretty badly as a father and Apple founder first time round. The 1984 Macintosh was a commercial flop. In fact, most products fail. Clever people with a terrific track record can still fail spectacularly. Sometimes their road to failure is documented that we might learn from it.
Dreaming in Code (2007) by Scott Rosenberg is one of such books, and an all-time favourite of mine. Written for a non-technical audience Rosenberg follows the inception and first releases of the open-source Chandler project – not related to Friends, but named after the author Raymond Chandler.
Read the original Dutch post. How often do we need to hash it out as Scrum practitioners that you shouldn’t translate story points into hourly estimates? Well, often enough to make me wonder whether there isn’t something inherently fishy about this obsession with numbers. Should you now feel the urge to wield the Scrum bible and explain what it says about story points and velocity: the 2020 edition still makes no mention of these concepts. Surprised? The developers who are doing the work are responsible for the sizing is the closest match. Alternatively, there are eighteen variations on the root of adapt-: adaptability, adaptative and adaptation. More than anything the guide stresses value and values: the value that the product represents to stakeholders and end-users, and the values that we should commit to in order to make the process a success.
The added value of a software increment is easy to express in a figure if it directly translates in increased revenue or reduced cost. But it’s never that straightforward. How do you value a better user experience, better service, attractive design, let alone a combination of all these? You can’t, at least not within a single increment. Consider the ways you can reward the people creating that value with more than just a pay check. Is there value in better equipment and more modern technologies when the end user does not see it? How about humane working conditions, instead of an annual death march to make it to the Christmas shipping deadline. The debacle with Cyberpunk 2077 has shown that it is hard to make good on your promise of the coolest game ever, and very easy to ruin your reputation with a shoddy first release.
I was ever so excited to join a team working on a major Scala codebase for a suite of in-house reporting tools. My only experience with the language up to that point were self-study, hobby projects and a Coursera course. Two years on and I am mainly doing Java again, at my own request I might add. Has the love affair reached its end? Not entirely, but it has cooled.
There is a pretty big gap between the conceptual soundness of a language and the grim reality of building working software with it. However well designed, it can never be a joy to work in without a stable and extensive support system, starting with the IDE through to testing frameworks, proofing tools, etc. No JVM language can match the range and maturity of the tooling we have for Java, especially when you go beyond mere IDE support.
I have been a keen “e-reader” these last ten years and have owned several devices. I love the lightness and backlit display of my Kobo Aura. But here’s why I still buy paper books:
There is no e-book available. Yes, that happens.
The e-book is actually more expensive. Incredible, but it happens.
Large-format art and photography books: doesn’t need explaining
I want to support my local bookshop.
Pride of ownership works better in print.
I also bought no shortage of IT books since 2000. The learning experience of a well-edited book written by an experienced specialist is superior to most online tutorials or blogs. Current shelf occupancy is some 20% of what I owned in total, the rest having been discarded, given away or sold because they were replaced with newer editions or were about technology I have abandoned myself (Perl..)