Code quality only matters in context (2019)
adamtornhill.com
Code quality only matters in context (2019)
1–10 of 78 posts
Re: Code quality only matters in context (2019)
#2(2019)
Re: Code quality only matters in context (2019)
#3This was a fun read for really personal reasons. The idea that, basically, bad code no one ever has to touch again is in fact good code, is in fact "better" in a true sense than carefully engineered code accomplishing the same thing, has been a really valuable guiding insight for me in my career. I couldn't remember where I got it though, or if it even had one single source.
Then when he shows the visualization I was like "hey that looks like the d3 script I got out of some git analysis book years ago and still use at every job I work."
It's the same guy! Looks like he productized the scripts distributed with that book, which nice. I'll definitely try it and push for places I work to pay for that instead of the bundle of customized scripts I've been dragging around for years.
I really endorse that book too! I read it at the right time in my career I think, where I had truly seen some shit and so had the experience to understand the value of that approach, but not so far in that I had become set in my ways.
Re: Code quality only matters in context (2019)
#4This was a fun read for really personal reasons. The idea that, basically, bad code no one ever has to touch again is in fact good code, is in fact "better" in a true sense than carefully engineered code accomplishing the same thing, has been a really valuable guiding insight for me in my career. I couldn't remember where I got it though, or if it even had one single source. Then when he shows the visualization I was…
So there is a script or something with the book that you can run on your Git repo to see a chart of the hotspots?
Re: Code quality only matters in context (2019)
#5This was a fun read for really personal reasons. The idea that, basically, bad code no one ever has to touch again is in fact good code, is in fact "better" in a true sense than carefully engineered code accomplishing the same thing, has been a really valuable guiding insight for me in my career. I couldn't remember where I got it though, or if it even had one single source. Then when he shows the visualization I was…
> The idea that, basically, bad code no one ever has to touch again is in fact good code
How do you know no one would ever have to touch that code again, at the moment of writing it?
Nevertheless, generally I agree that isolated complexity is much better than complexity that spreads everywhere through explicit or hidden dependencies (e.g. global state). So dirty complex code hidden behind a simple API is actually not bad code.
Re: Code quality only matters in context (2019)
#6I’m coming up to almost a decade of programming and have 100% bought into this mindset. Simple understandable code tends to be easier to change and delete. Abstractions and fancy features should have a high bar to introduce them. They can be useful, but is the cost worth it? Usually not, but sometimes it pays off 10x.
Perhaps if timelines for delivering software slows down this mindset will be less advantageous. But in today’s climate this ensures you have more time for design and testing.
Re: Code quality only matters in context (2019)
#7This was a fun read for really personal reasons. The idea that, basically, bad code no one ever has to touch again is in fact good code, is in fact "better" in a true sense than carefully engineered code accomplishing the same thing, has been a really valuable guiding insight for me in my career. I couldn't remember where I got it though, or if it even had one single source. Then when he shows the visualization I was…
> The idea that, basically, bad code no one ever has to touch again is in fact good code How do you know no one would ever have to touch that code again, at the moment of writing it? Nevertheless, generally I agree that isolated complexity is much better than complexity that spreads everywhere through explicit or hidden dependencies (e.g. global state). So dirty complex code hidden behind a simple API is actually not…
This is literally the 'O' in SOLID.
The key idea is to break code into "chunks" that each do one thing.
Then, if you have to add a new feature, it goes into another chunk, instead of editing/modifying existing code.
The same logic applies to system design at different scales, whether fine-scale OOP or coarser-scale (micro)service architecture. The ideal size of an individual "chunk" is somewhat subjective & debatable, of course.
It's like Haskell-style immutable data structures, but applied to writing the code, itself.
Re: Code quality only matters in context (2019)
#8This mindset is also true for many researchers who code.
Professional programmers make fun of research code but actually the dirty way is desirable considering that research is about prototyping, tweaking, and in small groups.
Re: Code quality only matters in context (2019)
#9I wonder if you can formalize this a bit more.
Let W(init,DC) be the initial cost (hours/effort) of writing Dirty Code (DC). Let's assume that the code works for the intended purpose and doesn't have any bugs.
Let W(init,CC) be the initial cost of writing Clean Code (CC). You'd expect it to be related to W(init,DC) by some proportion: W(init,CC) = (1+alpha)*W(init,DC).
Then there is a probability p that you will want to / extend the code.
Let W(ext,DC) be the amount of effort required to extend the code if the initial code is dirty.
Let W(ext, CC) be the amount of effort required to extend the code if the initial code is clean. I'd expect W(ext,CC) = (1-beta)*W(ext,DC).
Then you can compute E[W(total)|CC) vs E[W(total)|DC]. This will define some trade-off curve based on alpha, beta, p, W(ext,DC) and W(init, DC).
Lots of assumptions here, but I wonder if thinking this through will provide any insights. Obviously, if the probability of extending the code is low, then it always makes sense to write dirty code. If the probability of extending the code is high, then you'll want to write clean code.
Re: Code quality only matters in context (2019)
#10I was let go once for having too many commits in a PR. When we squash merged… I’ve come to the same conclusion about code quality. If it’s something that others interact with, make it polished. If it’s something only you interact with, make it commented.