Twenty years ago—before C# was a thing and people thought the world would fall to pieces at the turn of the millennium—Andrew Hunt and David Thomas published their book, The Pragmatic Programmer. It received a lot of attention on publication, and is being picked up again today by younger programmers. Most of the ideas discussed still apply, even in the contemporary world of software development, where you have AI autocompletion integrated into your IDE and you can clone any repository of code available on the internet at the drop of a hat. A lot has changed since the book was published, but the ‘pragmatic’ approach has stood the test of time.
In order to celebrate the book’s twentieth anniversary, the authors have published an updated edition. They’ve carried over a lot of the concepts of the early text. However, they’ve also brought them up to date to reflect the current state of the development industry while preserving the fundamentals of the ‘pragmatic’ approach—the authors even ran a complex diff, using regular expressions to ignore small changes between editions, and showed that only 30% of the book hadn’t been reworked. So, these are old and tested ideas applied to newer contexts.
This blog post discusses ‘Pragmatic Programming’ as presented in the opening chapter of the new edition. Like many things in life, the matters discussed aren’t always amenable to a single, simple answer. You might want to check out the official web page for the book.
The Pragmatic Mindset
The first concept discussed is the phenomenon whereby ‘the cat ate my source code’. This applies wherever developers decline to take responsibility for tackling problems, but palm them off on someone else instead. Even with thorough testing, good documentation and solid automation, you’ll inevitably encounter late deliveries and unforeseen technical problems in the course of your work. The book made me realise that often (though not often enough!) such situations occur through no fault of my own: but that doesn’t mean it isn’t my problem, or that I can assume someone else who knows what they’re doing will fix it—which, as an intern new to the industry, is an easy position to take.
One recent development is the integration of ‘git blame’ into many IDEs, which tells the user who last created or modified any particular piece of code. I feel it is too easy to see a piece of code which is making your life difficult and want to pass the ‘blame’ onto an earlier author. This way of thinking isn’t useful when developing, though like many of you, I guess, I often find myself getting annoyed with somebody I’ve never met because of the code they’ve left behind. But I’m learning that just because I didn’t write the code, if I’m working with it then I should take responsibility for it anyway. This is a good mindset to have if you want to prevent the onset of the ‘broken windows’ scenario discussed below.
Admitting ignorance and mistakes with honesty—not only to your team but first of all to yourself—is a good first step in countering this denial of ownership. I initially found it difficult to accept that things will occur beyond my control, and yet the consequences of the resulting failures may fall on my desk anyway. There’s a balance to be struck between pointing out when something has been done poorly in order to address and fix it, and merely pointing the finger of blame. Hunt and Thomas explain how you can prepare for such outcomes, and why shouldn’t blame such unforeseen events as the reason why your project was delivered late, or a key feature wasn’t added. The book highlights the words “provide options, don’t make lame excuses”, which for me is still a work in progress. A challenge at the end of this section is; whenever your answer to a question is “I don’t know”, be sure to take responsibility for the fact and follow it up with, “… but I’ll find out”.
Debt vs Decay
The next concept the book raised is potentially the most important to me. It discusses the idea of ‘software entropy’, and claims that the term is often used interchangeably with that of ‘technical debt’. However, the difference between the two is that when you call it ‘technical debt’, you imply that it will perhaps be repaid, which is often not the case. One of the main contributors to software entropy is the psychology, or culture, of the project team. Researchers into urban decay made a fascinating discovery of a trigger method which causes some buildings to be pristine, while similar buildings in the same neighbourhood become abandoned and derelict: ‘a broken window’. They discovered that one broken window left unrepaired for any substantial amount of time, inspires in the inhabitants of the building a sense of abandonment. It gives them a sense that the powers that be don’t care about the building. This causes another window to get broken, and then graffiti, litter, and structural damage all follow in turn. The building will then become damaged beyond the owner’s desire or ability to fix it.
A developers’ ‘broken window’ can be the result of bad design, a wrong decision, or a poor piece of code. If you fix each problem as it is discovered, there will be no further problems caused by this window. If you can’t fix it for whatever reason, make sure you at least board it up. ‘Boarding up’ can consist of commenting out the ‘broken window’ or using dummy data instead. So long as you take action on the broken window, you’ll keep on top of the situation. As soon as you leave a bad decision or a poor piece of code for any significant amount of time, you’ll see that just how quickly a clean, functional system can deteriorate. It is neglect that enables software entropy.
The book discusses how to counteract software entropy. It mentions the firefighters who lay down a mat in someone’s house before bringing in the hose to put out the fire, because they want to do as little damage (disrupt the system) as possible. The equivalent idea with code is: do as little harm to the rest of the project as possible, and don’t break any windows. I don’t have too much to say on this as an idea as it seems obvious when you say it out loud; but I do know that, in software development as elsewhere in life, there’s a difference between knowing what you should do and actually doing it.
Stones and Toads (sort of)
The next analogy the chapter uses is the story of ‘Stone Soup’ and the story of ‘Boiled Frogs’. This ties to development in situations where you know what needs doing and how to do it, but if you ask permission to tackle the whole problem you’ll be met with delays and blank stares. This is when the idea of ‘stone soup’ comes into play: work out a reasonable request, develop it well, then show people and let them admire what you’ve done. Then start telling them how it’d be better if you added feature X without great importance. The book then says that this is the moment where you can sit back and wait for them to start asking you to add the functionality you originally wanted. “Be a catalyst for change” is typeset in bold on the opening page of this story.
I think it’s a useful anecdote, but I find it strange how the tale is one of deception from the soldier’s point of view. It’s potentially dangerous to see this as a method to deceive your manager or whomever you may be presenting the idea to. I think it’s more useful as a reminder to act as a catalyst. The story shows a way of bringing a group of people together so that something can be achieved that maybe wouldn’t be possible if it was a solo effort.
The book retells the story from the villager’s perspective. The deception in the story comes from focusing too tightly on details, so the big picture gets lost. “The villagers think about the stones and forget about the rest of the world”. This is a key cause of projects overrunning significantly, because people focus on a specific task and search for perfection, which adds time unnecessarily to the project. This may not seem like a significant change but if you have five developers doing this every week, then every week you’ll slip further behind schedule. This ties in with the discussion of what is ‘good enough’ code later on in the chapter, and I think it’s something that has helped me to always keep in mind, when both completing and estimating work.
My Outlook Post Chapter
The things that I read in this chapter really started to drill into my head more when I returned to work the week after reading it and started noticing ‘broken windows’ popping up, as well as old code causing me problems. I like what the book teaches. If every developer followed it as if it were the law, maybe software development wouldn’t be so easily stereotyped as an industry plagued by poor planning and execution. I realise that asking everyone to do the right thing may be unrealistic, as many people will not always be able to abide by the law, whether they want to or nor. It is easy to know what you should do, yet often hard to actually do it. But it is good to be reminded of how we ought to approach problems. And good too, to think about what it is that sometimes prevents us following through on them.