Tuesday, December 16, 2014

Taking Ownership Of What You Deliver

Taking Ownership Of What You Deliver.

Almost a year ago I started a software development company as a way of creating and delivering projects outside of my full-time job with the desire to keep any intellectual property separate from what I delivered through my 9-to-5.
One of my favourite things about software development is being able to put an emphasis on creating working software instead of obsessing over intermediate progress gates and deliverables.
Over the past year I've learned a few things along the way, personally these observations have helped myself personally grow towards being more aware of what I am producing and delivering.
Quit being lazy! For many organizations the process has become one where you take the requirements from somebody else perhaps a business analyst, do your best to deliver and make deadlines, and then throw it over the fence for QA, testing, or whoever. In my experience, this makes many people less accountable for what gets pushed to production.
Own your work. Some of the best quality I have ever personally and professionally provided was in an environment where I was the one in charge of understanding the problem, coming up with the appropriate solution, and watching it all the way to production and eventually, the user.
The key ingredients to this recipe for success:
  1. Good unit tests – the benefits of testing are endless, I'll leave this for a future blog post.
  2. Do Not Fear Refactor! – 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.
  3. Continuous Integration – make sure everything is working all the time. It helps in the long run (and by long run, I mean tomorrow). don't commit broken builds, take the time to keep your own house in order.
  4. Code Ownership – everybody owns this feature; it’s not just my own. a.k.a. Stop putting yourselves into silos. Also, your victories must be shared, but your failures are also not your own.
  5. Deploy As Often As Possible – The best time to deploy a feature is the moment it’s declared “Done”. The longer you wait between this time and delivery, the more likely it is to fail.
Your experience may vary, but these have worked really well for me and I would suggest you try them if you’re having challenges moving quality from concept to deliverables.

ThinkMonkey - Web Design Company | Software Company