The stuff we do, in more detail

Developers: frantic to free in 6 easy steps (part 1)

Any developer who has worked in a small shop has experienced it (and undoubtedly developers in large shops too): the boss, who used to be a developer himself comes and asks for a "small feature" which "just needs to do X".

He sits down at your desk and says: "Let’s get started!"

This post will not help you solve that problem.

However, that method of development causes a host of issues that all lead to what our team began calling "Release Day Insanity." We were a small team with strictly internal (employee) end users so it wasn’t too bad, but at the end of the day,that’s a terrible way to approach software development. Our customer-facing development was having similar issues on a smaller scale, so we set out to fix the problem and create a repeatable process that they could model after ours when it had been working well for a while.

This is our story — it isn’t ground-breaking, and it isn’t meant to be "best practices", but it’s a pragmatic approach to a common problem for people with very little time to invest in infrastructure, and little to no QA support. We evolved this over the past year, and as we saw a problem, we gave it a swing (and sometimes a miss).

Note: I would highly recommend giving each of these a shot in a way that fits your team. I would also recommend trying to implement each one at a time. If you spend time focused on each step, tweaking where there’s pain and adjusting to your team’s personality you’ll find everyone owning the end result. You’ll also show them you don’t know everything and need their help figuring some of these things out, which actually helps build a stronger team.

Enough of the pomp and circumstance… here’s what we did, pretty much in the order in which we added them to our process:

Unit testing

Code review

Continuous integration

Daily stand up

Iterative requirements gathering

Lightweight develop/test/release process

So let’s get rolling with step one: Unit testing

Unit testing

There’s a LOT of conversation and blogging going on about unit testing and TDD. They are not the same thing, but TDD is about creating unit tests, and people who unit test typically practice TDD. My advice is to just pick a method for getting unit tests into your code base and start doing it. Like many have said before me, it’s hard. When you have “real code” to write you want to sit down and write it, not fiddle around with test code. But the diligence will pay off if you do it right, I promise. Having just come out the other side, I can attest to two facts: it will slow your development cycle down, and it will drastically improve your release day experience.

I don’t want to dwell too long on the first of those facts, but it’s true and I feel like I need to help dispel the idea that the longer development time isn’t worth it. If unit testing is done right, that’s like saying that having a database backing your system isn’t worth it. Sure it’s faster to write code that just saves stuff out to files, but a year from now SOMEONE will want to see a trend analysis, or you’ll need to add something to all 250,000 products and you’re hosed.

The second fact is the real motivator for me. Unit testing forces developers to think about the edge cases and hopefully, the uncommon-yet-frequently-encountered-in-production scenarios. Even if you go out with some bugs, the unit tests you have can easily be duplicated and modified to recreate the bugs, both proving you fixed it AND preventing a regression down the road.

This discipline is hard to develop, and often times it’s also hard to get your boss or boss’ boss to buy in. We just buckled down and did it for a couple releases and when they noticed things getting better, we told them why. That was a HUGE win for our team!