Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's probably time to stop recommending Clean Code (2020)

qntm.org

Post reply on HN
Print view View original

121–130 of 216 posts

Re: It's probably time to stop recommending Clean Code (2020)

#121

Post by KronisLV »

ornornor wrote: post #113
KronisLV wrote: post #104

Earlier quoted context omitted.

> I love fixing things. I actually enjoy working on a crappy codebase that has made the company money but is now too hard to maintain/extend and needs cleaning. Adding tests, refactoring, extracting functionality to discrete functions, figuring out what the black box actually does, etc. This is what I’ve specialized in. I am thankful that people like you exist, but after having taken on that role out of necessity mys…

I find that you can’t always fix everything. But the biggest hurdle is actually getting buy in (even if there is already buy in and that’s what you were specifically hired to do) Rewriting is tricky. It’s sometimes necessary (outdated and unmaintained language, obscure tech you can’t find people for, or sheer tech bankruptcy) but it can also not solve anything. As you implement the new version, you rediscover all the…

> As you implement the new version, you rediscover all the arcane business rules, edge cases, and sheer craziness that you didn’t know about and the rewrite ends up either lacking these or becomes The Mess v2 because you had to bolt all this weirdness on after the fact making the new codebase suck in a different way but overall as problematic as the one it replaced.

Sometimes I wish we could just look at an implementation that's meant to serve a business process and go: "Listen, we gave it a shot, but the technology and developers we have available cannot provide a satisfactory implementation for this, without making the entire thing a liability. Can we simplify the domain instead?"

I've actually tried this in the past (in a more mild form) and it has actually worked - sometimes getting a paragraph or two of changes approved in a 50 page spec can save you weeks of work ahead of time, which you'd otherwise spend because someone didn't realize which parts of the spec are technically unfeasible.

Sometimes it's actually easy to reason about, such as when you're doing a rewrite from AngularJS or something else that's deprecated to something more modern, and can suggest a few simplifications to "prioritize quicker iteration, shipping core features quickly and simplified UX for less friction", which might mean simpler components.

Or you might find yourself in an inflexible domain, having to replicate "the old thing" close to 1:1 which will take way more time than either writing or maintaining it would. There, rewrites don't make that much sense. At that point, if you need more modern elements (runtimes, libraries, frameworks), I'm not even sure what you could feasibly do, aside from setting up a new service and rewriting paths for particular new API endpoints to the less rotten codebase, but that has challenges of its own and can get out of hand.

Re: It's probably time to stop recommending Clean Code (2020)

#122

Post by camgunz »

I definitely agree that Clean Code is past its expiration date. In its place I'd recommend Code Complete, Rapid Development, A Philosophy of Software Design, and The Practice of Programming. I think more than any specific book is that by reading multiple opinionated viewpoints you'll start developing taste of your own that's grounded in a pretty good survey of approaches. If your philosophy is literally based on one book, you should probably read at least one other one.

Re: It's probably time to stop recommending Clean Code (2020)

#123

Post by camgunz »

edflsafoiewq wrote: post #116
Jtsummers wrote: post #39

Earlier quoted context omitted.

I'm still amused by claims that the book is dogmatic when these paragraphs are in the opening chapter: > Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and prof…

It's dogmatic in the sense that it often pursues some point (such as very short functions) to the level of a dogma, without much regard for the benefit accrued.

And no evidence. Other programming books cite academic or case studies. Martin's book is essentially a long appeal to authority to himself. If he'd written like, Quake or something I might buy it, but he hasn't.

Re: It's probably time to stop recommending Clean Code (2020)

#124

Post by zepolen »

xupybd wrote: post #115
zepolen wrote: post #107

Earlier quoted context omitted.

That's not a problem with bool arguments, that's a problem with the language and tooling.

That can be resolved with enums.

If your language/tooling and naming is bad then no, enums won't resolve it either:

Is this a username or a state?

  create_user('ADMIN')
Same for, could be a variable for the admin username, can't be sure can you:

  create_user(ADMIN)
Even this:

  create_user(User.ADMIN)

Re: It's probably time to stop recommending Clean Code (2020)

#125

Post by superjan »

Jtsummers wrote: post #39
DanielVZ wrote: post #30

Clean Code was one of the first books I read as a History student trying to become a self taught developer. From my point of view, coming from the rigor of historiography, the book was inconsistent and dogmatic. Still I took it as a replacement to talking with an experienced engineer, because that’s how it felt and most of the principles were fine when not taken to the extreme. But now in my career I’ve seen awfully…

