The human case for acknowledging and measuring wasted time
Acme Corporation is a famous software company employing around 2.000 developers. Like many other companies out there it has ensnared its faithful employees in a devious plot. It is murdering them, legally and out of sight, by wasting their time.
Acme Corporation is proud of its unified software development workflow. Despite multiple acquisitions, all of Acme’s developers share the same way of working. This means Acme can act swiftly on new market opportunities because re-organizing teams and shifting resources around is easy.
All of the teams have adopted and love Continuous Integration. However, mistakes can still slip through and break a project’s master branch. But, it’s no big deal, these are highly motivated developers who are always quick to fix the build right away.
And this is exactly how Acme Corporation legally murders a developer every year. “Hang on. What?”
Let’s do some back-of-the-napkin maths. Let’s say each developer wastes around 8 hours per week on fixing broken builds. Granted, that’s rather high, but let’s roll with it for now. With 2.000 developers, that’s 16.000 hours wasted by broken builds per week, or 2.286 hours per day. As puny humans we only have around 700.000 hours to live. One can therefore conclude that Acme wastes an entire human life every 306 days with broken builds alone.
Acme doesn’t exist, but there are many real corporate behemoths out there trampling their employees’ precious hours underfoot with poorly optimized marches for profit. The Acmes of the world often don’t acknowledge such waste, so they can’t work to remove it by, say, adopting pre-tested integration. The question is, how can you, as a faithful employee, prevent yourself from being slowly murdered at your desk?
Many (all?) developers complain about having their time wasted, but few actually get up and do something about it. Fewer still manage to do anything besides waste more of their time. Waste definitely isn’t removed by complaining, nor is it removed by lone cowboys. No, removing waste starts with acknowledging and measuring it.
So, when you end up wasting time due to a failure or manual task don’t shrug it off. Ask yourself, has this happened before? Could it happen again? If so, record the time you lost. Even a rough estimate is fine.
Once you have a few data points extrapolate and do some quick maths. Find out who owns the problem. If the company loses around three days of time per month to an issue, and six days of the owner’s time could resolve that issue forever, that’s a pretty clear return on investment. Sharing these numbers with your team, manager or boss is a great way to make sure the issue gets the attention it needs and is resolved properly.
Or, you can continue to sit there complaining at your desk, waiting to be murdered.
Looking for reading material on tackling waste besides my humble post? Check out the following brilliant book by Nicole Forsgren, Jez Humble and Gene Kim:
Continuous Integration and Code Review are strongly correlated with success. Many use Pull Requests for code review, but for co-located teams this can be an obstacle for CI. Is there a better way?
A short story about Pre-tested Integration
A developer that pushes their changes and goes on a celebratory walk to the water cooler is done. But, they’re not done done, their changes have yet to be thoroughly tested, added to future release notes, properly peer reviewed and more. These are pains we want to rid the software industry of, and here’s how we do it.
How we tell the Continuous Delivery story
Had enough of sluggish polling? With instant Artifactory event triggers you can give responsiveness in Jenkins a real boost. Here’s an easy way to set it up.
A super easy configuration guide
With the arrival of microservices code is becoming disposable. Does this mean that we no longer need maintainable code? Is it the end of refactoring?
Still relevant or increasingly redundant?
In software development tight coupling is one of our biggest enemies. On the function level it makes our application hard to change and fragile. Unfortunately, tight coupling is like the entropy of software development, so we have always have to be working to reduce it.
How to safely introduce modular architecture to legacy software.
I am an Atlassian certified trainer and over the years I have been spending much time with clients and their Jiras. In this blogpost, I have collected some small tips and tricks that will make your Jira usage better.
Jira Software is a powerful tool deployed in so many organizations, yet in day to day usage people are missing out on improvements, big and small.
In this post, I’ll take a closer look at the version of Jenkins X using Tekton, to give you an idea of how the general development, build, test, deploy flow looks like with Jenkins X. How does it feel to ship your code to production using a product coming from the Jenkins community that has very little Jenkins in it?
A crash course in Jenkins X and how to test it out on a local Kubernetes cluster
In this blog I will show you how to create snapshots of Persistent volumes in Kubernetes clusters and restore them again by only talking to the api server. This can be useful for either backups or when scaling stateful applications that need “startup data”.
Sneak peak at CSI Volume snapshotting Alpha feature
When I read Fowler’s new ‘Refactoring’ book I felt sure the example from the first chapter would make a good Code Kata. However, he didn’t include the code for the test cases. I can fix that!
Writing tests for ‘Theatrical Players’
Nicole Forsgren and the Accelerate DORA team has just released the newest iteration of the State of DevOps report. The report investigates what practices make us better at delivering valuable software to our users as measured by business outcomes. Read on for our analysis of the report, and how it can be best put to use.
The latest drivers of software delivery performance
Hear about upcoming events in Scandinavia, latest tech blogs, and training in the field of Continuous Delivery and DevOps