1. Are Your IT Practices Composable or Contextual?

    © 2013 Jeff Sussna, Ingineering.IT

    Neal Ford wrote a seminal post about composable vs. contextual development tools. James Urquhart applied composability vs. contextuality to PaaS cloud services. Thinking about this pair of terms has helped me frame my own thoughts regarding effective IT practices.

    In my experience, the best IT tools and practices are simple and lightweight. Their value is non-binary. They don’t make a difference between right and wrong, or good and bad. Instead, the very fact of using them makes things better.

    Version control is a prime example. People may argue about git vs. svn vs. TFS, or this branching strategy vs. that one. But I can’t remember the last time I heard anyone argue that using version control was worse than not. I don’t think I’ve ever heard anyone say they’d abandoned version control altogether because they spent a pile of time and money deploying it, only to have it fail (ignoring ClearCase of course :-).

    Version control is just one of numerous practices I’ve enountered that, for me at least, have been simple to understand and adopt, and quickly effective. Others include:

    • Desktop configuration automation using Vagrant
    • Engaging Infosec experts early in a project rather than at the end
    • Behavior-Driven Development
    • Managing units of work using a ticketing system intead of email or spreadsheets
    • Cross-functional standups (maybe)

    None of these practices by themselves solve “big” IT problems. All of them can be composed with each other to additive effect. None of them fail completely if not combined with all the others.

    Large-scale IT practices such as Six-Sigma, ITIL, RUP, and even Scrum, on the other hand, strike me as being contextual. Contextual practices provide overarching conceptual containers within which teams and organizations wrap themselves. They strive to move projects and companies from bad to good, from inefficient to efficient, etc. Whereas composable practices enable good behaviors and results, contextual practices try to prevent bad ones.

    Contextual practices seem to fail more often than not. They require large, long, expensive commitments. They encourage cargo-culting. When they don’t work well, experts tend to blame implementor’s imperfections. Doing it right vs. wrong is a binary choice. They tend to be brittle, with successful usage falling off quickly without vigilant process policing.

    My favorite example of the contextual practice mindset is “ScrumBut”. Scrum experts use this term to critique struggling Agile teams that “use scrum, BUT don’t do X”, where X is some part of the Scrum orthodoxy. ScrumBut implies that failure to follow the process to the letter leads to project failure. It doesn’t leave room for the possibility that the team in question only found some of the practices useful, or could only even understand some of them. It also doesn’t leave room for the possibility that the team is doing better by using some of the Scrum practice canon than it would by using none of it.

    Cross-functional standups are high on my list of useful practices. When I think back over the years, though, the most productive standups I remember tended to happen outside the context of formal Scrum. The teams conducted them because they’d identified specific, concrete needs that standups could satisfy. In other words, they used the practice out of choice, not because the contextual process prescribed it.

    IT more and more operates in a world of speed and complexity. The very definition of “good” or “right” continuously shifts. By the time we can “properly” adopt a contextual practice (assuming we ever can), the requirements that drove that adoption likely have changed. In such an environment, we may be better served by continually exposing ourselves to simple yet effective composable practices, and experimenting with combinations of them. Rather than trying to effect global, permanent transitions from bad to good, we may be better served trying to effect local, iterative, ongoing transitions from any given current state to a new state that is better in some concrete way. We can thus use composability to weave continuous improvement into our fundamental approach to tools and practices.

Notes

  1. ingineering posted this