So in today’s blog we are going to start a new chapter in The Pragmatic Programmer with chapter 4 called Pragmatic Paranoia.

Pragmatic Paranoia

David and Thomas start this chapter straight of the bat with a tip and it’s a very realistic one which says: “You can’t write perfect software.” Haha yes, indeed. This is what Uncle Bob tries to teach us in Clean Code as well. You can write fabulous code today but maybe a week later the requirements changed and your fabulous code isn’t that fabulous anymore because it doesn’t fit the latest architecture. Also remember the practice of tracer bullets from a few episodes back. Sometimes you write code for exploratory reasons. This is perfectly fine!

But David and Thomas tell the reader, us, to embrace the fact that we cannot write perfect code. Unless you accept this, you will be chasing a dream and wasting time trying to reach that asymptotic goal. They also ask us how this depressing reality could be turned into an advantage by pragmatic programmers.

Next they mention one of my favourite analogies in software development. Defensive programming.

Defensive programming is like driving a car. We all know, you, yourself is the best driver in the world. All other drivers are just idiots. So the best strategy while driving is a defensive strategy. We look out for trouble and anticipate things that might happen. You can do the same in software. At every architectural boundary or bounded context you can do sanity and security checks in input. Then when the data is inside the bounded context you are assured it is valid.
Pragmatic programmers however take this a step further. They don’t even trust themselves. We know that no mortal is able to write perfect code. So Pragmatic programmers also use defensive strategies to protect them from themselves.

This chapter will dive into a number of strategies on how to do so. We will check out a concept called “Design by Contract” which basically boils down to clients and suppliers agreeing on rights and responsibilities. In the Clojure programming language you can these things called pre-and-post conditions to functions. When in or output does not adhere these conditions, the function will throw an exception. I always thought this was a really cool concept, and implemented at the language level can help you with the robustness of the code.

Next we will discuss a concept called “Dead Programs Tell No Lies” haha. I can’t really remember what this section is about but they hint at it being about not doing any additional damage while working bugs out. This is indeed very important. Have you ever heard the idea that for every bug you remove, you insert 3 more? I think we even had to read some scientific literature about this concept during a course on software evolution and life-cycle back in University. That was one of the more interesting courses too 😉

Next-up is a section called “Assertive Programming”. This section is one that I do remember and it’s about leaving assertions active in production code. This can be a great tool to maybe work around the pre-and-post conditions I was talking about earlier.

Then we have a section about “Exceptions”. Of course, any book about great coding habits needs to have a section about error handling. We talked about it during clean code, and we did so as well during our deep dive into A Philosophy of Software Design. Both Uncle Bob and Prof. Ousterhout had lots of valid points and mostly aligned surprisingly enough. So we will see if David and Thomas are on the same line as them as well. Spoiler alert, they probably are!

The last section of this chapter is called “How to Balance Resources”. This is about how you manage exceptions, memory and data. David and Thomas will describe a number of strategies on how to do this in a c++ and Java.

So, those are the topics we will be discussing in the upcoming blogs. See you next time!

#end

01010010 01110101 01100010 01100101 01101110