The Relentless Desire of Programmers to Avoid Compromise

Last week, a friend of mine asked an interesting question: “Have you ever seen a code base without compromises?”.

We debated for a while and very quickly realized that this question is meaningless. The first thing I’ve learned about engineering (and, as a result, software design) is that any solution has advantages and disadvantages. Any choice you make when writing code is a compromise. After all, software engineering (including architecture and design) means to continuously balance things like: time to market, correctness, changeability, security, usability, performance… It’s impossible to have them all at once.

Two examples come in mind. No matter how solid your knowledge and practice of SOLID principles (pun intended) is, you cannot open your code to all possible types of change. You are always favouring one type of change over another. Usability vs. security is another typical compromise. After all, introducing a user name and password is an extra step for accessing a link of an application. It would be best for usability to avoid authentication completely, yet for security reasons you need to compromise.

I trust this is all common sense.

It’s surprising how prevalent the wish to avoid compromises is in the minds of programmers

I have one explanation for it. My mind as a programmer is a bit strange. For example, another friend asked me today if I can answer a question. What she really wanted to say was “do you have time to answer a question now?”. Yet I caught myself over thinking this simple question on many levels. I had time to answer it, but was I able to do it? I had no idea, and needed more data. But gathering more data takes time, so what if I the time ran out before I was able to answer the question? Would it be correct then to simply answer “yes”, since I have no idea if I really could do it? My instinct was to answer “possibly”, but how does this help the other party? Of course, I did answer ‘yes’ and I managed to help her. But I couldn’t escape this inner mental process.

As programmers, we hunger for precision. Computers are precise, after all. Yet very few things other than computers are precise. And then we realize little by little that even software engineering is doomed to be imprecise, since we everyday must make decisions based on partial or incorrect information. Further more, we need to work with people whose lack of precision is proverbial (at least for us): customers, sales, marketing. This ruins the ideal world of programs. I know many programmers who held a deep belief that if they only had more time, less pressure and better information they could build the perfect software. Yet, on a conscious level, we all know perfect software doesn’t really exist.

I believe the solution is in learning the deeper lessons of engineering, software architecture and software design: that every single decision you make favors one thing over another. A mindful programmer would continuously be conscious about the pros and cons for her decisions. This is obviously difficult, but I believe it’s possible with practice. I found the Architecture Kata a particularly useful format in this regard. Other ways to practice are: pair programming with the right people or mob programming.

Are you a mindful programmer? Let me know in the comments.

Photo source: http://pixabay.com/static/uploads/photo/2010/12/23/12/45/antelope-canyon-4027_640.jpg