Tag

Programming

The Truth about DevOps

By | Development

DevOps seems to be the new cool kid on the block lately, especially in Agile circles.  New user groups are popping up and it’s a fashionable topic to talk about at conferences; Many of the more leading edge consultancies are working hard to establish themselves as having creditable practices in the space.  Right now DevOps feels like Agile did 10 years ago.

Here’s the first paragraph from the top hit in google, it is of course from Wikipedia …

“DevOps is a set of processes, methods and systems for communication, collaboration and integration between departments for development (applications/software engineering), technology operations and quality assurance (QA)”

… and it’s 100% wrong. DevOps isn’t a process; Unlike Agile, DevOps doesn’t have a neat set of rituals to build the habits and enable the right communication and feedback cycles – perhaps we need to invent some.  There are definitely some things like co-location which help, and getting everyone coming along to one daily standup isn’t going to hurt. But, you can do those things and fail to create DevOps.

Here’s another thing it’s not, Continuous Deployment.  Releasing your software regularly and having an automated build and testing pipeline is another good process, it creates good habits and it does create closer ties between your developers and your ops group; But it’s not essential to DevOps and it doesn’t ensure you’ll have DevOps.

So here’s what it really is:

  • Developers caring about deployment and production systems.
  • Ops caring about the development of new features.
  • Developers with access to production systems, monitoring and deployment processes.
  • Ops engaged with feature development from the start.

It’s about creating a team of engineers, rather than a team of developers and a team of operations folks.

DevOps is just a neat new word to describe how little companies have managed their development and deployment for years – If you don’t have many people and you don’t have lots of departments then your developers get involved in deployments, and if you’re lucky enough to have a dedicated ops person then you can be sure they will be working with the development team as well, usually on the database and back end parts of your system. In bigger companies it’s not as simple, bigger systems mean more complex platforms, more sophisticated network configurations and database clusters.  As projects get bigger it’s only natural, even essential that within your engineering team there are specialist roles.  UI/UX specialists, back end, API and model specialists and DevOps is about engaging staff who would have previously been part of your ops team.

Just like Agile, DevOps means taking a leap of faith and seeing how things work out.  Here’s how to start, get a developer to sit and type all the commands to deploy one of your system with an ops person looking over their shoulder – I promise you they will be coming up with ways to automate your deployment by the end of the day.  Next time you have a performance problem, get your ops folks to pair with the developer working on it, matching up data from your system logs and monitoring system with the active code.
Just today I enjoyed watching a ‘developer’ and an ‘admin’ working together to shave 20% off the run time of our full test suite in 30 min just by building a shared understanding of what was required and tuning the platform together.

“‘Devops’ is a movement of like-minded sysadmins and developers interested in bridging the artificial gap between our camps. It’s impossible for sysadmins to do their job without reading or writing code, and developers need intimate systems knowledge to scale their software.

The walls between us are being broken down — it’s time to start learning from each other.” – www.devopsdownunder.org

“You can’t control what you can’t measure” – Tom DeMarco recants on his famous principle.

By | Agile | 2 Comments

Tom DeMarco

Governance and funding of business investment using agile development methods are two hotly debated and misunderstood topics among the agile community.

With governance principles originally borrowed from the exacting fields of construction engineering and accounting, where things can often be calculated to 2 decimal places, it seems weird that we more often than not disappoint our customers by delivering a different result to that which was blueprinted or planned in software ‘engineering’.

Fred Brook’s 1975 treatise The Mythical Man Month was probably the first to hint at the

core differences between engineering a bridge versus the knowledge work of solving a problem by creating code. In the 20th anniversary edition he added an extra commentary entitled ‘No Silver Bullet’ in which he further reflected on the shortcomings of applying a mechanical engineering metaphor to software development. It is a must-read book for everyone involved in agile or lean development – and if you’ve read Clay Shirky‘s 2008 book Here Comes Everybody you’ll recognise some early sources of Clay’s work on complexity of organisations.

By the way Clay Shirky also has my favourite definition of governance – ‘rules for losing‘.

Fred aside, one of my greatest heroes of the software world is Tom DeMarco, who wrote the seminal text on project and engineering control called Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982). But this one is a book you probably do not want to own. Why? Well, approaching 70, Tom gives us the benefit of his time to reflect in the newsletter of the IEEE Computer Society in 2009, downloadable here:

http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf

My favourite quote, which describes in a nutshell why measurement and management aren’t as closely linked as he surmised 27 years earlier:

“Imagine you’re trying to control a teenager’s upbringing. The very idea of controlling your child ought to make you at least a little bit queasy.

Yet the stakes for control couldn’t be higher… now apply “You can’t control what you can’t measure” to the teenager. Most things that really matter–honor, dignity, discipline, personality, grace under pressure, values, ethics, resourcefulness, loyalty, humor, kindness–aren’t measurable.”

And a lot of product deliveries and projects I’ve been involved with acted way more like moody, irrational, changeable teenagers than respectable septuagenarians.

Subscribe to the Luna Newsletter

Quote of the week

The new competitive advantage is the ability to anticipate, respond and adapt to change.

Recent Luna Posts

Become Remarkable.