'Clean Code' is bad. What makes code 'maintainable'? part 1 of n

In my "Top 10 Software Developer Books" video, there was a lot of discussion about "Clean Code."

It's horrible. It's based on flawed assumptions, and it makes code harder to maintain. In this video I'm going to talk about some specific examples that Clean Code gets wrong, the workflows it prevents, and a bug that took me days to find that Clean Code's STUPID recommendations can cause.

I'll also discuss what "maintainable" really should mean.

There's no way I can cover everything wrong with this book (or everything you need to know to write maintainable code) in one video - so expect more of these.

00:00 Most "clean coding" advice is bad
01:24 "Clean Code" is trash
02:13 Thing like "Clean Code" only serve to create arguments
02:42 "Maintainable" is judged by people other than the programmer writing it
03:25 "Maintainable" code is useful when you do something else for a while and then come back
03:35 Code is not read top to bottom like a book
05:13 Real programmers read code from the bottom up
07:00 "Clean" codebases tend to obfuscate bottom-up reading
08:43 Vertical slices of code
09:40 Root of much programming advice
10:09 Welcome to Whack-A-Mole
11:38 Specific Example - Real Bug (details changed, yada yada)
14:26 The bad assumption in most coding advice: Bugs are preventable
15:28 A bug that's hard to reproduce means the code is bad
16:43 The real point of maintainable code
17:11 Rant
17:55 Wrap up

[TitoSpadini]

"No code is perfect. The point of maintainable code is not to write code that can't have bugs. It is not possible to write code that can't have bugs. The value of maintainable code is writing code so that when the bugs happen, and they will happen, you can find them, and you can fix them, and you can write tests to make sure they do not pop up again."

Somehow, was so satisfying to listen to this.

[pwalkleyuk]

Its an old T-Shirt, but "Always write your code as if the person coming after you is a violent psychopath who knows where you live" comes to mind.

[jacksonstone]

His description of finding a string somewhere in the codebase and working your way up, lines up 100% with my day to day. Polymorphism does screw it up. Happy to know I'm not the only one that starts every problem looking for some string in the codebase :D

[samgoodwin]

Write simple functions. Keep things together. Avoid premature abstraction. The end.

[XxXuzurpatorXxX]

The underlying problem with all the 'advice' books is that those assume that by following certain practices a good product is going to emerge almost magically. It is as if we expected that pushing bolts and rivets in a specific way and aligning beams in another way would allow to build a bridge without ever seeing one. Call it 'clean engineering'.

[bobweiram]

I've rewritten several C# and C++ code in Ada and it changed the way I think and write code. It forces you to think really hard about your program's specifications. Before you can write a single line of executable code, you model your data structures in terms of types and their values. In turn, those values have constraints such as ranges, precision, number of bits, etc. Those types are grouped into "packages" and are included with your functions and procedures.

When properly specified, it becomes very hard to write buggy code because the compiler checks your values at compile time and or runtime. The common fence post error and buffer overflow bugs simply don't occur when your types are properly specified. Those same constraints also serve as metadata, allowing the compiler to perform optimizations that would be impossible in other languages. The efficiency rivals C and C++ in speed and size.

The resulting code is incredibly easy to understand and maintain, since it has a Pascal-like syntax and its specifications are built-in. You can revisit your code months later and immediately resume where you left off.

[HairyPixels]

I'd pay to see you debate Uncle Bob on clean code. Make it happen!

[drewsclues]

This makes me want to write a blog post on software craftsmanship

[livb]

16:44 "The value of maintainable code is writting code so that when bugs happen (and they will happen) you can find them and you can fix them (and write test so they don't happen again)"

Loved this quote

[sanjaykrishnan]

