Skip to main content
Tag

Software development

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

Why you should try a Hack-A-Thon

By DevelopmentOne Comment

In product and software development organisations there is very often a deep sense of needing to justify all the time we spend working on things.  I catch myself doing the mental arithmetic: is what I’m doing now really ‘adding value’? This is not such a bad thing; we should be striving to create value and generate profits… But I think there is an unintended side effect. Often this desire leads to product development and governance processes that can make development feel like a carefully planned military exercise.  Orderly, neat, no colouring outside the lines but probably not how you would choose to spend your weekend.

Street Performers in Trafalgar Square - People are amazing, unlock their creativity and see what's possible

A Hack-A-Thon (Fed-Ex Day, 20% time or Howhardigras) is a great way to break this culture and remind yourself that passion and invention are powerful and yet often intangible forces that really should try and tap into.  Here’s how you do it:

The Rules:

1) Everyone gets 24 hours.
2) At the start everyone has to give a 1 min pitch of what they are going to try and do.
3) At the end everyone has to give a 5 min presentation of what they made or learned.
4) (optional) Beer and pizza should be served.

Simple eh!  Now this is the bit where you’re going to feel uncomfortable. Don’t have a theme; don’t try and guide or cajole your crew to work on things with a ‘business value’; please, please do the opposite.  Encourage your team to experiment with things that have nothing to do with their day job or write something in a language your company doesn’t use.  Trust me on this and trust your people.

Having done this with countless teams I am still surprised each and every time at just what is possible in 24 hours.  Sophisticated iPhone apps with backend integration finished and ready to upload into the iTunes store.  Sysadmins teaming up with UI developers to overhaul interfaces based on what the admin knows from obsessively watching web-server logs.  Developers learning a completely new programming language and writing significant applications with it.  Product features which would never get through the rigours of a regular governance process and yet go on to be hits with internal and external users.

Allow your teams 24 hours, set them free and you’ll be amazed what they can do.

Subscribe to the Luna Newsletter

Close Menu

Quote of the week

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

Recent Luna Posts

Become Remarkable.