Nothing Missing, Nothing Broken, Nothing Out Of Place

An Essay About Software Engineering

Image generated by DALL-E

This week is the 14th anniversary of the death of my grandfather. It is a special bond we have with our grandparents, isn’t it? Certainly different from the ones we have with our parents. One thing I remember is how tidy my grandparents’ houses always were. When discussing this with my mom, she mentioned a principle she heard once:

Quote

Nothing Missing, Nothing Broken, Nothing Out Of Place.

I Google’d the source of this, but couldn’t find it easily; it’s likely tp be from some abrahamic religious text. I think it’s a good principle for a family home, to be sure; but also it just sounded really good for software engineering.

Nothing Missing

A very common thing that happens to me in software projects is to find myself using the wrong technology to solve a problem.

  • Trying to use a no-sql database for a queuing system?
  • Trying to use a relational database to stream data?
  • Trying to use a distributed file system as a data storage that needs to be queried?

As we get more senior we are more likely to have to rescue projects. We land on these projects where bad decisions were made a couple years ago, and now it became unsustainable. Or, as I like to say it, we have to replace the engine while the train is running.

When is the right time to raise your hand and start doing the right thing? When are we allowed to trump an organizations toxic patterns and create a new, healthy one? The time is now, as soon as you realize it. Before the project, during the project, or after the project. The compound benefits of using the right tools will far outweigh the cost of the change.

Nothing Broken

This one is a classic, we even have a term for that: technical debt. It’s the price for the exchange of what’s good for what’s fast. I find these decisions happen mostly in two situations: when doing the right thing is too hard, or when we are close to a deadline.

About things being hard, there’s not much to say about it. I feel team members (including leadership) that are jelled enough will give each other confidence to do hard things. Even more importantly, mature teams will create an environment where failure is not only accepted, but encouraged.

But deadlines are a trickier business, especially if you’re not the one who owns the project. A good negotiator will be able to postpone the deadline in order for the team to do the right thing, but I’m sure you’re familiar with the bitter taste of a postponed deadline. It’s a hard pill to swallow, but you just have to remember this decision will pay off. It always pays off.

Nothing Out Of Place

When I think about software out of place I think of code that was written but is no longer needed. I am unfortunately guilty of leaving dead code in a repository just in case, especially it this particular code was especially hard to implement; or is an elegant solution to a problem we don’t have anymore.

What is it that makes us keep these bits of code? I think it’s pride. Pride of the code we wrote, and regret that ultimately there’s no use for it. There’s no remedy: push it to a gist or a personal repository, remove it from your project, and move on. Over time it will lose it’s importance to you.




this has been a shorter essay, I’m trying to force myself to write more often. I expect to write a new article a month or so.