Sometimes we choose inefficiency

Engineering, in general, is all about finding efficient solutions to problems. Software engineering is no different; we are always looking for efficient architecture for our apps, efficient algorithms for our business logic, efficient programming languages, etc.

The one thing different though is that sometimes while developing software we choose "inefficient" solutions on purpose. I don't mean that in a bad way. It's not that engineers are not good enough to find the optimal solutions. It's that efficiency is defined based on one property that we choose to optimize. So choosing to optimize for something that's not the usual property (e.g. technical efficiency) might look like we choose inefficient solutions.

Let me give you some concrete examples to help you understand what I am talking about.  

Code repetition is considered awful and condemned in code reviews. Code reusability indeed is one of the basic principles of software engineering. Therefore having repeated code when sending out code to be reviewed looks bad. But in large/huge codebases optimizing for readability is sometimes more important than never having a line of code repeated. Having (a small amount of code) repeated might reduce the context switching (i.e. jumping to a method and back) thus improving the overall readability of the codebase. Easier to parse codebase is especially important in big companies where people come and go. So sometimes being technically "inefficient", as having the code repeated, is preferable.

Another example I encountered, which is a quite popular architectural choice in big projects, is the microservices paradigm. If you think about it, having a monolith (i.e. all the teams contribute to a single binary) is way more efficient and performant than any form of microservices architecture. Microservices have digital communication overhead; each RPC has latency cost. In addition, there's the physical communication overhead; teams need to be in sync for having their services to talk to each other. Still, all this described inefficiency is preferable to having to coordinate a big number of people into submitting code to the same huge binary. When optimizing for velocity, technical inefficiency is preferable.

My point here is that software engineers should not be obsessed with technical efficiency. Be thoughtful on what is the optimized property before choosing the ideal solution. There are cases that the most technically efficient solution is not what is needed. Sometimes we choose inefficiency and that's fine.

Happy coding!