Kudos

Unlike other expressions of the human capacity for tool making, computers are, perhaps uniquely, totally versatile in the sense that they can be programmed.

 

Computer programming is set on simple principles; 0′s and 1′s, on or off. From those humble foundations, springs complexity as layer after layer of abstraction are added, each designed to enhance our ability to utilize the one underneath.

 

When a programmer works on writing software, she usually does not dwell on the complexity she is creating with each line of code but , like art, no two pieces of software will ever be alike.

 

Software development is difficult to implement and a managerial challenge if ever there was one. It is a practical tautology that software projects neither finish on time nor on budget, while users are usually dissatisfied with the end product for some reason or other.

 

This behavior extends to IT. Generally speaking, the more versatile an appliance is (and thus more reliant on software), the more complex and uncertain to implement and maintain it will become.

 

This is very interesting because there are engineering tasks out there that are no less complex nor less monumental than writing software, yet are easier to manage in terms of risk; building sky scrapers could be one example. That’s because sky scrapers exhibit no emergent behavior.

 

Many smart people are addressing this challenge by thinking up new ways and creating new tools, to help managers tackle software projects. Probably one of the most interesting of those is Alistair Cockburn, who maintains that software development is most similar to a cooperative game.

 

I stumbled upon Alistair’s article about software development as a cooperative game (via coding horror), and it was absolutely fascinating. Only rarely do I read an article that leaves me saying “that’s right!” and “I can relate to this” and “damn, so true” so many times in one sitting. So before I go on – Kudos! to Alistair.

 

Mr. Cockburn’s article is a bit longish, yet packed with good material and is worth some serious discussion.

 

In future posts I will separately address, and add my own thoughts, on the points that are made in the article – starting with #1, Communication (here is a short excerpt):

“…The first thing to get is that no communication is ever perfect and complete. It just can’t be done. It is not even in the realm of possibility. Your listener, or the receiver of the communication, has to jump across a gap, at some point, and has to do that all on their own. You can’t do it for them. If they are very different from you, then they can’t jump a big gap. You have to explain some basic concepts to them, and then build forward until they build their own bridge of experience so they can finally get what you are saying…”

“The point is, we write these specification and design documents as though we could actually ever explain what we mean. And we can’t. We can never hope to completely specify the requirements or the design. Not even the faintest chance. When we write, we assume that the reader has a certain level of experience. If we can assume more experience, then we can write less. If we have to assume less experience, then we have to write more.“

“All communication is touching into shared experience.”

 

More on this to come. 

 

 

פוסט זה פורסם בתאריך 1 בApril, 2007 בשעה 1:20 pm בנושאים Emergence, Jobscape, management. ניתן לעקוב אחרי התגובות בעזרת RSS תגובות. לא ניתן להגיב לפוסט.