5 ms·

The thing that bothers me about conversations in opposition to "best practices" or "clean" code" is that it misses the pragmatic aspect of those concepts. WHY

The thing that bothers me about conversations in opposition to "best practices" or "clean" code" is that it misses the pragmatic aspect of those concepts. WHY do we write clean code? Because the value of software is its ability to CHANGE. Otherwise we would stick with fixed circuits. Best practices and clean code don't exist in a vacuum and they are not floating abstractions that developers should throw around as if everyone is on the same page with respects to what they mean. They are a set of quality standards that allow for the rapid development, adaptability and ease of maintenance as a codebase evolves over time. Clean code does not exist to slow or hinder development, or to handicap junior developers. It exists to maintain a team's velocity as the scope and scale of the project increases. Clean code is one of the crucial tools in the toolbox for avoiding death march projects. It it is not the only tool: an efficient management process, feedback loop, QA cycle, deployment process etc. are all critical as well. It is a team effort and code quality is the part that rests directly on the shoulders of the developers. The one and only part of the blog/article that I agree with is the part about refactoring without making it a teaching moment for the dev who wrote it. That part implies they weren't doing code reviews, another crucial element in the quality control of the product being developed. It blows my mind that these conversations are so often misunderstood. Us old timey senior devs have a professional obligation to make sure that the younger generation understands these concepts. Why do we see so many trendy medium articles and blog posts that seem to want to throw decades of hard learned lessons out the window? I blame the older generation for failing the younger ones. This stuff is not self-evident and has to be taught.

superjan 5y ago
In the article the author said that his “cleaner” version had less duplicate code, but was harder to adapt to new usecases. His point is that clean looking code is sometimes harder to change, because while cleaning people introduce abstractions or assumptions that hinder new usecases rather than facilitating them. The right way to keep code maintainable is not always self evident, and not necessarily always clean (which I interpret as SOLID, deduplicated).
- gspencley 5y ago
  I didn't miss that, I just chose not to address it for brevity. The problem that highlights is both a process and an experience problem. It indicates that he did not have a clear picture of the development road-map for the project, which suggests there are silos of information. There were a lot of hints about this actually. The lack of code reviews (that's where the original dev's opportunity for quality improvement should have been caught and addressed), the fact that a manager would chastise him for trying to improve code quality and the fact that he made poor design choices when trying to improve said quality really does point to a dysfunctional process. Pointing the finger at code quality here is failing to understand the difference between the trees and the forest.
- V-2 5y ago
  His example makes perfect sense... when the "naive" implementation duplicates stuff over 100 or 200 LOC. I've had joyful experience of working with duplicate code that spanned over multiple thousands of lines. I still fondly remember a PHP script generating multiple xml files, supporting different versions of format. (It was an e-commerce format for exporting and exchanging products data). And with multiple inconsistencies among this copy-pasta that have accumulated over time. The problem here is the boiling frog syndrome. Duplication rarely starts with thousands of lines. It grows over time, and the longer you put up with it, the harder it becomes to roll it back. But as long as it grows slowly, the frog feels comfortable. Clean code approach may get overzealous, the potential for fanaticism may even be sort of inherent to this approach (I agree), but it stems for acknowledging this simple, sad truth. The truth is that complexity of naive code is kind of like cancer. If you don't detect it before it actually begins to hurt, it's not great news.
discreteevent 5y ago
I'm from the older generation. I don't agree with a lot of what's in clean code. Particularly the focus on micro unit tests. Nor do I like the moralising tone of the books author in general. Also flexibility comes at a cost. A codebase where everything is easy to change becomes complex in aggregate, such that nothing is easy to change.
- gspencley 5y ago
  Don't confuse Robert Martin's book "Clean Code" with the broader concept of clean code. "A codebase where everything is easy to change becomes complex in aggregate" What you're describing there is a code smell that is commonly referred to as "Speculative generality" and was written about in a book by Martin Fowler called "Refactoring, improving the design of existing code." Which, incidentally is a great companion book to Robert Martin's Clean Code. Speaking of trendy medium articles, here is one that I wrote on the concept of clean code that might help better understand what I mean when I use the term: https://medium.com/@gspencley/what-does-clean-code-mean-anyway-472b559ee620 https://medium.com/@gspencley/what-does-clean-code-mean-anyw...
