I’m the manager of a great team, based 1,588 km from where I work. I can see the Alps through my office windows, they’re in Andalusia and can see the Sierra Nevada. So I spend a lot of time chatting to them via Teams, a sad avatar of modernity. At least we talk to each other and see each other every day.
Fortunately, once or twice a year we’re lucky enough to spend a week together. We then try to organise or create group activities, which take us out of the rhythm of sprints and deliveries.
Last time, following my visit to Snowcamp where a speaker recommended it, we did an hour of collective reading of Brooks’ classic chapter, “No Silver Bullet: Essence and Accidents of Software Engineering” (1986). I wondered if this old text would speak to a team none of whose members were born when it was written (apart from me…).
I was just discovering the text and found it incredible. Almost forty years old and still relevant reflections to answer the question: why is it so difficult to carry out IT development projects, and why is it that, while computers are becoming ever more powerful, IT projects are always lagging behind?
The title compares a development project to a werewolf. Innocent at first glance, a project like any other, which sometimes, often, turns into an uncontrollable monster that eats up budgets and deadlines. And Brooks demonstrates that there is no silver bullet that can put an end to it.
The text is short and dense, and I won’t insult you by summarising it. If you’re intrigued by the subject and don’t already know about it, read it.
Collectively, here’s what we did: I asked those who wanted to to read the text in advance (everybody did). Then, on the same day, I gave a brief introduction to the author, werewolves and the question posed by the text. Then I asked the team members to identify the main ideas in the text, which we put together collectively, and we discussed some old points (time-sharing) and some more recent ones (AI & expert systems).
Rather than listing our summary here, I’ll just quote a few extracts that I really liked.
Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level).
I really like this idea of a human construct, so vast and complex that it has thousands of parts, all different.
[Software] is pure thought-stuff, infinitely malleable
There’s something that links my two great professional passions: writing novels and writing software. As a teenager, I loved touching my first word processor and discovering that I could change everything infinitely. In fact, I think the term ‘infinitely’ is a bit misleading. Eventually you get tired of changing everything and programmes, like novels, crystallise.
Software is invisible and invisualizable
This idea also makes you dizzy. Our team is responsible for half a million lines of code, it’s our domain. We have no way of seeing all the details at a glance. Even our diagrams and plans are only partial indications. We are responsible for a labyrinth in which we are constantly laying down guidelines for the programmers of the future who will pass through it.
The most powerful contribution by expert systems will surely be to put at the service of the inexperienced programmer the experience and accumulated wisdom of the best programmers. This is no small contribution. The gap between the best software engineering practice and the average practice is very wide_perhaps wider than in any other engineering discipline. A tool that disseminates good practice would be important.
Very good vision of the impact of Copilot-like tools, even if Brookes didn’t anticipate the negative consequences…
What would you recommend for future team reading? Extracts from Clean Code or Pragmatic Programmer? The passage from Jurassic Park describing the bug in the surveillance system? All ideas are welcome!
Leave a Reply