This review is an insult based on lies about the book's content. The author says "unlike the authors, I know that DRY does not hold true everywhere". Meanwhile, on pg. 35 of Pragmatic Programmer: "Later on in the development process, you may choose to violate the DRY principle".<p>Similar exaggerations and mischaracterizations pollute the review. I could go on but it is too infuriating. Delete this.
I'm not finding I agree with this review, but because the author has chosen their quotes selectively, I want to point out:<p>"broken windows". The book uses the turn of phrase, but does not (unless maybe in the original edition? I have the 20th anniversary one) actually quote the debunked theory beyond this phrase. Take it as the turn of phrase that it is, no need to read more into it than is present. If you don't like it, consider something more like "if you see trash on the ground, pick it up, don't step over it." Though that's a heck of a lot wordier. But about the selective quotes, let's take the <i>whole</i> phrase from the book:<p>> Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. <i>If there is insufficient time to fix it properly, then board it up.</i> [emphasis mine] -- page 7<p>The emphasized part is what the reviewer didn't include. By only reading the first two sentences, sure it reads as a bit dogmatic. But reading the whole thing, it's clear that there is more to it. What does "board it up" mean? Well, they expand on it in the following sentences:<p>> Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. Take <i>some</i> action to prevent further damage and to show that you're on top of the situation. [emphasis in original]<p>That seems pragmatic to me, "I can't handle it properly now, but I'll do <i>something</i> that reduces the problem or draws attention so it can be properly handled later." In the JIRA-driven world, put in a new ticket.<p>They don't prescribe <i>one</i> answer or <i>one set</i> of answers to the problem, except to address it. Which is pragmatic because leaving garbage in a system is a really good way (over a few years, anyone who has worked on long-running systems will have experienced this) to end up with a load of garbage.
Personally I think the broken window theory still holds up, at least at a superficial level. The notion of permissibility drives behavior in these human operated systems (neighborhood vandalism/software development), and visible examples are signs of what's allowed or acceptable that if left unchecked will soon be widespread - people like to push the limits. The study doing the "debunking" was itself looking at other studies tying broad local criminal behavior to signs of vandalism, which is not what should be correlated here, just more broken windows. Of course the theory itself has been weaponized quite unscientifically, but that doesn't take away its explanatory power. Maybe for software we can call it the "temporary hack" theory, where a codebase will soon be held together with duct tape and one liners if things aren't nipped at the bud.
I've seen this sentiment more and more recently. This sentiment is shared with books like Clean Code, which, when I first heard this, was shocking. Clean Code was one of the best books I ever read on programming, and at the time was hugely influential to my career growth. In fact, it helped me so much that I was able to uplevel other engineers by mentorship at several organizations that I've worked at.<p>That being said, there have been some great critiques of these books and it's kept me wondering if maybe I'm misremembering these books for what they were. Here's a critique on Clean Code: <a href="https://qntm.org/clean" rel="nofollow">https://qntm.org/clean</a><p>Has it really been that long? Are these books really this outdated now? I saw a similar thread on Reddit recently and the alternative they recommended was this book... <a href="https://sandimetz.com/99bottles" rel="nofollow">https://sandimetz.com/99bottles</a> I've read only a couple of chapters, and I'm struggling to see why this book is so much better. Anyone have any opinions on this?
I bought TPP when it was published and it changed my thinking about software development in many very positive ways (unit testing and refactoring for example).<p>But, the author of this article seems to forget that this book is now over 20 years old and not everything written by Hunt and Thomas still holds true. But thinking about and trying to define how best to produce good software is an ongoing dialectic and one size doesn't fit everyone, some ideas reach their sell-by date. Pick the best bits and get on with the job.<p>Would I recommend TPP to novice developers? I've not read the 20th anniversary edition yet which apparently addresses how software development has changed since the original publication so my verdict is out on that question.<p>The article author doesn't make it clear which edition of TPP he's criticising, but if it's the original edition then I think he's unfairly beating a dead horse.
Most of these books that were standards in the 2000s don't hold up great now, just because most of the important parts have diffused and become ambient omnipresent practices.<p>Putting so much emphasis on variable naming, to take one common theme from Code Complete, Pragmatic Programmer, Clean Code, et al, makes a lot more sense coming out as a reaction against some of the worst excesses of Hungarian notation.<p>They just aren't the kind of revelation that they were 20 years ago, in part because they've been so successful at molding multiple generations of programmers now.
This review is trash. Calling a style guide for programming bad because it is opinionated is like calling sugar bad because it is sweet.<p>The whole review just drones on and on about why the book should not be opinionated about coding practices not realising that the books of this genre are useless without strong opinions.
This is the No True Scotsman fallacy applied to pragmatism: <a href="https://en.wikipedia.org/wiki/No_true_Scotsman" rel="nofollow">https://en.wikipedia.org/wiki/No_true_Scotsman</a><p>No true pragmatic programmers would waste time minimizing technical debt, they will always take the simplest path.
The point about broken windows having been debunked for crime is a non-argument when applied to programming. He's comparing apples and bananas. Someone just happened to use a term for two things that are only kinda related.<p>I don't even use the term 'fixing broken windows' for programming, I use the term 'repaying tech debt' . That's pretty universally seen as a good thing, if not without difficult tradeoffs in real world business software eng.<p>There's a fair bit else that's off in this article and it's quite an uncharitable reading of a classic book. There are no sacred cows but PP doesn't warrant a hatchet job.
> Dogmatic Programmer: let’s make everything abstract, what if we need to switch databases?<p>> Pragmatic Programmer: we will never switch databases.<p>In other words, the blog author is saying "I don't have much software experience." I used to think I'd never switch databases too, until I built a very large system and had to switch databases.
The author misses the point of abstracting portions of systems away. First, you can create shim layers for unit, component, and functional testing. Many of these tests can be automated, without the need of a database, or other functionality required during deployment. Next, if your software is written for you, and only you, then you're losing on others using it or other customers. Customer A might not use DB 1. Customer 2 might use DB1 at certain locations, and DB2 at others.<p>The abstraction portion also gives a tester the ability to see if what comes in, is what needs to come out, without reliance on additional hardware and other sunk costs. A simple example is a currency/bill validator. These are expensive pieces of hardware, and not needed to verify other portions of the system, but a module for that device can be emulated.<p>Next, it appears he hasn't read the book Pragmatic Programmer, or the book went over his head. "Don't live with broken windows", "Make it easy to reuse", and "Decoupled code is easier to change" are three hallmarks of the book. All three are in contradiction to his article.<p>If you haven't read the Pragmatic Programmer, I highly encourage you to read it. It is a required read in my company.
> Why? And “strategic”? I thought this book was about being pragmatic (foot on the ground, present) not “strategic” (heads in the cloud, future)<p>It's a good summary of the article. All of the time is spent trying to frame the book in a way (non pragmatic) and the author of the article in another (pragmatic). Articles like that usually have little to no value. At most, 5% of the book has been covered in the article, and that seems to be enough to reject everything.
I always code as specifically and practical as possible. Whenever I hear someone let's do this as general as possible - the junior dev bell rings.
Broken Windows is indicative of lack of resource, not lack of moral rectitude.<p>We leave the window broken because fixing it takes effort away from fixing the overflowing sewage or the dangerous roof.<p>If you have time to fix the windows, then someone has hired enough coders to fix the sewers and has time left over. That's a nice position to be in.<p>Work to be in that position.<p>It may be that you should build your buildings from open, pre-fabricated material :-)
Honestly, although I don't agree with the author's sentiment.<p>Yet, even though I found the old version very influential and a great read at the time, the updated version feels a bit quaint for me.
Especially because it uses old metaphors.
The author mentions the "Broken Windows" Theory.
<a href="https://en.wikipedia.org/wiki/Broken_windows_theory" rel="nofollow">https://en.wikipedia.org/wiki/Broken_windows_theory</a>
Especially as it moved towards Stop-and-Frisk in NY, I would not use it in a technical book today:
<a href="https://www.npr.org/2016/11/01/500104506/broken-windows-policing-and-the-origins-of-stop-and-frisk-and-how-it-went-wrong?t=1641400259087" rel="nofollow">https://www.npr.org/2016/11/01/500104506/broken-windows-poli...</a><p>Another one is the "Boiled Frog" from Topic 4:<p>"We've never tried this—honest. But “they” say that if you take a frog and drop it into boiling water, it will jump straight back out again. However, if you place the frog in a pan of cold water, then gradually heat it, the frog won't notice the slow increase in temperature and will stay put until cooked."<p>The same as with the broken window, it's just not true:
<a href="https://en.wikipedia.org/wiki/Boiling_frog" rel="nofollow">https://en.wikipedia.org/wiki/Boiling_frog</a><p>It makes it hard for me (personally) to use the lessons of the book (cognitive dissonance ... "wait but a frog would jump out" ... ).
Given the work that went into the anniversary book, I am wonder if the authors could not have found better fitting metaphors.<p>Edit: clarity + typos.
I am looking for a list of type of developers posted here more than 10 years ago. Types like the shotgun programmer, the duplicator, the abstractor etc. It was an awesome text only list of many different types. I cannot find it.