Keegan Wade's Homepage

Software Development and the Black Swan

February 9, 2010

In his book The Black Swan, Nassim Taleb describes a “Black Swan” as an unexpected event caused by some unanticipated variable that has a disproportionate impact on things. Taleb cites J.K. Rowling, Christianity, and 9/11 as Black Swans.

Black Swan events only happen under certain circumstances. The example from the book is say you have a thousand people, and that the average weight amongst them is 135 pounds. Now add the heaviest person in the world to this group – a guy who weighs 1000 pounds. If you do the math, this extra 1000 pounds represents less than a fraction of a percent of the total weight of the group; adding the heavy guy to the group hardly makes a dent to the total.

Now pretend that instead of weight we are concerned with net worth, and that the average net worth in the group is $100,000. If we add Bill Gates to the group, whose net worth is $40 billion, the opposite happens: the net worth of those thousand people represents only a fraction of Gates’.

Unlike with weight, Black Swans are possible in the context of income. Bill Gates is a Black Swan. The thousand pound guy from the previous example would have had to weigh millions of pounds to become a Black Swan.

~

When it comes to Black Swans and technology, the first two things that come to mind are nuclear energy and software development. First, nuclear energy: It goes without saying that a nuclear disaster could have a Bill Gates-sized impact on humanity. And while nuclear plants implement a host of failsafes and safety measures that make them seemingly risk-free, consider that very few empires or nation-states in human history have managed to avoid war or internal political strife for a period of more than some hundreds of years. If a war were to break out in a country with nuclear plants, who is to say what might happen, especially since power plants have traditionally been targets for sabotage and bombings. Radioactive elements found in nuclear plants can have half lives of hundreds to thousands of years. The consequences of a nuclear disaster – say, by way of political strife – despite how improbable this may seem - are, well, Chernobyl-like. Based on these variables alone, nuclear energy could be interpreted as short-sighted: like a Black Swan waiting to happen.*

Second, I want to touch on the occurrence of Black Swans in the context of software development. Software projects are particularly sensitive to getting thrown way off schedule by unexpected variables. Partly as a result, scoping and projecting software development is a notoriously difficult task.

Now, when I say “unexpected variables,” I am not referring to known unknowns, such as “this use case is much more complicated than I expected,” which can be accommodated for by employing best practices such as multiplying projected development time at the outset by a factor of 2.5. I’m referring to unknown unknowns; where the variables themselves cannot be predicted.

I recall the story of a conversion analyst who quit her job during a critical stage of a big important software implementation. Her departure was quite unanticipated, and it left the project team in a state of disarray. Although another conversion analyst stepped in and successfully finished the conversion, he did so at great expense to health and happiness. From that point on conversion analysts were paired up on projects, just in case someone quit or got hospitalized.

Sometimes, as with the situation I just described, there’s not much we can do about Black Swans except to learn from them. Not learning from them would be akin to knowingly building nuclear power plants amongst a war-prone species of beings.

In the spirit of this blog post, please enjoy the following clip – it’s one of my favorites. http://www.youtube.com/watch?v=b0LPUI0lfVw

* To my knowledge, Ernest Schumacher was the first to propose this argument in his book Small is Beautiful.
 

Taking Breaks from Programming

January 15, 2010

In the four software organizations I’ve worked for over the years, I’ve found that very few programmers ever take breaks. Some reasons to explain this:

   - Programmers don’t feel the need to take breaks
   -
Managers don’t encourage breaks
   -
Limited number of suitable break areas
   -
Not taking breaks is socially normative amongst programmers

Why take a break? The most obvious reason is to rest one’s eyes and one’s mind. A deeper reason is to get recalibrated with what matte...


Continue reading...
 

Mentorship in the Workplace

December 19, 2009

From time to time I hear the word “mentor” used in the workplace. I think most of us define a mentor as somebody who instructs others in work-related processes, especially through difficult points.


If instead of thinking of work solely as a means by which to earn a living, we consider work as a pathway towards human development, the word “mentor” goes beyond the machine level aspect of one’s work, and takes on a human dimension. With this in mind, I find Robert Aziz’s definition of...

Continue reading...
 
Make a Free Website with Yola.