Un-reason-able Software Engineering

In this article I will directly address problems that I have seen constantly in many software projects. Please do not feel offended but what try to take this information and check whether you can improve yourself or your colleagues and become a better software engineer.

In general, I would say that most software engineers have failed to understand who pays their bills. In this field, we are regularly not paid to play around with technologies but instead we are highly paid to build solutions for a business problem. Thus, our main goal should be to satisfy user requirements as best and as cost-efficient as possible.

While this should be clear to everyone, it seems that both software engineers and customers are not aware of this. In this article I will address us - the software engineers. Perhaps I will do another article on why businesses should not treat IT as a cost center later.

But why do software engineers only live for technical excellence? I genuinely like technical excellence! I like easy to understand, clean, and maintainable code. But I like the easiest route to them. Very often software engineers think about deep and detailed technicalities first - especially which frameworks to use. Framework-driven Architecture is probably the most frequently encountered variant of unreasonable software architecture. My personal low point was when a software engineer (not me) rejected a feature request by saying that the chosen framework does not support such a feature. This means this software engineer did not put the customer and its requirements first! Instead he had prematurely chosen a framework which he liked best and not for reasons based in requirements but instead of personal preference due to past experience or – worse and also common - the desire to try out new things. Software engineers cannot explain why they have made their architectural decisions. They are unreasonable about their software architecture because they have not reasoned about possible alternatives and forces that should have influenced their decisions.

This behavior costs enormous amount of effort, time, and money in many software projects, and is a very non-professional behavior. We as a profession should be able to defend our design choices with as many objective forces and reasonable considerations as possible. Being able to does not mean that we need to constantly do this to other people, but we should constantly do this to ourselves. Grounding our decisions more in requirements and choosing frameworks only after we know what concepts, algorithms, and architectural styles we want to follow let us build better systems. If we then find a framework or library which fully supports our decisions that we identified before as supporting our problems best, then we can happily use them. Then we have a reason to do so!

Thinking only in terms of frameworks and libraries lead to absurd solutions. Instead of fixing the underlying root problem, some software engineers just pile framework after framework on top off the problem. Far too often I have seen slow database performance being countered by deploying caching, touting NoSQL as the solution, or duplicating data in a full text search index instead of analyzing why queries are slow. Very often improperly configured OR mappers are the root cause. Properly configuring or replacing them would have been easier and would have led to a simpler solution than stacking more complexity on top of them. While this is a typical example in my world, you will probably recall many other examples from your professional experience. I would be extremely interested in them! Many examples can be found on YouTube, too, where many good coders demonstrate their admirable ability in using certain frameworks but also demonstrate their disability to justify their choices.

Having that said I think that we should be more reasonable about our software development. We should take care of requirements more than we do now and we should consider concepts and architecture more and only after these issues have been settled, we should think about the frameworks and libraries which we will use!