DevOps and Me

I just finished reading the book The Phoenix Project by Gene Kim, George Spafford, and Kevin Behr and I must say that it was fairly transformative in my outlook towards delivering software to the enterprise.  As many that know me will attest (my wife, mostly), I have bounced around trying to find my place in this new career.  I haven't understood well the restless feeling that recurs with each organization that I join.  Reading this book and accompanying resources  has allowed me to crystallize exactly what I am looking for in a development shop and finally identified my long term career goals.

In mathematical training, my goals were to begin to understand the higher level mathematical concepts and to find my place within the vast universe that lay before me.  This behavior took place daily and was lead by experimentation, study, discussion, and persistence. It was like a sport to me, every waking hour my thought was consumed by difficult concepts laid out in lecture, colloquium, or the text.  The feedback loop in my understanding was fed by my participation in the classroom, my written work, and further exploration beyond foundational topics.  It is helpful here to consider what a good day looks like and a bad day.  A good day looks like the following:

- Review the work from previous day preparing for class for the day
- Attend lecture, participate in conversation, and carry on conversation outside the classroom
- Visit advisor's office to discuss research, vigorous conversation ensues, leave with new directions to explore
- Student in the class I am teaching comes with a well thought out question and discussing for a few minutes sheds light on any misunderstanding.  Provide next steps to drive student understanding
- Use the conversation from after class to drive better output in homework for the day
- Follow up on the new directions after discussion with advisor

A bad day looks like the following:

- Unprepared for lecture, new concepts barely register
- Unprepared for advisor meeting, leave in the same place you started the day
- A gaggle of students visit your office and leave no closer to understanding because they just wanted the answers to problem number 5 and 8.
- Waste the rest of the day unmotivated because of the first three activities of the day.

As I matured in my work, it was essential to have more bad days than good.  For developer friends, hold on to this as I promise I will get to something interesting to you in a bit.  Notice that the key competencies of my work are highlighted in each stage of a good day.  Progressing towards research goals, better understanding the landscape of mathematics, succeeding in my job for the university as a lecturer.  Little time was spent wasted and all feedback loops were short.  The bad days were bad because of the need for rework, the delay in producing outcomes, and often unwelcome interruptions.

As a developer in a large enterprise framework, my goal is to deliver software that will provide value to the enterprise.  This concept of business value is often lost on developers at my level as it isn't presented to them as a core concept.  The idea of "features" and "bugs" are meant to distract developers from what should be their core competency, delivering value.  Agile methodologies are meant to help align the concepts developers know well: feature building, technical debt cleanup, and technical improvements, with some idea of business prioritization.  Unfortunately, these methodologies often fall short of their goal to provide fast feedback loops between developers and those that their work most greatly impacts.

I want to ask the same question to my developer friends that I answered above for my mathematical training.  What does a bad day and a good day look like?  I believe everyone's bad day looks pretty much the same.  Firefighting production outages, business and salespeople asking why features aren't deployed yet, broken build because of a poor development processes, and interruptions by outside work are all part of a developer's worst day.  Everyone's best day looks a little different, but one thing that will be in common is this: a day that the assigned tasks get done and no one else's problems affect what you need to do.

This leads directly into the question of how these tasks are assigned and who gets access to the flow of development work through the developers.  My previous job as Seagate has provided me some insight into the manufacturing process and this book further solidified my understanding of development as a set of resources carrying out finite steps that put a product out into production.  The product output of a development team is a little harder to see as it goes beyond just the executable, the visual output, and the data that they generate.  The source code and the process that assembles the source into an executable is essentially the product of any development manufacturing and it is much harder to see what a defective "product" looks like.

This book showed me why I felt these "products" were so defective.  It wasn't that we had bad source code (all the time) or that our individual work was bad.  Often it was that we were planning for a future that felt it may never come.  A year is now a long time in the business feedback loop and we were trying to plan for features that would be implemented 16 months or greater down the road.  We couldn't get buy in from any business partner because our feedback loops were much too long.  A feature request can't get appropriate reaction if the first time they may see anything is 4 months down the line.  At that point, the business opportunity is probably past and their competition has moved on to the next priority.  This further highlights the feeling of "we want this yesterday" that is so often put on development teams by their business partner.  This stress forces developers to attempt to complete features in a haphazard way without good understanding of the underlying risks that come with any new features.

 DevOps within the enterprise allows developers to provide maximum value to the business while reducing stress on the organization as a whole.  This reduction of stress is itself a feedback loop which provides developers an opportunity to produce higher quality output faster.  The reduction of stress comes especially in two areas.  First, there are less days lost to unplanned work because these outages are planned for and understood in the larger deployment context.  Single points of fault are eliminated or processes for restoring the fault are understood by all.  Second, the time normally allotted to this firefighting or to lengthy deploy process can instead be given to internal IT concerns.  There is always technical debt to be alleviated but no business wants to pay their taxes.  Development can provide this time to itself by reducing the two least accounted for types of work, changes and unplanned work.

Now, I have to decide what to do as my next steps.  For that, I'll have to ask you to stay tuned.