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.

Monday, January 5, 2015

Discussing "Inventory" in Software Development - Classifying approaches


Interesting comments of Martin Fowler starting from this idea : "So as an example - one of the principles of lean manufacturing is the elimination of inventory.This leads to the question of whether there is an analogous item to inventory in software development."

http://martinfowler.com/bliki/MetaphoricQuestioning.html

Martin Fowler make a very interesting comment about a IMO less interesting idea "up front documentation is the equivalent of inventory": "Now I agree we need to substantially reduce this kind of speculative documentation; but the rationale for doing so must come from thinking about the software development process, not from purely reasoning by analogy."

Here is my comments on these subjects.

Manufacturing-Software Development Analogies

We should be careful on these analogies because these domains areas are pretty different. Examples: Just-In-Time approach in manufacturing must find solutions for a JIT Production (where the design was previously done "offline") and software development must find find solutions for a JIT Design ("Code is design").

Inventory in Software Development 

Manufacturing inventory mean (simplified) a reserve queue of (done) products, ready to be sold. A similar concept in software development IMO is not the massive up-front documentation (based on too many assumptions) , but rather in the motive of producing a such documentation: a massive set of requirements allocated to the same release/delivery/project. "No inventory" approach means as small is possible set of requirements per release. Indeed from this point of view, the classification is already done:
  • Large set of requirements releases - non-agile, non-lean approach
  • Small set of requirements releases - Agile approach, Lean approach
  • Very small set Small set of requirements releases - Continuous Delivery approach
An explicit description of  lean and Agile life-cycle models could be found in DAD- Disciplined Agile Delivery: https://disciplinedagiledelivery.wordpress.com/lifecycle/ 

More: With an increased construction productivity and/or a higher envisioning productivity, a larger set of requirements could be delivered in the same time. Productivity suppose here here good results and quality 

The resulted formula of "Inventory" for software development:

(Set of Requirements "volume")/productivity.

Comment: the "formula" could be enhanced to:

 (Work volume")/productivity. 

But, in this case, it is too vague.  The main aspects that increase volume or complexity of the "work" must be specified. here are some of them:
  • Requirements volume and complexity at the start
  • Solution that must match the requirement 
  • Team productivity 
  • Process
All elements of the formula are "requirements" for "No Inventory" process in software development:
  • small set of requirements
  • good design
  • no junk stories with associated phantom features
  • high productivity (all contributing aspects)
  • small releases 
  • adapted/effective/efficient process 
Finally, seems that starting with this assumption about a "No Inventory" approach for software development we are very close to the description of a Lean/Agile approach.

See more here: