Look, we need to be able to do things quickly…
We don’t need any extra overhead, it’ll just slow us down.
Why do we need that? We’re doing fine.
These are just some things I hear routinely from people in the software industry. Software development is still a young industry, relatively speaking – construction, law, business, and umpteen others have been around for ages. As a result, they’ve had cultures and “ways of doing things” firmly established. That’s the key here: ways of doing things. The software industry has barely had enough time to decide on the best way to do things, not to mention the vast majority of companies are hardly at the frontier of software process.
Why the hell should I care?
Let’s say we’re working on a Mars lander and need to swap out the rocket being used for slowing it down as it approaches the Martian surface – some extra weight has made it necessary to install a slightly larger nozzle, so we need to make adjustments to timing and fuel usage to make sure it lands safely.
We find the snippet of code we need to modify and proceed to change the numbers according to what our rocket scientist colleagues have computed for us:
void landingSequence(Position position, Booster booster)
{
while(postition.altitude > 100)
booster.ignite(1, .1);
while(position.altitude > 10)
booster.ignite(2, .3);
while(position.altitude > 0 && position.speed < 0)
booster.ignite(5, 1.0);
}
Obviously, since we have a bigger booster, we’ll need to adjust the timing, duration and burn amount. We proceed to change the numbers, and since this is such a small change, we commit straight to the default branch in the Mercurial repository and push our changes. Bam – changes done in about 5 minutes, and we get back to whatever it was we were doing before.
Sweet – instead of going through some kind of overhead crap, we probably saved ourselves an hour of code review time, times however many people would be involved, and it’s another change marked completed on the todo list up in front of the office that everyone has visibility of. Well, not so fast. Unbeknownst to us, the original developers for this code snippet were using the units their rocket scientist, a different dude, gave them, that being metric units, whereas our rocket scientist, having just started a couple weeks ago, has given us calculations in imperial units. Well…booger. 12 months later, as the lander descends, we witness the quality of our work as the lander slams into the surface of Mars and pancakes about $125 million worth of hardware. Sweet.
Now let’s say we inserted a small little piece of process – a code review. Yeah, it’ll eat up some time and we won’t be able to knock that issue off of our todo list quite as quickly, but the code will be looked at by a handful of other people and the glaring and obvious error of unit choice will be pointed out and corrected. Lander peacefully touches down on the surface of Mars, and does its awesome science experiments where we find out there’s life on Mars. Cool.
Time for the dramatic before and after shot – without any process whatsoever, we saved ourselves about five man hours (our one hour of review time plus the other four humans looking at the code) and got our task done pronto, but we ended up losing the 12 months worth of effort on the entire team’s part as well as $125 million worth of hardware components and all the fuel and time that was used up just putting the thing into orbit; now we need to make a new one, test it, put it into orbit again, and hopefully this time it lands – taking yet another 12 months and an additional $125 million. With just a hint of process, we ate up a little time up front, but saved ourselves a lot of time and money in the long run.
Granted, this was an extreme example to purposely illustrate the drastic savings realized by putting just a small bit of process into the mix. In reality, it’s a lot harder to justify adding process overhead because the cost savings is smaller and therefore harder to notice. Over time, however, all that savings adds up to a lot.
Alright, fine. What now?
Every company is different, and the culture at each is what matters. More often than not, instituting a little bit of process will feel like pulling teeth from the entire development team. The keys to success in these kinds of situations:
- Don’t do much too quickly – start out slow and do little things incrementally. The flat-out rejection of anything will slowly give way to a let’s try it out attitude over time.
- Tailor the process to your needs – a gas-guzzling 3-ton pickup does not meet everyone’s needs. Likewise, not all development processes will be suited to yours. Take out things you don’t need and add things you do.
- Continually modify as necessary – Always look back and see what worked well and what didn’t, and change things that need to be changed. If you keep trying to fit a square peg into a round hole, you’ll end up with splinters and bloody hands, and probably some of your team at a different company.
- Look for feedback from the infantry – the people carrying out the process day-to-day are obviously the ones with the most exposure to it and will have to deal with whatever you make them deal with. If your foot soldiers stop doing part of the process, the respect for it is lost and you might as well be back where you started. Make sure they’re on board and appreciate what’s happening. If they don’t, figure out how to get them there.
It’s good for you, trust me.
Hopefully after reading this you’ve agreed at a high level that process isn’t necessarily bad. In fact, it’s generally a net gain. I guarantee that if your team puts some process into place and adheres to it judiciously, you’ll see an overall decrease in downstream defects and an overall increase in code/product quality.
You must log in to post a comment.