Automate [More of] the Things
This post comes from Matt Sneeden at the New Relic Blog.
When companies hire, it’s typically to fill a specific role. That being said, it is in the best interests of an organization to maximize the time that the person is doing [enter job role] — coders coding, testers testing, managers managing, etc. The reality is, we all have to do things outside of our specific role from time to time. These experiences broaden us, lead to cross-training and give us a better ‘big picture’ view. However, before the infrequent outside task(s) become more frequent and time consuming, it’s important to lookout for ways to maximize the time you spend doing your job.
What Am I Getting At?
Earlier this year we blogged about our efforts to revamp our build and release process. We highlighted how by minimizing complicated, manual efforts we were able to dedicate more time towards creating the best solutions for our customers. While physically delivering software is very important, none of the steps required much of our skill set. However, the amount of time each release required significantly reduced our productivity.
We’ve used that effort as a launch pad for making other improvements above and beyond simply getting software out the door. Once you’ve begun to optimize your time, it soon becomes addicting. As you’re able to ‘optimize out’ one mundane process and reap the benefits, you immediately being looking for the next … and the next … and the next.
There are a number of things that happen both before and after a release. Stories and issues must be updated, release notes created, versions tagged for release and so on. Then on the other side of a release, the process starts again — new version, new tag in source control, etc. Any one of these items alone are quite simple to do as they happen fairly infrequently and don’t require too much time. It’s when you start adding up all the little pieces that you realize the recurring cost in people hours. This again is all time that is taken away — from a coder, a tester, a manager — whose time is frankly more valuable elsewhere. Whatever tools your team is using for source control, project management, bug tracking or the like, leverage APIs and other interfaces to find ways to automate and improve. My guess is, when you automate more of the ‘little things’, you’ll find that it adds up to quite a lot of time saved.
Let’s also talk about environments. And no, I’m not talking about the state of your desk or the plant in the hallway. I’m talking about platforms, operating systems and frameworks. The .NET agent, like most others, is supported across a variety of platforms. Depending on the type of feature in development, it’s essential to verify the functionality across many, if not all, supported platforms. In past projects, more than just a couple of minutes time was allocated for ‘configuring environments’ for testing or debugging. Granted this could easily be considered ‘just part of the job’ for a Dev or QA engineer, but in my opinion this represents a golden opportunity to improve the process and maximize the time testers are testing or coders coding rather than configuring environments.
When testing finds a defect or a customer reports an issue, it’s far easier to have methods for spinning up environments that everyone can make use of, instead of a ticket that says “Spin up a Server 2003 Enterprise instance, configure this server role, install these patches, this software, our agent, debugging tools …THEN, do these 5 simple steps. And, oh and don’t trash the instance or you’ll have to start from scratch.”
We’ve recently spent some time working on scripting the creation and configuration of a few flavors of virtual machines across a handful of platforms. We don’t yet have a full configurable stack at our fingertips, but we’ve already been able to reap some rewards. During the testing of our recent Status Monitor tool, this proved to be invaluable and a significant time saver. One engineer was able to identify OS or architecture specific bugs and simply re-configure a VM and hand off an IP address to another engineer to dive in and fix the problem. The developer was free to debug and experiment at will, with no fear of trashing the VM or making risky changes. And in the worst case scenario, the VM could be restored in a couple minutes. This saved us countless hours during the final testing phases of the project as we cycled through nearly 10 different instances of operating systems or architectures.
Get to it!
The lesson here is don’t stop at the big manual processes. Look beyond to the clusters of smaller tasks that may be lurking in the shadows. When you add them up, they may not seem so small. Determine what toolsets or methods you have at your disposal and get automating. I bet you’ll have a blast integrating toolsets, working with different APIs or scripting environments … I know we did!
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)