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.
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!