Bad code & high-risk places in your project
They say what separates a regular developer and a senior developer is that a regular one knows how o fix something and a senior developer knows if this something should be fixed.
In this article we’ll discuss what makes code bad and, more importantly, how you as a non-technical person can easily get the idea of what places in the project are really terrible.
Years ago when I landed my first job in software development I was surprised when I heard a dialog between the team leader and another developer. “I fixed that old bug about so-and-so. Please review it”, my colleague said. “No, we will not fix this”, team leader replied.
If you have experience in IT, you probably get the idea why he rejected that fix instantly. Because some things are better left untouched.
It’s like Terra Incognita, but without any spirit of adventures. It’s where people ruin their mental health, simple bugs take weeks to be fixed and minor changes cause the end of the world and, more importantly, your business.
Bad code
“Code without tests is bad code.”
— Michael C. Feathers
And he is sort of right. If the previous sentence got you triggered, before writing an angry comment please read the article till the end.
Some time in the future I’ll share with you the best excuses on why you don’t have tests, so that next time when your employees would ask you “why don’t we have tests?” you would be able to give them something more than just “it’s not the priority right now” and maybe even convince them that your project is the chosen one, the one what does not need to spend developer hours on writing some stupid tests (spoiler: no it’s not).
So, code without tests = bad code, huh? Then code with outdated or not maintained tests also equals bad code. Note that code with tests ≠ good code.
Now, since we’ve established that it’s likely we are all sinking in the sea of bad code, let’s answer some important questions. We’ll skip “who is to blame” though, because we already know the answer to that one, no need to remind.
Is the code without tests really bad?
Well, it depends. In a startup, sometimes (more often than I would be willing to admit) it’s more important to get things fast rather than super-reliable. So, is the code without tests ultimately bad? Let’s put it this way: “It could be better”.
Consider the following statement: “My BMW 3-series is not very reliable” — does this ultimately mean 3-series is a bad car? Wouldn’t it be much better if fuel injectors would last longer? Sure it would. It could be better.
Who am I to disagree with titans like M. Feathers?
Reasonable of you to ask. I like to think about it this way: books like “Working Effectively with Legacy Code” or “Clean Code” by Robert Martin are classics. They are good and give directions on what you should strive to get, not what you should immediately have in your project.
And there are priorities that dictate that this new feature that would help you secure a contract with this big corporate customer is slightly more important than the test coverage percentage, even if it is close to zero.
It’s like some generic statements “It’s bad to lie”. You agree with it but you’d better tell you 4-year-old that this picture he drew of you is very beautiful and you like it.
Why you do not have a map of all the bad parts?
A project always has some better parts and not-so-good parts. The not-so-good parts may be legacy of a developer who worked there 2 years ago or something that a freelancer you hired through Upwork for 10$/h had coded. Or even the work of a CTO of the company who would shamelessly claim it’s good (M.S., if you’re reading this, I’m talking about you).
It’s likely the developers on your project know the not-so-good places. But they will not report it to you if you’re not a technical person. More than that, even if you’re the CTO (in which case you must know about this places yourself), some of the following still holds true.
PRO TIP: Even if the code in your project is so clean you can eat from it, a good developer should be able to name a place or two where things should be improved. If they can’t… well, a good developer always can.
Suppose Bob sees a 10'000-line masterpiece of a class with the most brutal violations of DRY principles, code style and common sense. If the this mess screws up the estimates, then Bob will probably mention that to the manager, Alice. But what next? Will any of them create some list in Confluence or do anything other than updating the estimate? Why I bolded “do”? Because saying “Yes, we should refactor that some day” is not doing.
And this is what happens in most of not-so-good projects, i.e. those without some good management and processes:
Both Bob and Alice subconsciously understand that you’ll never ever refactor that 10K-line beauty.
So, Bob just adds one more crutch to the existing mess (Broken Window theory in action) and then tries not to remember about it ever again. That’s it.
There may be other factors that stop him from telling the higher management about the mess he found:
- Colleague solidarity
- He knows who wrote that code and knows that there will be conflict (good indicator of a healthy work environment, btw. More on office politics coming soon)
- He wrote that code
How to identify “bad places”?
Easy. Your CTO should know those. Ask him.
If you are a CTO yourself and you don’t know, well… The easiest way is to interview every developer separately. Just ask them (and yourself) what parts of the project you would not be comfortable working on. Point out you’re not looking to blame anybody but just trying to get the better idea of the current state of the project. Ask them to “stay in touched”: should they stumble upon some masterpiece like the one we talked about earlier, they should notify you.
PRO TIP: If you rotate your monitor 90 deg CCW and see a beautiful landscape and silhouettes of mountains in your code, then your code probably sucks.
What should I do with these “bad places”?
Option 1. Live with it.
“Maybe it’s not so bad? Let’s not touch that module, because it… it works? Yes, we have some bugs there, but man, we don’t have time for it now”.
Sometimes this is the wisest choice. Sometimes this works, and sometimes it ruins your business. This is a perfect short-term solution but may have terrible consequences long-term.
PRO TIP: If you choose this route, don’t forget to tell all your developers that you are planning a major refactor, that would purge all the heretics… I mean bad code, of course. The CEO of one project (with all due respect, btw) was a professional at this. Built on a framework version support of which was dropped about 2 years before I joined, the project was supposed to undergo a major migration to the up-to-date stack “really soon”. 18 month later, when I quit that job, it was still running the same old version. When I was writing this article I checked a few things, and guess what? Yes, same application (many changes and best practices implemented, new design, finally some React instead of improperly used Angular 1, but still same backend framework). 5 years is not enough to complete a migration, I guess.
Option 2. Bite the bullet.
Refactor. Pay the interest on your technical debt in full. If you’re looking for a technical partner you can rely on, write me at alex@xfuturum.com. Am I shamelessly selling my services here? Of course I am, and I’m really good.
Option 3. Migrate
Start anew. Fix all mistakes you made in the architecture, use the latest tech. More articles about that are coming soon. I’m trying to post weekly, so subscribe to see more. And yes, I am still available at alex@xfuturum.com.
Bonus: Endless cycle of migration.
You followed the Option 1 as long as you can, you thought you would ride that bad boy until the wheels fall off. And they did, you can not sustain that anymore. Your code consists of crutches and ad-hoc solutions (more on them — in next articles).
So, you decide to migrate.
And you do it. But you still keep rushing features and collecting that technical debt in a manner that would have your credit score decimated, be that real money. Some years pass and you still (or, rather, again?) have the same old issues, and the code is still (again?) a bunch of not-so-good things.
And then you migrate again.
If migration was reincarnation, then your project would have just got reincarnated into an abortion. Congrats.
Both Options 1, 2 and 3 are viable. Anybody who does not know the details and tells you that you should pick one of those options is full of the not-so-good substance, just like that 10K-line class that ti this day Haunts Bob, the developer, in his nightmares. Usually, they will try to sell you the entire migration because this is where money is made for outsourcing agencies. Also, it’s much more fun to build something new rather than fix old boring stuff.
Just don’t go for the endless cycle. For the love of God, just don’t.
On this happy note, I’d like to remind, third time in this article, that if you’d like me to work with you, feel free hit me up on Linkedin or drop me a line at alex@xfuturum.com. And if you feel like you’re going through the endless cycle, get some help.
Cheers!
