Thursday, November 30, 2006

The cost of politics on software development

My gut feeling is that organizational politics introduce a 25% overhead on all software development projects. I strongly feel that a formula can be devised to determine the cost of politics on software development. As a matter of fact when I pondered pursuing a Ph.D. in software engineering I thought this may be a worthwhile topic to explore.

The reason this subject matter is brought up in this blog is because politics are unspoken constraints on a project.

The software architecture practitioners are finally maturing to a point where system’s quality attributes are measured in a meaningful way. For example, to express performance requirements of a certain aspect of a system an architect would create a scenario that may sound something like this: “8500 users stochastically add one item per minute to their shopping cart while the system operates in the ‘holiday shopping mode’ and the requests are processed with an average latency of 3 seconds.” A series of such scenarios provide a working reference for an architect to aid him in design a system to meet these quantifiable requirements. But how to measure the politics quality attribute?

Finding a way to measure politics in some useful and meaningful way is important, because politics present design related constraints and risks that must be mitigated. In my recent architecture analysis task I noticed that a cluster of database servers had to be two thousand miles apart from the web and application servers. When I inquired about the reasoning I was tacitly told that the two different bosses from two different datacenters wanted a stake in a high visibility project. I was assured, however, that a “very fast backbone” will provide sufficient latency between the locations.

The first step to tackling this problem is to define what one means by politics and in what units can this property be measured. Because politics are unspoken in most organizations the architect would have to decide how to represent this constraint and mitigation strategies on paper. Or can this be done on paper? Or is this something that an architect should document privately? If so, who else should be aware of this information?

Your thoughts are welcome.

- Firebrand Architect on duty: CK

No comments:

Blockchain learning path for Enterprise Software colleagues

I wrote this post to document my learning path of blockchain concepts and Ethereum technologies while keeping my “new to blockchain” collea...