This blog post has been making the rounds, and I have a bunch of problems with it.
The first issue I have is that the elision of the duplicated code in the examples means that we can’t draw any meaningful conclusions from the code.
If the code was present in totality then we could see *what* is being duplicated as well as see if there are any better refactorings that we could apply.
The second is that the drawn conclusion of eschewing clean code is not the right one.
This blog posts tells the story of choosing the wrong abstraction in order to make the code more DRY, but then concludes that clean code isn’t worth it and is just a “phase”.
This is dangerous thinking, and will cause some people to disregard important texts, such as “Clean Code” by Uncle Bob Martin.
@maxdeviant the problem is the adjectives give humans something to hang on too that is ultimately meaningless.
Every line of code is produced in an environment that is very difficult to reproduce. Clean Code is an example of environment where you have large code bases, endless budgets and huge teams.
Its a fallacy, code outside the environment it was made in and for, is just code.
@maxdeviant whenever I am asked to review code for some investor or ceo I always end up asking them so many questions related to their company and environment and history before we begin they ultimately change their mind.
@maxdeviant subjectively there is a style of code that I might appreciate more than others. There are ways of approching problems that may be objectively faster or safer but it isn’t often you find an environment with objectives like “this needs to be x fast and y safe and it will be tested for AND most importantly we will give up budget and features for”
@peregrine I think there exists some baseline for code quality that should be followed regardless of circumstances. Sure, there may be some things to compromise on dependent upon circumstances, but those should be things in addition to the quality baseline.
I say this as someone who has witnessed what happens when there is unbridled duplication (that is not incidental duplication) within a codebase. For example, there is no reason why there should be four copies of the same compression algo.
@maxdeviant it is very easy to say this but there exist several environments where this happens. For example microservices architecture this will happen. Or a team of junior devs who’s product got traction fast. Or a self taught programmer solving their own problem.
Code is not something that can be standardized in an ieee sense.
@peregrine I suppose that’s where we disagree then. I think that there are objective criteria that can be applied to code and that these criteria can be studied, taught, and standardized.
@maxdeviant comes with experience I think. I too used to think that.
@peregrine I’m not sure if you meant it to be, but this comes off as incredibly condescending.
@maxdeviant that is not my intent. I apologize and can see it now.
For example read this language and thread about the k langauge a variant of kdb a language/database used extensively in finance. Written entirely in this style. https://news.ycombinator.com/item?id=22009241
To me this is objectively bad and yet people defend it viciously.
@maxdeviant this comes from more a place of exhaustion over this fight in particular :P.
@peregrine Thank you for your apology.
And there's at least one thing we can agree on: I also consider that k code objectively bad 😄
@maxdeviant I felt like this was more about premature abstraction and being okay with "we can't abstract/clean this _yet_" but didn't quite get there in the article.
@ciel Yea, that certainly seemed like the place it should have ended up at. I think part of the problem is the clickbait-y title and the use of “clean code” without really qualifying it.
@maxdeviant why is that an important text? why is that dangerous thinking?
@cancel It’s dangerous thinking because the software industry as a whole seems to be moving away from software craftsmanship and technical excellence and instead towards hyper product-focused teams that couldn’t care less about the quality of the code they produce.
As for the importance of the text, I think it’s a good starting point, but not necessarily something that should be followed to the letter. Some of the views are a little extreme (like how short he suggests functions should be).
@maxdeviant @cancel I might be in a peculiar bubble, but I've seen the opposite :) progressively moving from places with terrible practices to places that care more and more about technical excellence. It takes time, but these end up being able to be hyper product focused THANKS TO the technical excellence (which I guess is the point of the post from Fowler you shared before)
@maxdeviant before we get that far, why should I care what this guy says about making software? As far as I can tell, he's never made anything notable (or even non-notable but high-quality.)
@cancel @maxdeviant looking at the original code, I didn't exactly see it as 'messy'. Repetitive for sure, but seems like—and maybe I don't know better—the author doesn't understand what messy code actually looks like ?
Messy is what I do, trying out a bunch of shit, toggling commends and console.logs to figure out why the fvcking thing doesn't work. Then I clean up when I somehow got it working.
@maxdeviant he's probably a totally nice guy. But I have no idea why I'm supposed to listen to him about making software.
@maxdeviant but he's never actually made software?
@cancel He definitely has made software, but nothing that has widespread name recognition. I'd imagine a lot of the software he has contributed to is all closed-source for the various companies he's worked at or contracted with.
You can see his work experience on LinkedIn:
@maxdeviant the consulting work here looks more like sitting in on meetings and talking to people.
To be able to write or give advice on something doesn't have a strict requirement that you have participated or been accomplished in a field.
But, I have no reason to just take it on faith that any of his ideas are good. There's no proof or anything. As far as I can tell, it's all made up. Which could be fine, if it were direct advice from someone very accomplished in a field. But he's not.
@maxdeviant You said that you wished people read this guy's books in order to fix the software quality problems that are are becoming more of a problem in the industry.
But it seems to me that the companies which churn out the mass quantities of low-quality software are exactly the ones following and switching to this Agile books and manifesto written by him (or equivalent figureheads.)
So I am very confused by this. And that's on top of having no idea why anyone is listening to them.
@cancel Well let's not drag agile into this, because that's a whole different discussion.
But I don't have any evidence indicating whether these companies are or aren't applying these methodologies. The only thing we have to judge them by is the quality of their deliverables, which, as I mentioned, are not impressive.
So I would wager that these companies aren't applying good software development principles, otherwise their software wouldn't be so terrible.
@cancel As for why you should listen to him, I don't think I have an answer that will satisfy you. But I'm curious who, if anyone, you would take software advice from.
@cancel Also, note that when I say "good software development principles" I don't necessarily mean the ones outlined by Martin.
I just mean if they were to apply *any* good software development principles that one would expect the quality to improve.
@maxdeviant @cancel the whole tone of that article seems to be "fuck it, don't bother trying to be clever because your boss will tell you to undo it if they don't get it" which seems an odd take. Surely someone with those credentials can actually turn it around and explain why it makes perfect sense to do it they way they did ?
But using "I chose the wrong abstraction" as motivation for saying "don't bother with clean code" doesn't seem like a logical conclusion to reach.
Which is why my main problem is that the examples are lacking the *actual* duplicated code, because now we can't even discuss what a more appropriate abstraction might have been.
@maxdeviant I've yet to see anyone discover or demonstrate any principles or dogma that work. People come up with these things all the time and there's a constant churn to use some new dogma or set of guidelines or manifestos or principles or whatever, and none of them are ever shown to work.
@cancel I just don't see how this sort of thinking can scale to training up new developers.
Unless we have some semblance of what qualities make for good and bad code and are able to identify and discuss these qualities how can we expect to teach them to beginners?
Take something like referential transparency, for example. We can say that referentially transparent code is easier to reason about because it is deterministic and has no side effects.
@maxdeviant > Unless we have some semblance of what qualities make for good and bad code and are able to identify and discuss these qualities how can we expect to teach them to beginners
That seems to be a huge problem, yes. And I don't think any progress has been made on it.
> Take something like referential transparency, for example. We can say that referentially transparent code is easier to reason about because it is deterministic and has no side effects.
Ackermann function fits that....
@maxdeviant even with mathematical complexity explosions aside, you can write "pure" code that is ridiculously complicated and that nobody can understand. Just look at the trash people make with C++ templates or Haskell monad transformer stacks.
@cancel Hence why we need other properties like "readability" or "understandability" to weigh things like "purity" against.
Like I might not mind having some monad gymnastics in a foundational library that is fairly static and not many people have to change, but you probably don't want to have that same level of complexity in your business logic that changes all the time.
@maxdeviant I worship at no church
@maxdeviant @cancel I don't really like or care about Fowler / Martin btw. Even if they have some good stuff, I prefer getting advice from people closer to me, that I work with and trust. Software engineering is such a large topic it often feels like it's different worlds, and not all advice applies everywhere.
In my case I was fresh out of university and thrown into an environment where the approach to software development was stuck some twenty years in the past.
If I had taken their advice and not sought out external opinions I am certain I would have fallen victim to the awful practices that were already in place.
Perhaps that makes me have a natural affinity towards them as they're really the first people who gave concrete advice on how to improve the quality of my code.
Would a colleague mentoring me have been preferable? Certainly. Would they have given me more balanced advice? Perhaps.
@maxdeviant He's not saying that clean code is a phase, he's saying that obsessing over clean code is a phase. I would tend to agree about that. There's many other things to care about when programming, it's a balancing act.
@electret In my experience, unless you have someone who obsesses (or at least cares at all in the slightest) about clean code and code quality then the codebase atrophies.
Maybe this is an endemic problem at my work, but maybe not.
The bottom line is that maintaining a high quality codebase enables you to move faster in the long run, at the expense of a slightly higher initial cost:
@maxdeviant I strongly agree about the "maintaining a high quality codebase". But it's been more effective for me to build that into the team culture than having one person obsessed about it. I think that's what was the main point of that blog post. Also, code quality != clean code. Testing, code structure, documentation, team culture and practices also play into code quality. And it's much easier to have high code quality when it's a team effort and not one person gatekeeping.
@maxdeviant I have to say tho, I've seen places where the approach you're mentioning was the only one that worked, which is unfortunate :(
@electret You’re very right about high quality being more than just clean code.
Unfortunately, at my work we have no automated tests, no documentation, poor code structure, a culture of copy/paste coding and quick hacks, and an adherence to a horrendously outdated style guide.
These are all things that I’ve been working incredibly hard to fix over the past six years at the company.
@maxdeviant It's hard work to change these things, and sometimes even if some engineers in a team know what to do, they can't get enough traction to achieve it. Before Christmas I went to a new client that lacked good testing practices and spent most of the week to guide them through it before moving on to anything else. Something that can be a good first step is to set up a basic CI. Building on top of that slowly and getting people into it :) Once you have CI + test, clean code can follow :)
@maxdeviant I agree. With code, "clean" is actually quite tangible and defined. And it's not a synonym for concise, abstract, or DRY.
They almost seem to conflate it with the term "clean" in graphic design, which means absolutely nothing.
Merveilles is a community project aimed at the establishment of new ways of speaking, seeing and organizing information — A culture that seeks augmentation through the arts of engineering and design. A warm welcome to any like-minded people who feel these ideals resonate with them.