Less Art, More Engineering
Although software development is an “industry” and computer programmers are “software engineers”, actual software development is far from traditional engineering. The key difference is, well, lack of actual engineering. Wikipedia defines engineering as:
Engineering is the practice of using natural science, mathematics, and the engineering design process to solve technical problems, increase efficiency and productivity, and improve systems.
Software development, in contrast, is largely subjective.
For example, we assess code using “readability”. But what is “readability”? Surprisingly, there is no definition which would allow measuring readability or, at least, objectively compare two pieces of same code for readability. There are no binary (readable/non-readable) criteria, either.
Another example — so called “best practices”. Try to dig Medium for this combination of words, and you easily find contradicting “best practices” or even clearly “bad practices”, which were condemned decades ago for their harm to the code or design. Even if “best practice” is actually good, there are no criteria to verify that this is so. And there are no criteria to verify that this particular “best practice” will be efficient in that particular use case where you’re going to apply it. In other words, “best practices” is nothing else than a cargo cult: we’re applying approaches used by someone else in the hope that they will provide the same benefits to us.
But the issue does not end at the coding level. We have the same issues with the design too. “DDD” and “Clean Architecture” provide no verifiable criteria to check correctness of the design or, at least, some of its key elements.
Moreover, issues caused by subjectivity do not end here. It makes the whole industry susceptible to manipulation. Armies of “champions”, “developer advocates”, paid and voluntary “influencers” are pushing various software technologies into the masses using unprovable and unverifiable claims. Often with devastating consequences. Just two very well visible examples.
Spring
Spring dominates the Java ecosystem, with the slogan “makes Java simple” and claims like this:
Spring makes programming Java quicker, easier, and safer for everybody. Spring’s focus on speed, simplicity, and productivity has made it the world’s most popular Java framework.
Anyone, who worked with Spring for at least some time, knows, that only one claim from the quote is true — Spring popularity. Everything else has nothing in common with reality: Spring applications are slow, memory hungry, susceptible to subtle, hard to nail down errors. Spring-style code is abused with annotations, which resulting in a constant need to “unwind” and “assemble the puzzle” in the head. Some “solutions” and “best practices” pushed by Spring are explicitly tying application to the framework, breaking elementary design rules.
Microservices
Actually, microservices make perfect sense in some cases. And a few dozens of huge companies in the world really getting benefit from them. But hysteria around them now forces every single startup with a half-dozen of users to build its MVP as a hundred microservices deployed in Kubernetes.
End Of Free Lunch
Of course, there are companies which benefit from the current state of the things. But this can’t last indefinitely. Funny enough, subjectivity causes issues here too. Demand on software grows every second, and it can’t be satisfied by increased headcount because every new developer needs to grow up his own subjectivity. Unlike a simple formula or method, which can be taught, (exaggerating) overnight. In other words, the subjective approach for software development is not sustainable. To survive, we need to shift to real engineering, define clear and consistent terminology (for example, stop calling everything “architecture”), define verifiable criteria, start assessing tools/libraries/frameworks using reproducible objective methods.
The transition will not be simple. It requires a lot of research, an in-depth understanding how we write and (perhaps even more important) read code. How we structure and encode business knowledge into the software. What and how affects our productivity.
The next step is to convert obtained knowledge into a set of clearly defined and well grounded rules and criteria. Ideally — measurable, but in either case easily verifiable.
