Are you annoyed by software engineers that never follow the standards? Or by your fellow engineers making everything overly complicated? Find out how this comes and what you can do about it!
In my 20 years as a software engineer, I have had several heavy discussions that were unpleasant for both parties because they are not about the matter, but about who is right.
The discussions usually started small, with a simple question:
- Why don’t you use an interface instead of an abstract class?
- Why do you use a factory for a newable object?
- Why do you use a Dependency Injection Container?
- Why so complicated?
These are simple questions, but when asked, tend to result in vivid discussions about life, the universe, and everything in between. With a lot of emotion, dogmatic reasoning and intense frustration:
- That’s a best practice!
- It is an anti-pattern not to do so!
- New programmers will otherwise not understand our code!
- Who are you to complain? You never use design patterns yourself!
- Please stop nitpicking, just follow the standards!
- I am the architect so I decide!
Phew. I was just asking. Just trying to be pragmatic, helpful, to see whether we could make our code simpler by eliminating things that do not provide direct value.
Why do we react so firmly on each other? I will explain what lies underneath and will provide some tips to make it better. But let’s start by introducing 3 types of engineering.
3 Types of engineering
In his blog Minimalist approach to Object Oriented Programming with PHP, experienced software engineer Tony Marston describes 3 ways of software engineering:
- Apprenticed Engineering. That’s the way of engineering as performed by the ones that just started programming. They do not yet know much about design patterns, best practices and tools. Apprentice code is rather straight forward and often works, but may need some fine-tuning.
- Fitting. Fitting is when one has learned all the patterns, best practices and tools as an apprentice engineer, and faithfully applies them to his work. And expects others to apply them as well. Engineers who fit love to use frameworks that plumb everything together, in favor of writing code themselves.
- True Engineering. When performing true engineering, one doesn’t care anymore about design patterns. True engineering is pragmatic and cares about simplicity: the art of omitting what is not strictly necessary to produce correct, readable and maintainable code. Someone who masters true engineering may apply patterns and best practices, but not because they are tought to, but because the specific situation requires something more than the simplest approach without these patterns and best practices. When a framework does not supply what they need, a true engineer will happily write the functionality by itself, which is fun, a learning experience and provides exactly the functionality that is needed.
Both apprenticed and true engineering are pragmatic by nature. Apprenticed engineering is pragmatic because such an apprentice engineer does not yet know how to make things complicated. True engineering is pragmatic because those who master true engineering have experienced the importance of simplicity, so they choose to omit practices that do not add value.
In the context of this blog, the opposite of pragmatic is dogmatic. Dogmatic is defined as asserting opinions in a doctrinaire or arrogant manner (dictionary.com), characterized by an authoritative, arrogant assertion of unproved or unprovable principles (thefreedictionary.com), where statements and opinions are forcibly asserted as if authoritative and unchallengeable (collinsdictionary.com).
Pragmatic is to Dogmatic what science is to belief. A pragmatist is open to explain his choices almost in a scientifical way, to listen to alternatives, and to embrace those alternatives when they are better. A dogmatist defends his beliefs, becomes frustrated, and feels personally attacked when confronted with critical questions.
Fitting is a dogmatic way of engineering. One that fits strongly believes in the design patterns, best practices and tools he has learnt. He/she wants to apply them everywhere, even when they add little value in a certain situation and only add to the complexity of the software.
As Tony puts it:
Programmers that try to enforce those ideas onto you in a purely dogmatic and dictatorial fashion seem to think that their rules, methodologies and “best practices” are absolutely sacrosanct and must be followed by the masses to the letter without question and without dissension. They criticise severely anyone who dares to challenge their beliefs, and anyone who dares to try anything different, or deviate from the authorised path, is branded as a heretic.
So what does this al bring?
I started this blog with some simple questions I have asked to so many fellow engineers in the past about overly complicated code. And I listed a whole bunch of dogmatic responses that I have received from a small subset of these people in the past. They often accused me of being heretic: not following the well-established standards. And as the discussion continued, the other party always became clearly frustrated and annoyed and wanted to stop the discussion
This pattern is a clear sign of the other party applying the fitting approach to engineering. The firmness of the defense, the accusations of not following the standards and thus not producing quality code, and the omission of on-matter arguments strongly all point to the dogmatism that goes hand in hand with fitting.
Do you recognize yourself as being emotionally touched by pragmatic remarks? Do you see those remarks as a personal attack? Are you convinced that design patterns and best practices must always be used? Your reaction may indicate dogmatism, which is a sign that you are stuck in fitting instead of true engineering.
Which is not a shame. It is normal to believe in the design patterns, best practices and tools that you have learned and used so often. But dogmatically sticking to that, and forcing it upon others, is not pragmatic. It hinders in-depth and on-topic discussion with your fellow engineers. It hinders personal and team growth. And it makes both you and your fellow engineers feel bad: disrespected, unheared, misunderstood, frustrated.
So what can you do to turn fitting into true engineering?
- Detect and accept when you are fitting, and that you are on your way to true engineering.
- Open yourself up.
- Listen to other engineers and their arguments.
- Whatever you do, start simple and continuously check that you are still doing the simplest thing.
- Remove everything (design patterns, best practices, tools, libraries) that is not necessary for the required functionality or maintainability.
- Dive into libraries of others. Be open to libraries of your fellow engineers, try to understand why they wrote the library instead of using an existing library.
- Debug existing libraries. Write libraries on your own. But keep it simple, don’t overdo.