Kreg Jig

I had mentioned in Does running the QA team tests during coding slow developers down? that one developer was practicing red-green-refactor. I actually learnt about this from the dev lead. He had messaged me to ask if anyone from management was paying attention to what was going on; my answer was no. Here’s the story he told me to the best of my recollection 4 years later.

There was a scary new feature but the dev team was under-resourced because the managers decided to reduce the head-count by removing some of the senior most developers. So out of necessity, the feature was given to a new-grad. This new-grad had maybe a year of COBOL experience from having worked on the code as a co-op student. Here’s the list of things that were expected to happen

  1. They wouldn’t know what to change and break things
  2. They’d need two senior developers taking turns reviewing their work when they had the time
  3. Those same developers would probably have to make changes
  4. When the code was integrated, the new-grad would probably have broken the build
  5. When the code was delivered to QA, we’d have defects in everyone else’s work as a result.

When I was told this, I was surprised because I didn’t hear of any such disaster. It turns out that’s because none of that happened. Here’s what happened.

  1. Red: The new-grad took the tests as they were written and ran them first. He used them as a search engine to identify which parts of the code were affected.
  2. Green: Then he only changed enough code to make the test pass. After that he’d run QA regressions for any suites affected by that module.
  3. Refactor: As he was done, he paired up with the senior devs who review his work and they refactored it and ran the tests to make sure they didn’t break anything.

I’m a wood-worker and so I’ve come up with a way to explain why running the tests in advance makes a difference.

There’s 3 parts to making the cabinet box.

  1. A specification
  2. The box itself
  3. A jig to make holes for screws. If you don’t know what a jig is, check out this site

Now consider these approaches to making that box

  1. You read the spec, make the box, then ask someone else to check it for issues
  2. You read the spec, make the box, make a jig that fits the box, then ask someone else to check it for issues
  3. You read the spec, make the box, then use the jig as a template to check for issues. If there are some, you correct it and try again.
  4. You read the spec, use the jig to guide you and then make the box.

I hope you’d agree that number 4 is the best approach. Let’s try the same approaches but I’ll swap test code for jig and main code for box

  1. You read the spec, make the main code, then ask someone else to check it for issues. The no unit test approach.
  2. You read the spec, make the main code, make test code that fits the main code, then ask someone else to check it for issues. The unit tests after coding approach.
  3. You read the spec, make the main code, then use the test code to check for issues. If there are some, you correct it and try again. The senior dev who knows what they’re doing but makes mistakes approach. The developer that delivered the code late did this.
  4. You read the spec, use the test code to guide you and then make the main code. The red-green-refactor approach. The new-grad this.

There’s a lot more to this but for now I wanted to document what happened when this was attempted with COBOL.