For almost the whole extent of my career in Engineering, I have thought about the answer to the following question:
What is the goal of Software Engineering?
When I started -- and for a good while -- I believed the goal of Software Engineering was to produce working software that was useful to their users. After all, what is the point of writing Software if is not going to be used by anyone? This is what I call the pragmatic goal.
But then, later down the line, I came to believe that the true goal of Software Engineering was to produce software that was easy to maintain and evolve by their developers. After all, what is the point of writing Software that will have to be re-written every couple of years? This is what I call the dogmatic goal.
During my career, I've met people leaning toward one side more than the other. I hate to generalise, but followers of the pragmatic goal tend to be very effective at accomplishing tasks and delivering value, but pay very little attention to design and evolvability, and make architectural decisions that happen to be very costly later down the line. On the other hand, followers of the dogmatic approach tend to be more focused on theory, patterns, methodologies, abstraction and processes rather than thinking about how to effectively solve a business problem and deliver value to users. They oftentimes end up coming up with over-engineered solutions that are unnecessarily complex or that solve the wrong problem because they lack user perspective.
This reality is engineering's own Apollonian and Dionysian sort of tension. I would say you can classify every engineer on earth in one of these two opposing camps, and that they usually are accompanied by other traits and characteristics opposed to the ones of the other side, in a truly remarkable way.
Pragmatism | Dogmatism |
User-centred | Engineer-centred |
Focus on Usefulness | Focus on Correctness |
Present Looking | Future Looking |
Results Driven | Process Driven |
Simplicity | Complexity |
Naiveness | Pessimism |
Emotive | Analytical |
Delivers Value | Exhibits Knowledge |
Seeks Freedom | Seeks Order |
Flexibility | Uniformity |
Concretions | Abstractions |
You might read this list and immediately identify with one side of the spectrum. Well, I'm here to tell you that if you easily identify yourself with one side, then you might want to start pushing to the other.
Neither of these camps is correct by itself: both put the focus on things that are true and valuable. I think the true goal of software engineering is to produce software that is both easy to use by their users and easy to maintain by their developers. And the biggest challenge is to successfully navigate the tension that exists between both.
For instance, let's take the pragmatic approach. You could build the most useful piece of software, but if it is poorly designed, then you can know for sure it will cease to be useful because a rewrite will be needed. I've seen systems that are awful to work with and that quickly burn out their engineers because the last thing someone thought about was how to make it maintainable. Sooner rather than later, your engineering turnover rate cost will be much more than what your business can handle. You will have a really good idea or product, but it will be impossible to scale.
On the other hand, you can build the most maintainable software. And you might have no issues finding engineers that want to work in a well-designed software or system. But can get so focused on correctness and maintainability, that you might be late to the market or worse even, you discover that the market has invalidated many of the hypotheses in which you built your product.
There is no escaping from the fact you need both. A good engineer is capable of being both pragmatic and dogmatic at the same time. And this is no easy feat: you will over-steer to one side or the other quite often, so we must be constantly reminded of this.
The goal of Software Engineering is then to produce software that is both easy to maintain by their developers and that is useful to their users. Is part of your job to have both things in mind when exercising your trade, and you must not compromise on any of them.
