
Containers Will Not Fix Your Broken Culture (and Other Hard Truths) - dmcdm
https://queue.acm.org/detail.cfm?id=3185224
======
zbentley
"...process is the scar tissue of past failures"

That's an extremely important point to keep in mind.

------
dmcdm
I guess this article just resonates with me as a member of an organization in
the process of "transforming" itself by migrating to a containers-and-services
architecture with the goal of "continuously delivering" components of what has
historically been a very monolithic and tightly integrated product. Lets just
say it's in the class of products one might consider "big iron", but not
strictly. This transformation sounds like an admirable goal on paper and in
meetings, but the system we are building today is even more complex than what
preceded it, because it has to do all the stuff it did before, and more, but
now I have to worry about containers and a half dozen ways to orchestrate
them, and whatever some other team has decided to replace their API with
because now nobody is supposed to make assumptions about what anybody else is
supporting, or we're all supposed have our software spend a bunch of cycles
negotiating versions and APIs or something. This is way more complex. I guess
the idea is now we can release patches for individual components, instead of
having to do roll-up releases or something? But there's really no reason we
had to do those anyways - dynamically linking to a library isn't much
different conceptually than attaching to a "service API" when it's all
happening internally to some box.

People go read about what Amazon, or Netflix, or Facebook are doing and see
how successful they've been (in both the financial and technical), and say "we
can be like that too if we use the same stuff they're using!". Some manager
reads a book which makes broad generalizations about "the right tools and
behaviors", and starts building a cargo cult around them. Some kid in the
valley whose never worked with a codebase larger than 10,000 SLoC writes a
blog post about it, and everyone makes a toast with the koolaid. "More than
10,000 SLoC is an anti-pattern!" you say.

This may be a bit of stretched analogy, but just as communism or other socio-
economic ideologies have given some people a framework for uprooting their
broken incumbent governments and power culture, technological fads like
"DevOps", etc, sometimes just give people the framework to uproot their broken
incumbent tools and technology culture. The problem is, most of the time what
you needed wasn't communism per-se, or DevOps, but just some framework to
mobilize and guide your culture into fixing its fucked up status quo. It would
have been better if you looked at your problems, instead of looking at the
other guys solutions. The unique pitfall technological transformation
encounters in this regard, is often the social framework (i.e. DevOps) gets
conflated with the tools (i.e. containers and microservices), and leadership
tends to focus on the latter - because changing tools is easier than changing
people. What you needed was a better culture, and I think in most cases - a
culture of reducing complexity - but what you got instead was microservices
and "containers.

