Steve Neely

R&D Engineer

Steve Neely is officially a software engineer at Rally. In reality, he gets to play with a broad range of technologies and systems, attend and present at conferences, and write about all the cool stuff he discovers along the way. His current focus is on continuous delivery, big data, service-oriented architectures and software craftsmanship.

Steve's background is in researching the design, construction and management of globally distributed systems. He has worked at top-ranked universities across the UK and Ireland as a researcher and teacher. Steve has produced a broad corpus of research publications and organized conferences at an international level.

When Steve is not teaching Ruby at Rally, wrangling Clojure code or pushing data around Cassandra clusters you can find him rock climbing with his team or skiing the powdered slopes of Colorado.

More posts from this author

Post Date: 02/11/2015
Last Comment: 1 year 7 months Ago
<photo via
Post Date: 10/17/2014
Last Comment: 1 year 11 months Ago
DevOps for startups! DevOps for new projects! DevOps for a 10-year-old code base? Um ... okay ... If you’re getting started with a shiny new product and a new deployment pipeline, DevOps is easy (well, easy-ish.) But what if you’re not just getting started? What if you’re working on a 10-year-old code base, and want to adopt DevOps… and then continuous delivery… then continuous deployment? How will the product team and business react?
Post Date: 07/22/2014
Last Comment: 2 years 2 months Ago
We practice continuous delivery at Rally. This means that every commit to our master code branch is thoroughly tested, and builds a deployable artifact that could safely go to production whenever we choose. Many of our services go one step further: continuous deployment. Continuous deployment is the next step after continuous delivery. Every commit to master that passes all our automated tests, test deploys, and monitoring will go directly to production -- with no human intervention.
Post Date: 07/11/2013
Last Comment: 3 years 2 months Ago
Abusing Java is all too easy. How many times have you written code to manipulate a string for-looping with s.length(), chopping out substrings, regex splitting and munging it all back together again?  
Post Date: 04/01/2013
Last Comment: 3 years 5 months Ago
One of the many fantastic things about working in Rally Engineering is that we’re given the freedom to research. Our latest expedition was a foray into the world of alternatives to the Java programming language.
Post Date: 12/10/2012
Last Comment: 3 years 9 months Ago
We were asked a tough question by one of our customers: “is a team leader of a dev team needed?” I say yes and no and sometimes. In 1965, Bruce Tuckman proposed the Forming – Storming – Norming – Performing model of group development. This simple model describes the phases teams roll through from their first meeting to becoming all-stars.
Post Date: 07/31/2012
Last Comment: 3 years 10 months Ago
Ten years is a long time for a human. In compute cycles ten years rivals the age of the universe (think dog years but way faster). Rally just turned ten and our codebase is getting a facelift. Our existing weekly deployment process approximately looks something like this:
Post Date: 06/01/2012
Last Comment: 3 years 10 months Ago
Rally Software engineers move towards faster builds, tests, releases and value delivered to customers by using lights that track their builds. If all tests pass, the lights go green; and if any test fails, the lights go red. By blocking the engineering team with a working agreement that says "you cannot push code when the lights are red," immediate remedial action is taken when something breaks. Using a build light system makes Rally engineers' tests blazingly fast, reliable, and trusted by the team.
Post Date: 04/01/2012
Last Comment: 3 years 10 months Ago
How well does production survive in the face of all-out failures? Enter the Rally Chaos Raccoon. Opening up your production systems to wildlife attack demonstrates confidence in monitoring, recovery, and backup processes. It stretches your failover strategies to their limits. You may think your systems are ready for anything but when a raccoon attacks there are no rules.
Post Date: 03/16/2012
Last Comment: 3 years 10 months Ago
Help! My Java application keeps crashing! OutOfMemoryError?! My hair is on fire! Please don’t let the invisible fire burn my friend!!! 1. Increase max heap size


Request a Call

Looking for support?

Send Us Your Feedback

Provide us with some information about yourself and we'll be in touch soon. * Required Field