Wait, I dont get it. In the last clean code example you were referring to, it's suggested to add the "special case" to the Expense class, instead of checking for the exceptional case outside it, why does this break the whole "don't make whack-a-moles" thing you mentioned? What's wrong with checking the private implementation of that class? If the error is in the expense amount, isn't it natural to then go check how that amount is calculated? Honestly, this entire thing sounded like someone who has a bunch of shit to vent, and just finding any excuse to vent.

[baldflyboysts]

Three minutes into the video, and you stated one of my guidelines of coding,
"Write code as if you will need to come back in six months and maintain the code." Most likely, you will not remember all of the details, and, most likely, you will be tasked to maintain the code since you are one of the last people remaining people who created or modified the code.

[moonbiscuit]

So true - supporting code in production has beaten out of me any intent of doing fancy abstractions and depth.
I hope you continue to speak to this in plain principles.

[slmsnper]

I strongly identify with the idea that a software team should limit the set of "things" that create meaningless arguments. Clean code rules certainly fall in that bucket. And I totally agree that applying clean code on any appreciable scale on a real large codebase leads to disparate and hard to understand code. Clean code is part of a set of coding advice (possibly stemming from OOP in my opinion) which advocates for an approach, which is doomed to fail because one does not infact understand the true nature of the problem at the outset (if indeed ever). This is a lesson I had to learn after being a clean code, abstracting zealot.

HOWEVER, the opposite end of the extreme is also a problem. I've seen code written by senior devs which gives no thought to structure at all. This is code consisting of huge functions, where logic for new requirements is just tacked in the middle somewhere, without thinking if this is a well defined business rule or process or invariant which should be pulled and out and shared with an existing usecase. Then one gets bugs where business rules are not being applied consistently. This is still better than lots of little functions, because it is easier to trace backwards (or use a debugger and trace forwards) through big functions, but it is not ideal.

Perhaps the ideal "book" is one which looks at the problem from both extremes, and explains why there are not hard and fast rules but rather tools in the toolbelt: sometimes you use a hammer, other times a screwdriver. But I also can't help but wonder if the only way one learns is through experience and a bit of humility.

[jimmiejohnsson]

True indeed. Separation of concern is very important and a major pain to deal with. Another common one I see is over-engineering/future proofing, large amounts of classes and concepts that are there for future ”what ifs” that never comes but now that code needs to be maintained. Its such a classic programmer thing to do, cant just solve the issue at hand but need to build something fancier that the next set of developers will have to deal with. Also having more than one way of doing something, usually a nightmare and unless it is absolutely needed to support both ways its not worth it. Another one is premature optimization, kind of falls under future proofing. But lots of devs love to do ”smart” things in the name of performance. In the end, the actual performance issue customers face are somewhere else and the cool optimisation is never useful only prone to errors and a nightmare to maintain

[yevhenorlov]

Great video. A little bit of feedback on the editing: personally I found the "morph" cuts very distracting, I think simple hard cuts work better.

[InfiniteQuest]

Thank you. I'm pretty sure you're the only person on the internet who has programmed. I've argued with so many people about the topic of how people get started. They always say it should take at least a month of a developer getting paid full time to sit and read through the entire codebase to understand it before they can ever make a single commit. And I'm always like what are you talking about. Someone is going to give you a very specific problem that you can usually find within an hour (yes, I'm being generous here) and in any sane environment, you've probably committed something on the first day.

[herberttlbd]

Dijkstra's complaint was about the lack of locality; GOTO was just the tool that was most used to harm it. Tpday's code design principles are the modern day equivalent to GOTO.

[KevinMoturi-lz]

I thought he was going to discuss the limitations of the actual principles of clean code but all it was is a vague critique of scenarios that are more related to just poor code writing in general not an issue with something like polymorphism.

[Zayelion]

How i explain wacka mole is ... "seperating the puppies does not mean cut the puppies into little pieces and give me all their paws. Its the same with code" this mental image is mortifying and gets the point of what something being "whole" means.

[robosergTV]

wow thanks! As someone who now has to deal with a badly written legacy code this video series is gold!