Two years gap

It's been more than two years between my two last posts on this blog. That's far away from my initial attempt to write one post a week.

It's not that I need to justify it, but I'd like to recall what's been going on in my life during this two years.

  • My first son and second child was born in April 2013. We are four, and we are happier than before.
  • I found a new job at Ericsson, as a research and development engineer. I joined the company in January 2012 and I'm currently playing a role as a technical team leader for a development team in SAPC.
  • I had and overcame cancer. I had a rare kind of cancer: liposarcoma. I got a fat tumor removed from my right armpit in February 2012, followed by 6 weeks of radiotherapy between April and June. I currently have regular reviews and everything is fine. According to statistics, the probability of the tumor coming back after treatment is 5%, and decreases along time.
  • I completed a Master in Software Engineering that started in February 2012 and ended in July 2013.
  • I learned about Coursera and its wonderful course offering. I accomplished the course Functional Programming Principles in Scala in November 2013.
The main reason for not writing any posts during this time is that I was too busy taking care of my family, my own health, my job and my training. So almost any spare time that I could spend using my computer at home was devoted to studying.

I hope I can write here regularly from now on, but one post a week is probably a too ambitious goal to meet. Let's see how I get by and go on with it.


The code protection smell

I like the concept of code smell. It recalls the idea of identifying something that you dislike, but cannot tell exactly why. You don't have a good reason, but just a feeling that it's wrong.

I recently found a new type of code smell at work. One of my colleagues - a highly skilled developer who I respect and enjoy working with -, told me he was taking a concrete design decision pursuing that other programmers could not later misuse it. He was implementing a C++ class hierarchy and he wanted to prevent others to freely instantiate objects using operator new.

We discussed technical options to achieve what he wanted but I had a weird feeling during the conversation. In the end I recommended him to discard the idea and simply don't implement what I then called a bad programmer protection. I call it simply code protection now. Second thoughts on the matter led me to identify a twofold kind of code smell.

First, it is a pure technical smell in the sense that you are writing code in order to implement what is not a business requirement. One may argue here that proper code formatting is not a business requirement but accepted to be good practice. Code readability might not be a business requirement itself, but it is important for maintainability, and that is (or should) always be a business requirement.

The other side of the smell is organisational. Even if you implement your design in a way that makes it hard for others to misuse it, you cannot prevent others to rewrite it in a way that protection gets nullified or just removed. So it is an indicator that you doubt about your co-workers capability and good judgement.