How to make the mental shift towards becoming software factory engineer
Imagine that you’re running a cookie factory. Producing innumerable cookies per hour. What do you do when you discover that the cookies deviate from your quality standard? Do you repair the cookies? Of course not. You repair the machinery. Yet when it comes down to software releases, we have a tendency to repair the releases when something goes wrong, instead of repairing the way we do release management.
Repairing the right thing
It’s not surprising that we developed this ‘repair the cookie’ way of working. Applications used to be released infrequently so it wasn’t worth the effort to streamline and automate the process. But when you think about how things have changed, you realize that it’s worth reviewing the process.
The way we organize our way of working depends on the characteristics of both the systems and the organisation. Let’s look at two examples. We manage large applications that are the backbone of an enterprise differently than smartphone apps that – although very handy as ‘personal productivity tools’ – usually aren’t business critical. On the organizational side, we take different IT management measures in a risk-averse public organization than we would a start-up in which taking risks are part of the business model.
Take a logical approach
So it’s quite logical now that releases are not only deployed more frequently, but also that the organisation is also more dependent on the applications, that the deployment process needs to be make quicker and more reliable. Increasingly, deployment processes are automated using tools such as Capistrano, UrbanCode, Nolio, XL Deploy. But although tooling is a key part of this way of working, the most important part is to embrace the concept of repairing the machinery, not the cookies.
Now if you currently do this work manually, you might see this as threatening. Will your job be safe? Of course it will – it will just be done by a computer. As Warren Bennis said, the factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment. So do you want to be the dog feeder, or the engineer who builds the software factory?
Latest posts by Mark Smalley (see all)
- DevOps in a Baltic business context - October 2, 2017
- IT-Wise, Business-Foolish? Time to Look at the Bigger Picture - May 22, 2017
- A Journey from IT industry Guidance to Business Value - April 11, 2017