Monday, April 13, 2015

Polydamas Syndrome

 

..Great strength but little sense

 

Polydamas was an panktration (panktration - almost no rules mix of boxing and wrestling) champion at 93rd Olympiad, 408 BC.  Beyond Olympic success, there are some legends about his strength and power, that could remember of mythological Herakles (Hercule): he kill a lion with bare hands, he stop a moving chariot and win a fight with more "immortals" of  Persian king Darius.

However, he died trying to held with this hands the roof of cave that is crashing down around him.  

"The death of Polydamas, the Thessalian, when he was crushed by the rocks, made clear to all men how precarious it is to have great strength but little sense."  - Diodorus Siculus, Historical Library,  9.14.2

The key concept is the feasibility of an endeavor: no matter the skills, strength and power you have , but only if all these abilities are matching with the difficulty of the task. Knowing what we cannot do, the limits of our abilities it is very important.

Of course, we want always to go further and test and improve our abilities, but the also the involved risks matter, as in the Polymadas case.  

Polydamas Syndrome in software development 

 

Software development it is an area where this syndrome it is manifesting rather very often. The high rate of projects failures is not only a problem of inadequate management and inadequate engineering but also a problem of overestimating the involved skills versus the difficulty of  the context problems. 

Waterfall approach, for example, it is sign of this syndrome: if the iterative development try to manage the complexity in smaller parts, waterfall claim that will "eat" all the complexity in one piece.

Software development is the activity where most often smart people repeatably fails due to wrong estimation of their abilities on facing complexity.

Here are other examples from real life:
  • Reckless: We have no idea about how to solve what the customer want, but we commit to solve it (eventually with also a committed delivery date). Possible reasons: wants to gain appreciations from customer and management. The root cause could be a gambling disorder-like behavior or just an immense vanity  
  • Inadvertent: We know that we have no idea about the solution, but we hope that we will find it. That is happening many times with individuals that want a higher role or position and just hope that they will succeed without some previously proved practice. 
There are similar terms that the ones used by Martin Fowler describing the Technical Debt Quadrant. The "Polydamas Syndrome"  instantly produce or induce Technical Debt, that sometime could be irreversible.

By their nature, people could be reckless, inadvertent,  "normal" or too cautions. We need an adequate work discipline in order to get from all of them a good enough estimation for the balance between abilities and difficulties and also of the resulted risks in case of significant imbalance.     
Agile development at least it is defined as the "art of possible" and any manifestation of "Polydamas Syndrome" is a sign of severe agility problems and in general severe problems in the software process that should not be tolerated.

Solution Spikes and Architectural Spikes from XP are an possible answer to feasibility problems in Agile approaches, but a more complete set of practices could be found in DAD - Disciplined Agile Delivery that also have feasibility related milestones and an explicit approach for such risks.

"Seduction"


A big problem is that people with "Polydamas Syndrome" are very seductive for management and for customers. They represent at the first sight the dream collaborators: they will quickly commit to any request. The consequences are visible rather on medium and long terms. The main problem is when the management of the development side does not control the result risks. It is rather not expected that the customer side to be aware of these risks and they will surprised when the effects will become visible.

Sunday, April 5, 2015

Human evolution patterns: from beginning of history to software



Beginning of human history

 

Asia Minor, more than 11,500 years ago, just after the Ice Age and 7,000 years before Stonehenge or Cheops. No agriculture. No domestic animals. No metals. Just some groups of hunter-gatherers. But … they have settlements, deposit of foods and a community. This community start building some massive stone temples. Their culture influence other groups and communities in the same area. 1000 years later, in that region are founded the first evidences of the agriculture and the first cities. And that was the beginning of the world history.

The first engineer and the first architect have existed before the first farmer.


The key of the evolution - community

 

Making an 11,000 years’ time travel, I want to quote from “Manifesto for Software Craftsmanship”, initiated by Robert C. Martin: “Not only individuals and interactions, but also a community of professionals”. 

The key word for evolution is community

The discovery of the Gobekli-Tepe temples in Asia Minor changes the model of the civilization evolution from: farming-settlement- religion-temples-cities to this one: settlement, religion, temples, farming then cities. (Of course that religion exist before settlements, but it is about more structured forms of religion).

Evolution sequence: settlement, religion, temples, farming then cities. 

The base of civilization was the settlement, the moment when was crystallized a stable group that share common values: from common food deposits to a common culture and form a community. This community was able to build temples and to distribute their culture
Hunter-gatherers, settlement, religion, temples, farming then cities. We can translate that to: teams, practices, sharing values, community and culture, distributing the culture, transformation: new practices, new values and new communities.

The software new civilization: between dilution and evolution

 

The recent evolution of software development has follow a similar (cyclic) pattern: the late 80s and the 90s start with some new practices, new small communities with new values. That has been finalized with some cultural “settlements”: CMMI, UML, Unified Process, Agile Methods and Agile Manifesto. This culture will be distributed and new communities will be formed.

Unfortunately, the initial new software civilization was somehow diluted during its expansion: the only widely adopted method was Scrum (very lightweight method) and many values, especially engineering values were almost forgotten. (See Robert C. Martin comments here  https://www.scrumalliance.org/community/articles/2010/december/the-land-that-scrum-forgot ). 

There is a new wave that want to recover the forgotten values and go further: the Software Craftsmanship movement and the Disciplined Agile Delivery (DAD) method are the best examples.  Both are dealing with some biggest elephants in the Agile room.

DAD want to make explicit the Agile cultural values and practices and recognizing that context matter, this method offers guidance for adapting the process to different situations.

Foundations of Software Craftsmanship are older and I will remember here only some contributors of the Agile related foundations: Kent Beck, Martin Fowler, Scott W. Ambler and Robert C. Martin. The last one – Uncle Bob – try to push further this wave with Clean Code and Clean Architecture initiatives. Unfortunately this part is difficult enough to not see yet other valuable contributors or even valuable distributors. A symptom of this problem is that most of the “distributors” talk only about Martin SOLID principles, without an understanding of the bigger picture or of other aspects. It is just a copy-paste distribution.

There are two divergent evolution aspects now: a distribution that dilute values and new endeavors for enhancing and improving the original values.

Human Evolution patterns

 

The evolution patterns seems to be in this sequence:
  • Prehistory
    • Teams & practices
    •  Small and slow transformations, many of them being lost because of limited distribution and sharing
  • History
    • Settlement: sharing common values, community, culture
    • Distribution: sharing culture, new communities 
    • Transformation: communities generate new practices and new values 

Evolution factors: communities enable values sharing and creating of new ones 

Involution factors and sequence:
    • Success with diluted values
    • Dissolution of communities
    • Cultural regression 

 Involution factors: cutting the value distribution chains and the success of “non-valuable values”

The involution factors seems to be the same in history of human civilization and in the one of software development.  The human history has several regressions caused by “success of diluted values”: such as the Greek Dark Ages (1100 BC–800 BC), the Dark Ages of Middle Ages. The history does not necessary represent a continuous linear progress and same risks could affects the software development domain.  For example, the rising of new web technologies cause a dilution on design quality ("Architecture lost years" - Robert C. Martin), even that is only because of their continuous changes. Poor design is finally resource consuming and expensive and that cause regression or slowing of the overall evolution.

These patterns that seems to be the ones that have "shaped" the human evolution. I think that should be considered for any aspect of evolution and for different levels, from large communities and "populations" to organizations level.

Any invention of human genius is born dead if is not shared and embraced by a community that will make that invention as a valuable step in the evolution. On the other hand, a community that does not profits from its "inventors" it is not a community. We need to enable, recognize and share the real values in order to have a community.