It's an exaggeration to say that a bad day coding for yourself is better than a good day coding for someone else. But today it's difficult to convince myself of that...even after dredging up memories of the "I can't believe they didn't fire me for that" bone-headed things I've done purely on my own initiative.
During the limited times that I've had to impersonate a manager, I've learned that you walk the proverbial fine line when you need to give people the freedom to make decisions--even poorly thought-out ones--yet keep your entire "herd" of features moving at approximately the same pace toward the release date.
Similarly, "ownership" of code is a fine line to walk. Some schools of thought tout communal ownership, which basically turns developers into software kibbutzniks. In all fairness, I've never worked in that scenario, so I can't form what I would consider an informed opinion. I only know that a few arguments in its favor are:
- No one has a valid excuse to be territorial about "their" features. If you don't work around programmers, just trust me that it's an issue.
- Communal ownership encourages cross-pollination.
- Development teams that practice communal code ownership often seem to adhere to a common set of code conventions to make the code more readily learnable.
I imagine--emphasis on the word "imagine"--that it would, superficially, seem quite easy to manage. That is, if you delude yourself into thinking that you can simply announce the collectivization and expect the code to exist on its own plane above the churn and froth of interpersonal dynamics. And, of course, the flip-side of making "everyone" responsible for writing the features and fixing the bugs divides is that the blame is evenly divisible by the number of "everyone" when that stuff doesn't happen.
The other end of the ownership spectrum is to make a someone responsible for the success of each part of the product. In that scenario, accountability--including the responsibility to shout for help while it can still do some good--is clearly established. Parceling out the responsibility for everything also seems like an easy management strategy. Sure, you might have to referee a few food-fights as the code-base breaks off into autonomous satellite republics: Securitistan, Datalayerstan, Guistan, and the rest. But, ultimately, you've made people their own masters, with all the obligation that entails. Right? Except that it doesn't work that way. When you're the manager, you can certainly delegate the project by nickel and dime and even ha'penny--but the buck ultimately stops with you.
So it's scant wonder that I've learned to look at development methodologies with the same jaundiced eye as management fads. Every approach has its trade-offs. Those trade-offs may be skewed toward the favorable or detrimental aspects by the prevailing culture of the organization. A culture, it's important to note, which is never static, even when the personnel remains fixed.
