Reducing Code Quality Costs Money Shitty Programming
I spend more time reading code then writing code. Uncle Bob has told us that we spend 9 times longer reading code then writing it. I can vouch for that.
When I jump into a code base I’ve never seen before I have to read to understand what the hell is going on. It maybe a simple change. Something someone more experienced with it can jump in easily and say “Hey, just change it here and there, then over there.. Oh don’t forget, there’s this weird thing that will blow the world up if you don’t check for this”. So it’s safe to say you want to get a lay of the land before you start shifting code around. It’s like the saying goes.
If you don’t know where you are, you’re lost.
What happens when the code you’re trying to read is impossible to comprehend?
When there’s 1000’s of lines of code with interfaces, configs and classes to navigate. Connecting the dots is difficult. You have to read code, figure out how it works and remember it. Sometimes it’s a lot. This is made doubley worse if the code is written poorly (or should I say quickly?) or read at an obscure hour. Tired anyone?
Code should be written like a book. Things should be structured so they make sense and are easy to understand. Chapters, formatting, tables and even spelling should be considered for the next poor soul who will inevitably tread your path. They will have to read your code. As many programmers will tell you, that person will probably be you.
I raise this topic as I recently had a discussion regarding the order of a method that had a signature:
GetFromTableStorage(string rowkey, string partitionkey)
This seems innocent enough. However, if you’ve ever used Azure Table storage before (particularly their emulator tool) or even their own Assemblies you’ll recognize something.
The order is always “Partition key” > “Row Key”.
It seems logical to keep it this way in your code as well. You may think, “well there could be a reason for that” and you’d be wrong. In-fact, there is absolutely no reason for the order to be changed. To add fire to the flame, the inputs are both strings.
When little old me comes along to use the method under some kind of handicap (lets go with lack-of-sleep). I see the method (note in my code base you’ll find it the correct way as well) and quickly assume that the order is “partition key” then “row key” and continue on my merry way.
Because that’s the convention.
Only it wasn’t and it caught me out twice!
I forgive you if you believe I’m stupid. It’s a simple mistake, but it happened. If I’m your average programmer, then chances are others will get caught out too. It took me, both times, 2 hours to locate and fix my mistake. Totaling 4 hours. Multiply this by the number of people who also work on this (10 or more in this case) and you just have a recipe for disaster particularly when the fix is really simple.
Swap the signature around.
It took me 1 hour to fix. Three hours less then correcting the mistakes. It was longer to run my tests then to swap it using ReSharper. I did have to change a few other parts manually. But the frustration and errors it may potentially solve is much, much greater. I only bring this up because one solution brought up was simply:
“Remember to flip it!”
I know! I got caught out once and I should’ve remembered. But I didn’t! In this world of information where things come and go so quickly. I can hardly remember when my haircut appointment is or when I last watered my plants. I’m in such a rush trying to pack everything together, move house, cook dinner, talk to my partner. You can forgive people for their mistakes or simply avoid it all together and fix the problem.
Then again, it’s funny because once people get used to “flipping this method” then when you change it everyone who used to flip it is now wrong. So we’re at a stalemate here.
It’s a zero-sum game. The best thing to take away here is to always code to convention and if you see something, change it immediately. I feel like a lot of people are too scared to change things and instead just copy and paste what the last person did. That way, you can never get in trouble because you can always blame the last person and say.. Well, they did it like that.
Oh dear, now I feel like there’s no excuse but to flip that method. The problem is, this is a difficult thing to justify to someone. Especially when you have much more important things to deliver (eg, the actual function that you were using that method for). Is it really that important or should we just “remember to flip it?”.
As a developer my number one priority is the code. That’s what I’m responsible for and the well-being of my fellow developers who will eventually read and work it. I am not going to sacrifice the quality of my code or someone else to ‘deliver’. Perhaps on a smaller project you can get away with a few shortcuts. However, the increase in bugs and mistakes and the cognitive overhead to fix them is enough to persuade me to fix such a problem and persuade those higher up the value of quality code.
If developers take pride in their code and enjoy their time instead of rushing things, we will have a better solution. This will make software more expensive. Before starting any software project we need to make sure that it’s one that’s worth it and will benefit others. Because it’s the root cause of these problems and unfortunately it falls onto the people below.
Let’s look at ways to reduce Cognitive Overhead in code in our next post.Category Blog