DeathArrow 5y ago
Overly abstracted code can be difficult to read, comprehend, maintain and reason about. Thousands of small methods spread through hundreds of FactoryFactoryFactories and Builders and Adapters and Visitors can become a maintenance nightmare.
- gspencley 5y ago
  Overly abstracted code, or code that is a maintenance nightmare, is not clean code. It's almost like you didn't even ready my comment, or completely glossed over the "why do we write clean code" part. Clean code is code that is easy to understand and maintain. If you're describing the opposite then you're not describing clean code.

superjan 5y ago

In the article the author said that his “cleaner” version had less duplicate code, but was harder to adapt to new usecases. His point is that clean looking code is sometimes harder to change, because while cleaning people introduce abstractions or assumptions that hinder new usecases rather than facilitating them. The right way to keep code maintainable is not always self evident, and not necessarily always clean (which I interpret as SOLID, deduplicated).

gspencley 5y ago
I didn't miss that, I just chose not to address it for brevity. The problem that highlights is both a process and an experience problem. It indicates that he did not have a clear picture of the development road-map for the project, which suggests there are silos of information. There were a lot of hints about this actually. The lack of code reviews (that's where the original dev's opportunity for quality improvement should have been caught and addressed), the fact that a manager would chastise him for trying to improve code quality and the fact that he made poor design choices when trying to improve said quality really does point to a dysfunctional process. Pointing the finger at code quality here is failing to understand the difference between the trees and the forest.
V-2 5y ago
His example makes perfect sense... when the "naive" implementation duplicates stuff over 100 or 200 LOC. I've had joyful experience of working with duplicate code that spanned over multiple thousands of lines. I still fondly remember a PHP script generating multiple xml files, supporting different versions of format. (It was an e-commerce format for exporting and exchanging products data). And with multiple inconsistencies among this copy-pasta that have accumulated over time. The problem here is the boiling frog syndrome. Duplication rarely starts with thousands of lines. It grows over time, and the longer you put up with it, the harder it becomes to roll it back. But as long as it grows slowly, the frog feels comfortable. Clean code approach may get overzealous, the potential for fanaticism may even be sort of inherent to this approach (I agree), but it stems for acknowledging this simple, sad truth. The truth is that complexity of naive code is kind of like cancer. If you don't detect it before it actually begins to hurt, it's not great news.

discreteevent 5y ago

I'm from the older generation. I don't agree with a lot of what's in clean code. Particularly the focus on micro unit tests. Nor do I like the moralising tone of the books author in general. Also flexibility comes at a cost. A codebase where everything is easy to change becomes complex in aggregate, such that nothing is easy to change.

gspencley 5y ago
Don't confuse Robert Martin's book "Clean Code" with the broader concept of clean code. "A codebase where everything is easy to change becomes complex in aggregate" What you're describing there is a code smell that is commonly referred to as "Speculative generality" and was written about in a book by Martin Fowler called "Refactoring, improving the design of existing code." Which, incidentally is a great companion book to Robert Martin's Clean Code. Speaking of trendy medium articles, here is one that I wrote on the concept of clean code that might help better understand what I mean when I use the term: https://medium.com/@gspencley/what-does-clean-code-mean-anyway-472b559ee620 https://medium.com/@gspencley/what-does-clean-code-mean-anyw...

DeathArrow 5y ago

Overly abstracted code can be difficult to read, comprehend, maintain and reason about. Thousands of small methods spread through hundreds of FactoryFactoryFactories and Builders and Adapters and Visitors can become a maintenance nightmare.

gspencley 5y ago
Overly abstracted code, or code that is a maintenance nightmare, is not clean code. It's almost like you didn't even ready my comment, or completely glossed over the "why do we write clean code" part. Clean code is code that is easy to understand and maintain. If you're describing the opposite then you're not describing clean code.