Close

February 14, 2018

Try to Catch the Unicorn

A long time ago, I once read about how true democracy is impossible, but that shouldn’t stop us from trying to achieve it. Actually, it might have been a text about anarchism. I can’t remember. And it was probably more eloquently put, but I want to take that “quote” and change it to:

While perfect code is impossible to achieve, we should continuously work towards it

I was reminded of this quote when a fellow developer told us he had doubts about our efforts to get a database running locally. This was a large legacy application where the team would work on a single, shared database. We wanted to tackle this legacy by starting out with a local database. This would allow us to make changes more easily, write and run tests without getting in each others way, etc.

But getting the database set up locally was proving to be a non-trivial effort. There were cross-database and cross-server dependencies, stored procedures that required long-gone tables, views referencing removed columns, etc. We tackled the problem for over a month before we started getting anywhere.

The colleague mentioned he thought that having a local database in a project was like trying to catch a unicorn: everyone talks about it, but no-one manages to do it.

While this may certainly be the case for some principles in our profession, I don’t believe this must be so for local databases. But the database example isn’t important. It’s just a segway to my main point.

In software development, we have many principles and best-practices. TDD means writing a test before writing any production code. You should follow SOLID principles. Don’t repeat yourself (DRY). And so on. But if you try to follow these principles everywhere and all the time, you’ll never get anything done. And that’s not the point of the principles. We shouldn’t be fundamentalists. It’s OK to cut corners. It’s OK to write code that isn’t perfect, be it by accident or on purpose. Sometimes you don’t know any better until some future point in time. Sometimes there is no time, and you work with what you have.

We should accept that. But the moment we take that acceptance as an excuse to no longer try, then we’re going down a slippery slope. It will put you in a much worse state than when continuously attempting to reach the goal of a clean, readable, tested codebase. It will creep up on you, slowly, bit by bit. But before you realize, you will end up with a legacy mess that is immensely difficult to maintain.

So keep trying to reach that blissful state of a perfect codebase. You will never achieve it. But your codebase will be much more enjoyable to work in, than when you no longer try.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.