Programming Analytics

A feed of interesting tidbits from IT, software engineering, business intelligence, and videogaming.

Programming hand-offs

Doesn’t it suck when you build something great, a real shining jewel of a program, only to see the next owner mangle it with careless maintenance and poor planning?

The only thing worse is when you do it to yourself!

The necessity of ownership

Successful organizations make sure that programmers have the ability to own their programs.  It’s vitally important for a creative person to have a stake in the fruits of their invention.  It takes an incredible investment in energy, diligence, thoroughness, and continuous attention to turn a random scratchpad full of block diagrams into a functional, useful program.  Good programmers may make it seem easy, but there’s no faster way to discourage a talented person than to trash their creation.

But, ownership has a downside too.  You can overload your programmers and wear down their motivation if they get stuck on the same work for too long.  You’re probably not Google, and you don’t have a few million dollars lying around to just hire new programmers when the old ones get full.  You’ll also notice that employees do occasionally leave, and to keep the remaining ones happy, you’ll need to give them new challenges from time to time.

Mixing needs

So let’s try to avoid burnout while supporting efficiency: we can rotate ownership, say, every six months or so.  If we do it right, we should be able to encourage many programmers to leverage their own unique insight in turn, and get a better product than if it had been built by one person alone.

  • Use code reviews to prepare a project for a transition.  Try to bring in different people periodically.  Watch their enthusiasm levels, and ask them to share ideas for future improvements.
  • Cross-develop test suites to encourage healthy competition between groups.  Challenge someone new to produce an better validation test, or to investigate new use cases.
  • Performance tuning, or new feature development can also be a good excuse to get new programmers involved.  Try to use a clear, simple, one-time goal in mind for the project to make it easier to gauge success.

Once you get a rotation in place, watch for reactions.  Some employees may be happy to get new tasks, others may regret losing control of their key contributions.  Balance out your well-thought-out plans with the practical realities of day to day management, and don’t be afraid to change your plans if needs dictate.  Happy rotating!