Tag Archives: engineering

Rollback Addiction

A lot of teams are fascinated with the notion of ‘rollback’ in their environments.  They seem to be addicted to its seductive conceptual simplicity.  It does, of course, have valid uses, but, like a lot of things, it can become a self-destructive dependency if it is abused.  So, let’s take a look at some of the addictive properties of rollback and how to tell if you might have a problem.

Addictive property #1 – everybody is doing it.  One of the first things we learn in technology (Dev or Ops) is to keep a backup of a file when we change something.  That way, we know what we did in case it causes a problem.  In other words, our first one is free and was given to us by our earliest technology mentors.  As a result, everyone knows what it is.  It is familiar and socially acceptable.  We learn it while we are so professionally young that it becomes a “comfort food”.  The problem is that it is so pervasive that people do it without noticing.  They will revert things without giving it a second thought because it is a “good thing”.  And this behavior is a common reason rollback does not scale.  In a large system, where many people might be making changes, others might make changes based on your changes.  So, undoing yours without understanding others’ dependencies, means that you are breaking other things in an attempt to fix one thing.  If you are in a large environment and changes “backward” are not handled with the exact same rigor as changes forward, you might have a problem.

Addictive property #2 – it makes you feel good and safe.  The idea that “you are only as good as your last backup” is pretty pervasive.  So, the ability to roll something back to a ‘known good’ state gives you that warm, fuzzy feeling that it’s all OK.  Unfortunately, in large scale situations with any significant architectural complexity, it is probably not OK.  Some dependency is almost certainly unknown, overlooked or assumed to be handled manually.  That will lead to all sorts of “not OK” when you try to roll back.  If rollback is the default contingency plan for every change you make and you don’t systematically look at other options to make sure it is the right answer, you might have a problem.

Addictive property #3 – It is easy to sell.  Management does not understand the complexity of what is required to implement a set of changes, but they do understand “Undo”.  As a result, it is trivial to convince them that everything is handled and, if there should be a problem with a change, you can just ‘back it out’.  Being able to simplify the risks to an ‘undo’ type of concept can eliminate an important checkpoint from the process.  Management falls into the all to human behavior of assuming there is an ‘undo’ for everything and stops questioning the risk management plan because they think it is structurally covered.  This leads to all sorts of ugliness should there be a problem and the expectation of an easy back-out is not met.  Does your team deliberately check for oversights its contingency plan every time or does it assume that it will just ‘roll it back’?  If the latter, you might have a problem.

As usual, the fix for a lot of this is self-discipline.  The discipline to do things the hard and thorough way that takes just that little bit longer.  The discipline to institutionalize and reward healthy behaviors in your shop.  And, as usual, that goes against a fair bit of human nature that can be very difficult to overcome, indeed.

Advertisement

Managing To Get To Agile is Harder

There are a variety of jokes or snarky comments made about management.  A lot of them are modern echoes of Industrial era factory practices.  And that is the hard thing – most large corporate management doctrines are merely evolutions of principles established in the industrial era.  That era was characterized by hyper-specialization of jobs so that the companies could achieve economies of scale, from which competitive advantage could be derived.  That, of course, led to a whole system of policies, rules, and even laws that reflected that era.

Of course, competitive advantage from economies of scale is not a focus today.  Business moves too fast.  They key advantages are responsiveness to the changing market and the ability to exploit shorter-lived opportunities.  Even manufacturing processes have evolved to enable faster retooling to serve different markets with the same facility and equipment.  Agile development and DevOps are how the need for business agility gets reflected in IT.

Despite these market dynamics, the people management doctrine for most businesses still looks like an old-school industrial approach.  There is still a push to specialized roles and to do appraisals within a narrow set of rules for that specialty.  The generalization that is intrinsic to agile execution is not valued and corporate structures often limit what lower and middle level managers can do in terms of incenting the behaviors of folks on their teams.  A lot of that is based on the fact that the HR structures are designed to stay within a narrow band of safe and easily defended legal structures so that a pissed-off employee can’t really sue if there is a problem with perceived fairness.

These things are easier to achieve in smaller companies where there is not the same legacy and, frankly, there just isn’t as much sue-able money.  It is naive to not think about these aspects and would be patently unfair to simply slam things for being the way they are.  Things are the way they are for a lot of very good and very complex reasons; some of which are beyond the direct control of the business.

It is solvable, of course.  You can use creative organizational structures that put nominal specialists ‘on assignment’ in other specialty teams.  A popular extension of this is full-on matrix management.  A variation on the matrix is to have people farmed out to project teams in a similar manner to how consulting companies do things.

The common point of these solutions is that they require managers to work together in new ways.  They require managers of managers to encourage good team dynamics for their teams of managers.  They require a lot of communication and interaction among managers and to scattered teams.  Lower-level managers will have to be empowered to invest in and coach their teams into adaptable groups with good team dynamics.  It means the managers will have to be a lot more “hands-on” and leader-like rather than manager-like than they might be used to.

That is a lot harder for all levels of management than scientifically managing a group of theoretically interchangeable specialists.  The odds are that the managers are not trained for leadership skills relative to management skills.  So, as the organization goes Agile, make sure that the investment includes an investment in how to actually manage in an Agile environment.  It really is different.  It really takes an investment.  And it really will eventually take structural change.