If-problems and removable code

– Hey Markus! Come over here and see what I have done!

I paused my debugging session and took my chair and rolled over to my much older colleague.

– What awesome thing have you done? I asked.

– Look, I have made an interface for our new hardware device. I made it as a separate solution if we need to use it in another codebase. It can take different connection types, for example if we need to connect over IP in the future. And I also made a cli tool, if we need that.

– It looks super nice! I said.

But I don’t know if I actually thought it was nice. Not that it was bad, I just didn’t know what kind of code I thought was good code, all code was gray to me. Good in some way, bad in another way. Just like I never have had any favorite color or favorite food. I had no idea what kind of code I thought was important when it comes to code structure.

But this time it was not of importance how the code was written. Whatever I thought about it I would had said it was awesome. We were a new team and building the team spirit was way more important at this time.

After listening to my colleague and confirmed his enthusiasm, I rolled back to my desk and resumed my work.

Time went by, the hw device laser went end-of-life and we got a new replacement model. Now it was time to integrate a new device to my colleague’s interface. There was only one problem, it was not IP based, nor serial or normal Bluetooth. It was Bluetooth Smart. A complete different API which was fundamental different from my colleague’s interface. Sadly, we had to partly remove the code and make a new interface. The solution separation that could solve problems ended up causing problems in our build chain so we removed that too. Regardless of all problems he had foreseen it couldn’t solve the next one.

Everything should be made as simple as possible, but no simpler

I have heard it many times before, sometimes it is called agile or lean, other times it is a quote that is attributed to Einstein. I call them if-problems. Young ambitious developers come to to me and ask for help about a problem, a problem we do not have to solve - an if-problem. Often fixed by a minute of actively listening about why they feel that they need to solve that problem now.

But there is one more important lesson here… my favorite color.

I argue that you should do the opposite of if-problems in code structure, instead of “how to extend the code if something is needed”, you should code like “how to remove the code when it is needed”.

It was not just my older colleague’s code we had removed and replaced over the years, a lot of my and my colleagues' work in the 20+ year code base was to remove code and replace it with something that solved our new problems. My coding style was converging to this:

“Did I leave comments after me that explained dependencies so they could easily be removed?”

“Did I make tests so someone could remove and replace my code easier?”

“Did I make minimal dependencies between code files so when removing my code, one do not have to do it over the whole codebase?”

I also noted that many popular code philosophies (but not all) come natural from this, but now they have one simple, common goal. A common rule that united them when they were in conflict.

Today I have two philosophy rules that guides me in producing and reviewing code:

• What to code: Solve only your problems at hand - don’t solve if-problems.
• How to code: Make your code easy to remove.

There is of course never one simple solution or philosophy to a complex problem, like code structure. But for the time being I whish to explore the limits of these ideas and get to know them even better.

// Markus