The Role Of A Software Engineer -Professional Advisory Explicit Content
Throughout my experience as a software engineer and especially over the past year, I have been confronted to many ideas, concepts, good practices, design patterns, architectures, school of thoughts and so on. It is natural for any professional developer to grow some interest in how to make better software. After a lot of discussions, research and some more experience, it occurred to me only recently that all of this could be summed up in a few simple words : “you have to be explicit”.
Architecture
Let’s start with everyone’s all-time favorite, architecture. Software architecture is obviously a tremendously important subject when it comes to software development. A lot of principles and design patterns aiming to help you have the best architecture have emerged throughout the history of programming. But, no matter what your belief or preference is, all of them lean towards the same objective : being explicit. Whether we talk about Clean Architecture, VIPER, MVVM, MVC or any other, the only goal they have is to help you make it clear what you are doing and how you are doing it.
In some conference I saw from Robert C. Martin (Uncle Bob), he gave an example that stuck in my head ever since. Let me ask you something, to demonstrate this to you. Can you tell me what the following image is ?
“Well, isn’t it obvious?”, would you tell me, “this is a blueprint of a Cathedral!”. Neither you, I assume, or me are buildings architects or real estate professionals, and still, we are all able to tell right away those are the architectural plans for a Cathedral. When we look at it, it screams that this is made to build a Cathedral.
So when it comes to software architecture, why should it be different? If your architecture is great, it should become obvious right away to anyone opening your project what you are doing.
“Oh! This is obviously a bank account management application!”
“Oh now, clearly, this an online book store application!”.
As mentioned before, no matter what your favorite concepts or design patterns are, when it comes to having a good software architecture, it can be summed up in those few words: “you have to be explicit”.
Behavior-Driven Development
BDD is a software development process that is inspired by Test-Driven Development (TDD) and other design concepts from object-oriented programming. Led by Dan North this is a process that has gained in popularity over the past years and which I had the opportunity to get practical with in my last project.
The goal of BDD is to help the developers and business persons of a project to collaborate together by specifying business requirements together, and write tests that validates those business requirements inside the software. What this does is help make clear to both business and technical sides of the project what the application should be doing and if it is working properly.
This can be summed up in a few words: “you have to be explicit”.
Domain-Driven Design
DDD is an approach to software development created, or at least clearly defined, by Eric Evans. The goal of it is to place the focus of a project on the domain and its logic. By doing so, it allows programmers, project managers, stakeholders and any other person involved in the project to share the same vision of the domain discussed with a ubiquitous language and thus, understand each other. This helps business requirements be expressed better and the software to be aligned with the core domain of the project.
Again, all of this goes towards the same goal as everything mentioned before and could be summed up in a few words: “you have to be explicit”.
S.O.L.I.D. principles
Promoted by Robert C. Martin, the S.O.L.I.D. principles are object-oriented programming design principles. Those five principles have been the core base for many school of thoughts or methodologies. They are simply a set of good practices, or rules, that have been defined in order to help make clean functional software.
Whether we talk about Single Responsibility, Interface Segregation or any other principle, they all could be summed up in a few words: “you have to be explicit”.
Project Management
The idea I have behind project management here is how, as a team of developers, you handle a project besides writing your source code.
Outside programming, you should have a lot of things to deal with as a part of your project. Like how and where to deploy your application, documentation, communication, on-boarding and many other subject.
But again, whether you think about what documentation could be useful to provide or how you can make our on-boarding process better, it all relates to one single concern, which you probably guessed by now: “you have to be explicit”.
Being Explicit
All of the above are just a few of many more examples. I have questioned myself and questioned a lot of other developers throughout my still young career, trying to always find a better solution. I think we all strongly believed at some point that we had the best architecture or the best tests or even the smartest way to implement a function. But it seems like no matter the arguments we have, we are never able to settle on an agreement over these subjects. And this is okay! All of our beliefs and claims come from experience, ours or others’, and all of them usually make great sense in our context. We do not have to all agree on one best architecture, or a few best principles or design patterns. And we should not! But the more I look, there is one thing I find to be always true: “we have to be explicit”.
If a person takes your project and it does not appear clearly what you are doing, then you are probably not doing it the right way.
