By “I read” I mean “I finished the final chapter of, 14 months after starting,” and I should really go back to the start of Subramaniam and Hunt’s Practices of an Agile Developer and read it all over again. Sounds like a grim Sisyphean chore when I put it that way, but in fact I quite look forward to it: I purchased the book as a PDF, and as I slowly worked my way through it (via GoodReader on my iPad) I studded it cover to cover with my own notes and highlights. Between these personal defacements and the fact that I’ve had more than a year to gradually apply the book’s guidance to my own work, I want to see where in my own processes I know that I’ve improved, and where both the authors and my past self would probably agree I still have a long ways to go.

I have already written about the most profound way this book has changed my work style and habits, teaching me to think about software projects in terms of small, rapidly built, independently useful sub-deliverables, rather than monoliths with a single goal of “everything you could possibly want works now.” Practices allows itself to assume that software projects fail — or nominally succeed, but go way over-budget, ending up rushed, poorly tested, and unmaintainable — less due to software engineers’ perceived (and, indeed, stereotypical) inability to plan, but more because a software project of any significant size simply resists planning. Fixed Prices are Broken Promises, states one of this this book’s 45 chapter headings, and one of its many well-argued insights that make me want to shout hell yes, preach it and good lord I have been doing everything wrong simultaneously.

Even though the book’s title contains the a-word, which for a long time I dismissed into the same hacker-fad corner as standing desks and paleo diets, it does not advocate any of the capital-A implementations I’ve run into (and backed politely away from), such as Scrum or XP. (It does mention their existence from time to time for the sake of example, but ends with cross-references to other books rather than diving into details.) This book does not prescribe any recognizably “Agile” tools, techniques or ceremonial dances. Rather, through all the practices it recommends, it advocates recognition that the mere act of building a software project always, always causes it to continuously change shape, and it offers advice for coping with this extremely non-ideal reality.

I really would urge any contemporary full-time software professional to read this book, or another book sufficiently like it.