Own Your Work
This post is mostly here to share a link. Jeremy Miller posted ‘“Code Complete” is a polite fiction, “Done, done, done” is the hard truth‘. Before clicking through I thought I was going to disagree. After reading through, I agree 100%.
Read it first, it’s not long…
Done? Now my take on this:
Stop being lazy! I have been in places where the process has become one where you take the requirements from somebody else, do your best to deliver, and then throw it over the fence for QA, testing, or whoever. In my experience, this makes people less accountable for what gets pushed to production.
Own your work. Some of the best quality I have ever provided was in an environment where I was the one in charge of understanding problem, coming up with the best appropriate solution, and watching it all the way to production and eventually, the user.
The key ingredients to this recipe for success:
- Quality tests – sometimes TDD, sometimes test first, and sometimes test after.
- Refactor to your heart’s content – if you’re afraid to change code because it might break something, you have problems. Follow SOLID principles as best as you responsibly can and you’ll have fewer problems here.
- Continuous integration – make sure everything is working all the time. It helps in the long run (and by long run, I mean tomorrow). Oh, and by CI, I mean CI done right.
- Collective code ownership – everybody owns this feature; it’s not just my own. a.k.a. No silos. Also, your victories must be shared, but your failures are also not your own.
- Deploy early and often – The best time to deploy a feature is the moment it’s declared “Done” (or Done, done, done). The longer the span between this time and delivery, the more likely it is to fail.
Your mileage may vary, but these have worked for me and I suggest you try them if you’re having trouble moving quality from concept to cash.