Introduction

“We’ve spent over a decade now becoming more and more agile and adaptable in our ways of working. Unfortunately our software is now struggling to keep up with the pace of innovation that is increasingly being demanded by modern businesses. It’s time to sort that out.” - Russ Miles

There are enough boring books out there on software development, enough probably to fill Foyles many times over.

This is not one of those books.

What this book is NOT about

Rather than waxing lyrical on highfaluting thoughts, concepts and ideas in software development, or getting tangled up in the exhausting and ultimately mostly meaningless discussions (see: wars) around languages and frameworks, this book is going to dive into the practical tools I’ve found that really help with building software and that meet the challenges of modern software development.

That means the following topics are rendered essentially meaningless and so have been completely steered clear of.

Brand X Process

Processes are merely ways of organising work with the aim of trying to ensure that something valuable happens.

This book will be avoiding discussions of the form “Scrum is better than Kanban because… <insert biased and inane argument here>” and instead concentrate on practical tools that you can use to tailor your own process.

As a wise man once said, do what works for you. I aim to help you to figure out what works for you, not sell you on Brand X of anything in particular.

Brand X Methodologies

Methodologies are colloquially used to mean processes in software development. Methodology is a misnomer typically used by people who wish to make something sound much more important and complicated than it actually is, often in order to drive up consultancy day-rates or justify cash-cow Certification regimes.

Treat any methodology as suspect and with intense skepticism. In fact, treat all doctrines, ideas and rules that way and you’ll do well in software.

Doctrine & Dogma (sort of)

I have a sneaking suspicion, but ironically I can’t necessarily empirically prove, that the majority of what is broadcast in software development in terms of self-evident practices and processes is often just simply someone’s own beliefs with no empirical basis whatsoever. Nothing that would get past a half-decent scientific journal’s panel anyway.

On their own, and when clearly stated as ideas and beliefs for your own consideration, doctrine from experts in our field is not necessarily damaging or unimportant. If we held out for clear proofs of every tool, process or practice we came across then I’m fairly sure we’d never get any work done. The problem is that in the majority of cases that doctrine quickly becomes dogma; the unvarnished and unequivocal truth to be defended to the death by its adopters.

I’ve lost count of the number of times I’ve heard the argument “you’re not doing it right, to be really Agile you need to be doing X”. I pick on Agile here because it is an area of thought in software development that, due to its broadness and even in the face of clearly useful foundational and revised principles, it still attracts its fair number of coaches, consultants and bigots (I often like the term zealot) even some 10 years since its inception.

The problem with these individuals and organisations is they do not have skin in the game. They are offering unempirical advice and belief as if it was certainty with no direct threat from the action being taken on that advice. This is dogma prevailing.

When Dogma prevails, valuable outcomes are lost in the noise of opinion-driven accuracy to some authority. This has no place in this book.

Here I shall be talking about exactly how I design systems, with real skin in the game every time I do.

What this book IS about: Attempts (Essais&)

This book is a collection of attempts. At first that might sound odd but attempt is in fact the mostr appropriate translation of the literary form that we’ll follow and that was originally popularised in Montaigne’s own work masterwork, the Essais.

So this book is a collection of essays. You can take each essay in isolation or as a whole, the choice is entirely yours. Some essays are related to one another, and in those cases I’ll attempt to make that very clear. Others stand alone for your consideration.

And that’s the important point, these essays are presented for your consideration. I would like you to take the ideas in this book and apply them carefully to your own software development work with the understanding between us both that these are my own ideas based on my own experience and context and that they may or may not bear the same fruits in your own particular context. As such it’s probably useful at this point to propose a little contract between us. Nothing onerous, just making it explicit what I’m attempting to do with these essays and what I’d like you to do when reading and applying them…

Our Proposed Contract: Nullius in Verba

Forgive me but we need an agreement, a contract if you will, while you read this book.

For your part I’d like you to agree to keep something in mind as you read about the ideas presented here; I’d like you to keep the tagline of the Royal Society in mind: “Nullius in Verba”.

“Nullius in Verba” essentially means “Take nobody’s word for it” and it’s a great guiding principle when considering applying new ideas, ways of working or tools to your software development.

Your unigue context is king when considering the ideas in this book, and “Nullius in Verba” will guide you to try, accept or disregard what I present, which is exactly what I want you to do. That’s what I’d like from you.

While you keep “Nullius in Verba” in your mind I’ll be attempting to give you ideas ready for them to be (hopefully) fruitfully critiqued and mined by you for your unique context. My part of the contract is to ensure I only promote those things that I have done myself, thereby having real skin in the game.

Do we have a deal? Ok, then let’s get going, this is going to be fun, I promise.