Common Approaches versus Creativity
As a software architect, I need to help a number of teams of developers build systems towards a common goal and future. A few years back, I tried to capture what I was aiming for in terms of a balance between commonality and creativity. I think it still holds true, so here it is:
Having a common approach is not meant to discourage individuality. Individuality and creativity are both actively encouraged and sought out. After all, it is from such creativity that our current infrastructure arose. It is important to realize that the current infrastructure is the result of factoring out the common needs of what were originally separate approaches. Effort was then applied to these factored-out needs to create high-quality reusable components that meet "the common need".
Therefore, when an solution has a need, we analyze it to see if it is met by the common infrastructure. When it does, we conform and use the existing reusable components consistently across the team. When it doesn't, we solve it in the specific case, but make note of it. When future solutions arise with similar needs, we may factor out the solutions' specific needs to see what they can contribute to the common infrastructure. Sometimes they can, and we get new high-quality reusable components, and sometimes they're solution-specific (at the moment) and they stay that way.
The philosophy behind this is that the code is owned by the group and not by the individual, because it must be maintained by the group. Therefore it should meet the needs of the group, and therefore conform where appropriate. However, to remain agile, the group must adapt to new and different and conflicting needs. Those needs are best met by harnessing individual (and small-group) creativity which feed back into the common code base.
Evolution of the common approach benefits the larger group. We try to guide the creativity of the individual to support the evolution of the larger group. Evolution of the individual without respect for the group threatens to undermine the group and the common approach. Recognized evolution of the individual in support of the group leads to a better group and expands and updates the common approach.
We encourage justified creativity and individuality in the context of building a common infrastructure. Simply put, the trick is to encourage creativity but to not do things in a different way for no other reason than to be different. A common infrastructure and a common approach both have benefits that should not be ignored.
1 Comments:
At 10:55 AM, Tide said…
One of the things I've come to believe is that you need "process" -- whatever you want to call it -- to sustain people day in and day out, and not for only a particularl project or crisis. I think you have to have some level of systematization at both the technical infrastructure level (e.g. CVS, webdocs, wiki's, test crons etc), but also at the poorly definable people level (e.g. time scheduling, ticket flows, how urgency is communicated, how priorities are communicated, how status is reported, etc.). You have to give people like you suggest some order they can depend on. The balance is making creativity and goodwill possible while encouraging some degree of rigour in method. People who probably aren't that experienced, or only experienced in narrow methods, will clam up at that because they'll say free expression and good management are mutually exclusive. The point is for me you have to have some order in a dev process to both foster creativity and to support people exactly when things get hairy and best-solutions may have to wait. You'll never have real innovation or sustained good productivity if the place is too rigid or too sloppy. Inevitably, both situations just demand "more dogs" and that's eats people alive.
Post a Comment
<< Home