I was reading “how devOps is killing the developer” by Jeff Knupp.  It made me think about the multi-faceted developer, who is covering “all the bases” (because it’s a start-up, and there is nobody else to do it), to the organisation who thinks they can run a “whole operation” (regardless of what it does), with a handful of developers.

Every coin has two sides.  I have finished reading the Phoenix Project, and am in the process of reading “The Goal - A Process of Ongoing Improvement”.  Both deal with issues related to “through-put, inventory, and operational expense”.  It’s very easy to type these three phrases, but far more difficult to see how these relate to a start-up, a manufacturing plant, a corporate, or the delivery of IT widgets.  Each one will be very different.

The books focus on “how are things done currently, and previously” people talking, trying new things, a hit-squad (with a goal to get a small improvement to work in a very small timeframe).  They don’t focus on just the technology, but rather how people do their jobs, what vital information is needed in different parts of the business, and “if you are making widgets”, how long does it take for one to be made, how many processes are involved, impact of delays and work-in-progress, how long to wait for raw materials, how many of the completed widgets are stored in a warehouse.  

Common sense, easy to understand, and you don’t need a Computer Science degree to “get-it”.  But it doesn’t give me the silver bullet to answer the question, “what is devOps?”

Moving solely to a software development / devOps team, you may be unlucky to be working in the Jeff Knupp definition of DevOps, or may be the developer who does everything.  But are these any different to a person who works in a manufacturing plant, who “wears many hats”.  I don’t think so.  All jobs will be impacted by a working environment which “does not get-it”

All rely on a culture of improving things, but this improvement needs to resonate throughout a business.  It is not just about automation, building Docker images, and using AWS.  These are the tools which are “de rigueur” today, but are no different to the equivalent Perl and BASH scripts in the 1990s.

One thing which is very apparent, is that computer systems are increasingly complex, and creative solutions are needed to ensure that engineering teams aren’t forever picking up the pieces, wrapped up in a blame culture.

*I’m not 100% sure what these creative solutions are, but to start, “it’s not just down to the tools in a toolbox”, but also the way the tools are used, across a business (not just an IT function), understanding what different projects (widgets) want (doing), empathising with the “delivery” team (or individual), the business providing the support which is needed, and common-sense communication.

Ensure these creative solutions are not wrapped in process* and bureaucracy, because it feels familiar, and comfortable.

Your suggestions are welcome.  Especially from developers, and devOps, and wearers of multiple hats in manufacturing plants.