Twelve Ways to Make Code Suck Less

Tuesday, November 22, 2016

This year, I was one of the lucky developers that got to go to the biggest Java community get-together in the country, Devoxx.

Twelve Ways to Make Code Suck Less

The first talk I attended was immediately spot-on and of very high quality. In this blog, I will focus on this talk as it was easily the most interesting.

Venkat Subramaniam was one the best speakers at Devoxx this year, so I wouldn’t want to miss it. His talk “Twelve Ways to Make Code Suck Less” was very popular among the Devoxx public.

Venkat very politely had put off his shoes and gave his subliminal talk on his white socks (literally).


He began explaining the purpose of good code quality. Good code quality is very important if you want to be agile in your project. The first law of programming says: “Lowering quality lengthens development time. Poor code slows you down, as you spend more time trying to understand the code.

Venkat has gathered twelve ways that can help us, Java programmers of all ages, to make our code suck less. I will discuss his most ingenious points.

Just like our financial debts, we have to be aware of our ‘technical debts’. Technical debt for example, are deprecated methods, or libraries that are not performing and not having time to fix this. Not low quality code though, that’s just sabotage! The code becomes very hard to maintain after a while. It’s what makes developers leave the project or not want to get hired on the project. To manage this, we can plan in extra time, maybe 10% of the time, into the sprint, to pay the debt and not only develop new stuff or fix bugs.

Besides paying technical debt, we can also schedule “slack time”. This is a time slot where we can take a breather and think about new innovations we can build into the project. Venkat gives a nice metaphor for this: during the evolution of civilization, people went from being savages and hunting for food to becoming (mostly) civilized and using agriculture. The use of agriculture gave people free time, which they used to create art and music.

Favor high cohesion and loose coupling. Cohesion means putting alike things together and unalike things apart. Obviously, putting business logic in the GUI is a bad idea. This is basically what we all learn in school. But why? We want to increase cohesion so we can decrease the complexity of change. This allows us to change the code at a much smaller cost. That’s why we “modulize” things and make sure we avoid making methods super long. We also want to reduce or eliminating coupling. Tight coupling makes our software hard to test, because we have to start mocking all our dependencies.

“Good code should read like a story, not like a puzzle.” When your business analyst asks what a piece of code does, you should be able to talk to them and say: “Look, this is what we do, step 1, step 2 and so on”. The business analyst should then think: “Ok, this was easy to understand”, not trying to figure out what it does, when in the meantime we have production code to release. This is where functional programming become very handy. It allows you to replace lengthy, complex, imperative style code with less and easy-to-read code.

We need to be aware of and avoid “primitive obsession”. This is when we write complex code and feel good about it, petting yourself on the back, because it was difficult to do. But actually, maybe you could have just used one method from the JDK instead of all the complex stuff. So, instead of trying to be clever and write complex code, stop, and write clear code instead. This will avoid a lot of annoying bugs!

“There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious deficiencies.” – Tony Hoare

Let’s talk about the controversial topic: “comments”. Some of us like to insert comments whenever we can, while others just can’t even be bothered. Personally, I try to comment as much as possible when I feel like another programmer will have a difficult time understanding the functional aspect of the code. Venkat explains his opinion very well. We want to know why the code is there, not what the code obviously does. The code should by now be like a good joke; it shouldn’t need comments explaining the joke, you’re just covering up your bad code! The code should be self-documenting; choose well-chosen, meaningful names and use the comments to describe its purpose and constraints.

Code reviews can be very politically charged. But, by consistently doing them, you can remove a lot of errors by proactively reviewing the code. Don’t only review the code, but the tests as well! We can rotate the reviews around the team so your code is not always getting reviewed by the same person. This is called “tactical code reviews”. In my experience, code reviews are not always taking seriously. People sometimes perceive it as being an administrative job, something that had to be dealt with. Venkat says you need to convince your team about the advantages of code reviews, that you can learn a lot from it. In my first years of programming, I worked in a big team, with lots of experienced programmers. We did code reviews all the time and the more experienced programmers would constantly tell me what I can improve. So, I’m definitely a big fan. But, the goal must be to tell people what they can do better, not to slap them in face when they did something wrong!