Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

A Unified Theory of Software Karma

DZone's Guide to

A Unified Theory of Software Karma

· DevOps Zone
Free Resource

In response to accelerated release cycles, a new set of testing capabilities is now required to deliver quality at speed. This is why there is a shake-up in the testing tools landscape—and a new leader has emerged in the just released Gartner Magic Quadrant for Software Test Automation.

I make a lot of jokes at work about code review karma.  Here's the idea: each time a person volunteers to review others' code, that person build their code review karma.  Then, when it comes time for that person's own code to be reviewed, the reviews go smoothly due to the store of code review karma.

Build karma works the same way.  When someone jumps in to help fix the build, they're accruing build karma.  Thanks to build karma, the builds that kick off from that person's own commits are far more likely to be successful.

If you have a lot of time on your hands, you can actually see software karma all over the place: QA karma by helping out your testers, refactoring karma by cleaning up the scariest bits of the code base, planning karma by leading sprint planning, etc.  The more you help, the more the software gods reward you in the future.

I see two explanations behind software karma.  The first is that there actually are software gods who sit upon Mount Codelympus and keep a running tally of all these helpful acts.  They probably keep this tally in Emacs, since that was clearly not designed for mortals.  If there is any truth to this explanation, then let's all quickly sacrifice a 'PHP for Dummies' book to appease them.

The other explanation is less exciting, but slightly more practical.  By reviewing others' code, you build a mental model around what great code looks like.  When you go to write your own code, you apply your model and reap the rewards immediately.  By fixing broken builds, you build a mental model around the build process and how it can go wrong; your own builds are far less likely to go wrong thanks to that model.  Same thing goes for helping QA, refactoring, sprint planning, and so forth.

I'm not taking sides on which explanation is correct, since I don't want to get struck by a lightning bolt or incite a plague.  All I do know is this: if you want to get better as a developer, boost your karma.

Recently published 5th annual Software Fail Watch Report identified 606 recorded software fails impacting half of the world’s population (3.7 billion people), $1.7 trillion in assets, and 314 companies. Our advice: Rethink your testing strategies and approach to quality so they’re not finding it in your next release.

Topics:

Published at DZone with permission of Cody Powell, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}