Many years ago on this very blog I wrote the cheekily titled Blodgett’s First Law of Software Development:
A development process that involves any amount of tedium will eventually be done poorly or not at all.
I don’t remember what exactly triggered me to write that down in February of 2008, but I could take a good guess.
This may be a gross oversimplification, but I think that smart people tend to have a low tolerance for repetitive or tedious work. They can’t ignore the futility of what they’re doing.
A way I see this play out in software development is that all those things that developers should do, but are not directly necessary to ship software tend to fall by the wayside given enough time. Testing, documentation, code reviews, tracking hours spent on tasks, and “process” in general.
You can usually tell when an activity is discipline-based, because you’ll notice someone who’s not a developer is constantly hounding the developers to do it. That’s a clear sign.
When it becomes clear that an activity is discipline-based, it’s time to ask: Is there a way we can get roughly the same result while adding less to the discipline burden of the team members?
Why is it that this activity feels so tedious and discipline-based? Maybe some aggressive automation is in order. Computers are damn good at doing tedious things, and you never have to hound them to do it. The necessity of discipline is a sign that something has not been automated yet.
Relying on discipline alone is not a sustainable strategy to accomplish…well...basically anything, at least in the long run. Try to lean on discipline as little as possible.