I'm still amused by claims that the book is dogmatic when these paragraphs are in the opening chapter: > Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and prof…

If this verbiage is only in the introduction, it will not carry much weight. People, and especially IT people like rules, that you can indiscriminately apply.

Re: It's probably time to stop recommending Clean Code (2020)

#126

Post by ornornor »

KronisLV wrote: post #121
ornornor wrote: post #113

Earlier quoted context omitted.

I find that you can’t always fix everything. But the biggest hurdle is actually getting buy in (even if there is already buy in and that’s what you were specifically hired to do) Rewriting is tricky. It’s sometimes necessary (outdated and unmaintained language, obscure tech you can’t find people for, or sheer tech bankruptcy) but it can also not solve anything. As you implement the new version, you rediscover all the…

> As you implement the new version, you rediscover all the arcane business rules, edge cases, and sheer craziness that you didn’t know about and the rewrite ends up either lacking these or becomes The Mess v2 because you had to bolt all this weirdness on after the fact making the new codebase suck in a different way but overall as problematic as the one it replaced. Sometimes I wish we could just look at an implement…

> Can we simplify the domain instead?"

I can see this working in more mature and healthier orgs, but they’re a minority. As cynical as it sounds, most orgs are dysfunctional meat grinders where you’d get attacked for not having the skills to pull it off, in my experience.

Nobody brings this up for that reason and the madness continues unabated, ensuring the project becomes a slog over the medium/long term with the expectation that most will have moved on before it gets there.

This is also how we run our societies, leaving problems for later so that the next guy/president/generation has to deal with it at the point where it’s impossible to ignore anymore. Instead of much earlier when it requires much less effort and is reversible.

Re: It's probably time to stop recommending Clean Code (2020)

#127

Post by benj111 »

eurasiantiger wrote: post #94
ornornor wrote: post #86

Earlier quoted context omitted.

So… how do you deal with this on a personal level? How do you retain any shred of sanity or enjoyment from your work? I can’t stand self inflicted toil and the stress from constant firefighting which is invariably the result of these short term policies. It makes me want to quit programming altogether and work in something totally unrelated even though I love programming. Just not the way employers want it.

You stand up and talk about it publicly.

The issue is, managers want these things, like a nice code base, but are unwilling to pay for it. Or more correctly you have to pay most of the cost of that Hodge podge of hacks. So while they can off load that cost to you, why would they make an effort to improve the situation?

Re: It's probably time to stop recommending Clean Code (2020)

#128

Post by jacquesm »

userbinator wrote: post #57
jacquesm wrote: post #14

Earlier quoted context omitted.

> If a function is only called from a single place, consider inlining it. A compiler should do this for you. > If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that. This makes no sense to me. > If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters…

A compiler should do this for you. Unless it outputs source code, it can't.

From what I got the context he more or less implied a compiler due to the language used (C++). I know that's now how C++ started but nowadays I think you can assume that when people discuss ways to program C++ it is by using a compiler rather than a code generator.

Re: It's probably time to stop recommending Clean Code (2020)

#129

Post by leftbit »

DotaFan wrote: post #2

The amount of money I've spared to a companies by first learning the importance of Clean Code before I've tackled projects are immeasurable. Sure, Uncle Bob might be to opinionated and you might not like him, and some coding practices you might not agree with, and are indeed unnecessary today, but rules are important, and this is what we're missing today. Ground set rules, so everyone is on the same page.

> but rules are important, and this is what we're missing today.

Programming rules are important - they make you think before you break them. Just don't turn rules into dogma - otherwise your devs will be more concerned with following the rules than solving the actual business problems. And you don't want that.

Re: It's probably time to stop recommending Clean Code (2020)

#130

Post by john_the_writer »

eurasiantiger wrote: post #94
ornornor wrote: post #86

Earlier quoted context omitted.

So… how do you deal with this on a personal level? How do you retain any shred of sanity or enjoyment from your work? I can’t stand self inflicted toil and the stress from constant firefighting which is invariably the result of these short term policies. It makes me want to quit programming altogether and work in something totally unrelated even though I love programming. Just not the way employers want it.

You stand up and talk about it publicly.

And you're the first to be let go. The squeaky wheel that irks the bosses.
Post reply on HN