Bad Code
We watched the video If Your Code Looks Like This… You’re A GOOD Programmer by Dave Farley.
Farley describes bad code as
- Doesn’t Do it’s Job
- Hard to Change
Which means that good code does it’s job and is easy to change. Everything else falls under these two. Details of ‘good’ depends on context.
They use this simplified definition because it’s practical: Code that does it’s job and is easy to change produces results (which means money, Dora 2017 found out that high-performing organizations spent 21% less time on unplanned work and rework and 44% more time on new work).
Managing complexity is essential in programming, and often readability is listed as an important factor. Farley notes that readability should mean that almost anyone can understand the code (with some help if they are not technical).
Farley concludes that in general, preferring testable code is beneficial (in managing complexity, but also otherwise): it tends to have more good qualities (like being modular, cohesive, having good separation of concerns, reasonable coupled, does abstraction / information hiding).
I think we can wholeheartedly join on Farley’s wish that more people would defend good code against misguided pressure to cut corners. We have all felt the struggle of working with code that is just not good.
Comments
I like the practicality and a bit more higher level definition of bad code. More often than not these kind of definitions go way too deeply into the details, listing things such as how long a function should be, that are also very much context dependent. Giving these kind of definitions might even be unproductive when they are followed too literally.
Oh yes, at least I remember I used to struggle with these definitions when I had less experience writing code. Like, ‘small functions are easier to read, split them up if they go over n lines’. You might get carried away with that kind of rules. Who am I kidding, I still struggle with these.
Bad Code
I like the practical nature of this definition of bad code: It takes the focus to outcomes. Farley is also conscious about the fact that what qualities the code should have is somewhat context dependent. Same as with processes, it’s too easy to start arguing about the details with very limited practical utility.