Easy To Do Right, Hard To Do Wrong

Easy To Do Right, Hard To Do Wrong

Part of the reason that technology workers are compared to cats (managing developers is like herding cats) is a misunderstanding of how their work is structured.

Quite often rewards are given for doing the wrong thing and the right thing is punished.
Praise is given for pushing a release out before it is ready.
Even more praise is heaped upon them for fixing the bugs in the early release.
Yet more praise is layered on top for tracking down and fixing all the data corrupted by all the bugs that were in the early release.
And on and on.

As a manager of technology workers the goal is to put in structure so the easiest thing to do is the right thing. And it is at the same time hard to do the wrong thing.

Take the one two three combo of 'Source Control is Authoritative' and 'Daily Build' and 'Automated Builds'
By insisting that the only code that matters is the code in Source Control, you make it hard for developers to create local branches that are far out of date with the main branch.

The 'Daily Build' reinforces checking in often and verifying that all local dependencies are fixed.
The 'Automated Builds' make it easy to verify that the checkin have not broken the code.