Today is towel day, but due to higher priorities I have to celebrate this important day all by myself. I can’t make it to Innsbruck this year, but I swear to you that I’m wearing my towel around my neck while I’m typing this blog entry, which I dedicate to Douglas Adams.
Few people know that his idea about “The great question of life, the universe, and everything” (to which the answer is, as everybody knows, “fourty-two”) was in fact a little bit inspired by Isaac Asimov’s great short story “The Last Question“, where generations after generations build more powerful computers to find out how to reverse entropy and thus prevent the universe from becoming an infinite starless nothingness. “The Last Question” is a great read with a surprising end. I won’t spoil it, don’t worry.
While it is impossible for humans to stop “real” entropy from increasing (let alone reversing it) it is certainly doable in the software world. But how?
It’s not by carrying out the big refactorings and redesigns that nobody wants to do and that no profit-oriented organization can afford: for months valuable resources are so busy cleaning up instead of implementing cool features customers are willing to pay for. It’s the small stuff that counts: the teeny-weeny improvements that you do on a regular basis. Like James O. Coplien said: “Quality is the result of a million selfless acts of care”
I very much like Uncle Bob’s boy scout rule analogy: “Always leave the campground cleaner than you found it”. This principle is helpful for life in general and software development in particular. If the system you are working on is a complete mess, don’t resign. Even if you just improve a comment or rename a badly named variable, you have made the system better. Then, if everybody acts like you, software entropy will be reversed.
If you watch one of those famous chefs on TV, you get the impression that cooking is both, fun and easy. A chef knows instinctively how to combine spices and how long the meat has to stay in the oven to be just perfect. That’s a clear sign of true mastery: masters have become one with their tools, materials, and processes; to a layman everything they do looks so simple.
What the audience usually fails to realize is that these chefs are not just great cooks and entertainers: they are also entrepreneurs, managers, and coaches. They usually run at least one big gourmet restaurant, they do the marketing and goods procurement, they write books, they hire people and train apprentices such that they someday can become great cooks, too. To sum it up, they are experts at their craft and possess other important skills at the same time.
Contrast this to a traditional software company, were you have managers managing people and developers doing the programming. Managers usually don’t do any coding and probably haven’t done much coding in their life. Most likely, they are the least-qualified to write solid, production-quality code. And yet they are in charge of strategic decisions, including hiring new developers. A master chef, however, is the most-qualified person to do the cooking and because of this is the most-qualified person to make strategic decisions.
In my view, a traditional non-coding software manager is a relic of the industrial age. The obvious waste is that such a manager does not actively contribute to the main asset, ie. working software. But there is more: not being a skilled software developer with first-hand up-to-date experience, a manage-only manager will face difficulties in many areas: first in finding and selecting talented people; second, in being a mentor and role-model for developers and third, in convincingly educating upper management about intrinsic software-related problems. Especially the latter weakness is a constant source for disappointment and grief in many companies.
The classic apprentice/journeyman/master model has proven timeless over centuries. It promotes people who master their craft and have the right management and social skills. Possibly the biggest advantage is that in such a system managers (“masters”) are still allowed to pursue their craft. Being able to do what one loves to do the most is good from a motivational point of view and leads to continuous dissemination of knowledge and best practices.