Software engineer role revisited – from waterfall to microservices
Our industry is quite young, and this is something we easily forget. It has been 70 years since the first program was executed. During this period, software developers have always used metaphors to explain what they do.
We call ourselves software engineers. In civil engineering, engineers are those who combine a set of math and empirical knowledge to assemble different materials into a beautiful building. Likewise, in computer science, software engineers are those who combine a series of math and empirical knowledge to assemble machine instructions into fancy programs that interact with the external world.
In civil engineering, a building starts with the foundations that, once are established, never change. Likewise, in software development, for many years, programs were implemented based on database relational entities and core business logic that, once established, should not change considerably.
But what if a single civil engineer could alone recreate a complete and self-contained building in the timeframe of 2 weeks, with no loss of material and with the same quality and benefits to customers? What if instead of constructing this giant skyscraper, where the quality and safety of each floor fully depends on the quality and safety of the previous one, buildings could grow up horizontally with minimal risk and dependency between each block?
This is exactly the revolution that has started since 2005 in software development when Dr. Peter Rogers shot the concept of Microservices during a conference on cloud computing. Soon after the conference, this concept became popular. Developers started realizing that it was not just a concept but in fact a new way of designing software.
The immediate benefit of using Microservices was obvious: coding became cheaper. Developers were encouraged to build more and more services that were easier to understand and maintain. Also, if by any chance, a service was not performing as expected and had to be rewritten, no big deal: two weeks of a single developer was all it would take.
But, in a world of microservices, can we still be called ‘engineers’? This is the question that Sam Newman tries to answer in the first chapters of the book “Building Microservices – Designing Fine-Grained Systems”.
In his book, Sam explained that software requirements shift more rapidly than they do for people who design and build buildings. Once a program is launched into production, it will evolve in its use and interaction with the external world, like a living creature. The best analogy to illustrate this mechanism is a city.
The city changes over time based on external forces and the preferences of its occupants. The town planner is the person responsible to anticipate the changes the city will face. This person knows it is impossible and quite futile to control the change in all its aspects. More important than to worry about what happens inside the buildings or zones, is to worry about what happens between them. Likewise, in microservices architecture, more important than to worry about what happens inside one service, is to worry about what happens between the microservices.
In a conference about the future of the web in 2011, the CIO of Google, Ben Fried asserted the professionals of the internet to its next levels of scalability will not be specialists, but generalists.
Besides the shift to cloud computing, shifting to microservices plays an important role in this change of paradigm. I would not be surprised if, in the near future, the software engineer’s title becomes obsolete and developers started to call themselves as something else.
