Scrum is toxic; agile is dead. Is Shape Up the answer to how we develop software products?

“Code is harder to read than to write.” I first came across this perplexing idea some 20 years ago. How can this even be?

I have the sudden feeling that I’ve joined a cult. We are sitting in a circle, me perched on a chair, everyone else slouched back on a sofa or bean bags. Everyone is quietly writing on post-its with Sharpies. I’m holding the same, but I’m not writing anything, as this is my first week on the job and I’ve never been to a retro before.

Eight years ago, when working with a client for whom we were proposing to build a new publication website and CMS in Ruby on Rails, one of our client’s advisors referenced a blog post that advised against using Rails. I wrote up our response to this, lightly edited it into a blog post, but never published it. Coming across it in my notes, I was curious: how do the arguments for and against a tech stack stand up over time? And was it a bad call to go with Rails?

High Output Management, written by former Intel CEO Andrew S. Grove, is the management classic of the tech industry. Published in 1983, it has inspired generations of Silicon Valley startups. But is it one of those works that was revolutionary in its time but is now of interest only as a curiosity of Silicon Valley history?

The first principle of the Agile Manifesto is: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” But who defines what’s valuable?

I found it difficult to write up my thoughts on An Elegant Puzzle. On the one hand, the book is gorgeous: it’s a beautiful hardback volume, printed in colour on thick paper. On the other, it’s not a very enjoyable read: it’s dense with prescriptive advice, interspersed by mostly superfluous diagrams. Larson does do a difficult and rare thing: he tells you exactly what he recommends to do.

The first programming language I ever used was BASIC. I was twelve or thirteen when a classmate introduced me to it. The first thing I tried making was a text-based choose-your-own-adventure game. Little did I know that even in this first exposure to code I’d form conclusions that have stayed with me throughout my life.

Or, why I love software engineers who have prior careers.

So you’ve got a job as a junior software engineer. Congratulations — it’s a fun gig! At first you’re just chuffed that you’re in this new role. But at some point you will inevitably ask: what do I need to do to not be a junior any more? Chances are — despite career ladders and progression frameworks becoming more common — your organization won’t have a clear answer.

There are six of us sitting around the table: me, my boss, his boss, and, across from us, our senior client and his two lackeys. We are on the receiving end of a grand bollocking. How did we end up here? I had messed up a technology choice.

We’ve been told the artificial intelligence revolution is right around the corner. But what if it isn’t? What if this is just another false dawn? After all, we’ve been set to harvest the rich bounty of AI before. Technology turning out to be a false promise in general could mean that we — and our children, and their children — will have to get used to a world of diminishing prosperity.