Chapter 20. Don’t Elevate the Means Beyond the End

Seth Dobbs

Our industry is rife with trendy technologies such as microservices, serverless, and blockchain, and trendy processes such as Agile and Lean in all of their various forms. Years ago, the trends were EJBs and UML, and before that, shifting to object orientation and having a structured Waterfall were important.

In their time, none of these were bad in and of themselves, but each wave creates the potential for missing the point behind each of these waves and leads to organizations serving the means. This behavior manifests in comments such as “that’s a bad requirement because it doesn’t fit our architecture” and “that’s not Agile!” In fact, we as an industry can become dogmatic around the means as if that is our purpose rather than them merely being tools.

For example, I’ve encountered several organizations with the directive to “implement microservices.” The problem is, “not having microservices” isn’t a problem, per se, nor is microservices a solution in and of itself. It is a tool or a means for solving a problem. This becomes more ironic in organizations that are dogmatic about Agile given that the Agile Manifesto is itself a set of principles that among other things eschews dogmatic process.

Not to pick on microservices specifically; this is an architectural approach that provides a ton of value for certain problem ...

Get 97 Things Every Engineering Manager Should Know now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.