Principles for a community of professionals - II

See first - Principles for a community of professionals - I

Critical mass of potential skills

A team does not have the critical mass of potential specific skills for great steps forward or for facing too difficult problems. A single team is limited in the same way as single individual is limited. The solution is to have available a larger pool of resources: more (collaborative) teams, a community.  

Knowledge and experience sharing. Knowledge persistence

The limitations related to single team are also manifesting for sharing knowledge and experience.  Communities could be more effective in this case. Also the knowledge persistence could be more robust.

Isolated teams will have the same problems as isolated individuals: will not benefits of pre-existent or co-existent knowledge and much part of their effort will be a waste. Some examples:

• Will re-invent already existent solutions (aka “re-inventing the wheel”)
• Will be slowed by impediments that were already removed elsewhere 
• Will not re-use creative work and good results from other teams

Knowledge persistence short history: first community, temples, stories, cities, stone inscriptions, papyrus, alphabetization, academies, libraries, Gutenberg, electronic data, Internet … 

Active collaboration: inside team, between and across teams

Active collaboration between individuals it is a mandatory practice for an effective knowledge work, but is not enough. In order to get more value from skills, knowledge and experience we need an active collaboration between teams and across teams. 

Talents valorization and rare ideas

Contribution of very talented individuals, one of the engine of our civilization could not be valorized at team level – we need communities.  They need peers to develop and validate their ideas, and only a community could sustainable offer such peers. Also, only communities could spread, persist and valorize better their contribution. There were a lot of talents in the prehistory and history that have wasted their potential because of lack of collaborators and peers.

Evolving stability

All the factors enumerated here – skills, knowledge, experience, collaboration, teams and teams of teams – need time in order to manifest and bring results. A community need a time of evolving stability. For example, the history discontinuities of the “dark ages” have slow down the evolution for centuries.

Promoting valuable ideas

We cannot get value from distribution of wrong or not productive ideas. In software development, using a historical retrospective, the Waterfall approach have not produce either benefits for single projects or for software engineering evolution … with notable exception of lessons learned.  On the other hand, agile and iterative development have improved the overall results of that domain.

Historical example: The “Classical Greek” era in the ancient history was followed by a similar flourish of sciences only on the Renaissance times; this discontinuity has affected the entire evolution of the civilization.  

Different kinds of communities

It is not just a simple math. To bring together a critical mass of skills you need more kinds of communities: cities, schools, universities, specialized companies, professionals’ communities.

Inside an organization, you could benefit from communities of practice, but the first community must be the organization itself.

Creating new values, practices and new communities

New values, practices and finally new communities will emerge from existing communities.  From an economy dominated by mechanical and construction engineering has later emerged electronics and computer science.

Historical example:  The main step in evolution of human civilization was the occurrence of the first human communities. All have started in this order: first community, first series of temples (yes, first architect and first engineer have existed before first farmer), other similar communities and later agriculture and cities.

A good example - Agile Manifesto 

• "Talents realizations and rare ideas" - the "rare" ideas from initial agile methods and practices have been shared via ad-hoc community of Manifesto authors
• Share knowledge, experience and knowledge persistence - no comments needed 
• Promoting valuable ideas - the good influence over the software industry is obvious 
• Creating new values, practices and new communities - agile practices, values and principles have emerged legacy existent form of software engineering community. In fact many of these were pre-existent, but was no evolved via communities 

A good example - Software Craftsmanship Manifesto

• Has emerged from Agile Manifesto
• Address manifested weakness of  agile movement and agile teams

A bad example - Discontinuity on promoting core agile engineering practices   

• The problem was recognized by some of the main Agile contributors: Robert C. Martin, Martin Fowler, Kent Beck, Scott W. Ambler and others
• The main symptom it is so called Flaccid Scrum  (See FlaccidScrum by Martin Fowler) 
• Agile values was promoted in a diluted, partial manner 
• There was a discontinuity on promoting core agile engineering practices 
•  People skills and knowledge were "disconnected" with team-only dogma

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.

See - http://ngm.nationalgeographic.com/2011/06/gobekli-tepe/mann-text

NEXT

• Principles for a community of professionals - I
• Principles for a community of professionals - II 

The Obligation of the Programmer (Robert C. Martin ) versus reality

After "Clean code", the book and the rules, are inspired from Hippocratic Oath, Robert C. Martin has elaborate now "The Obligation of the programmer" , a code of ethic inspired from the "Order of the engineers" (http://en.wikipedia.org/wiki/Order_of_the_Engineer) code.

http://blog.cleancoder.com/uncle-bob/2014/11/15/WeRuleTheWorld.html 

Some significant ideas from this code:

• Human progress depend on "those who manipulate information"
• The result of any programmer is depended on the "accumulated knowledge and experience " - that mean this experience must be known and used
• It is important to participate only to honest enterprises 
• The programmer skills and experience it is a public good

Starting from Uncle Bob sentences, here some ideas about why this code it is important. How the reality looks like:

• Human progress it is stalled because of software development problems (high costs and low productivity, where defects management it is included)
• Too many programmers does not learn enough from "accumulated knowledge and experience" -  the re-invent the (...squared) wheel syndrome is not rare - and too many of them blocked in stone-age of the design (... no design).
•  "Honest enterprises..." - the short term goals (combining with poor skills) are destroying the products and productivity

The programmers and the others involved in this domain are smart people, but the domain is very difficult and we need to be also disciplined and deliberate dedication.

Technical Debt Patterns

(More details – article Know and Manage the Technical Debt, Software Development Journal)

Prevention_Versus_Correction 

• We should focus continuously on quality by adopting “built-in” quality versus “inspected-in” quality. In fact, the “test&fix” approach will give a temporary quality and will hide the debt. Finally, it is pretty naive to address quality only by test & fix.

Levels_of_Design_Versus_Debt 

• Because TD is related to software design, it is also related to the Levels_of_Design, where each level could introduce – more or less – its own part of technical debt. Here are some levels (others could also be taken into consideration):

• Coding style
• Clean code rules
• Design decisions in context
• Architecture decisions

No_trade_for_basic_levels 

• “Bad code is always imprudent.” says Robert C. Martin 

 Methodology_Induced_Debt 

• Use context-adapted iterative approach, that mean the right design strategy in the context.
• Agile techniques: Clean Code (“prefactoring”), Refactoring, TDD (pay the debt early)
• Risks-driven techniques: Architecture-driven approach.

 Avoid_Mega_Debts 

• The cost of a such debt could be exponentially higher then of the normal debt. Examples:
• Refactoring nightmare by Interfering_Debts (such unsearchable names + “duplicate” code); 
• Envious_Monster – mega components that present “”feature envy” for many other components;
• Big_Design_Elements 

 Register_the_debt 

• In order to manage and pay the debt , you should know and register the debt

Manage_Mega_Debts_First 

• Big, important and messy – that is an explosive problem.

Define_and_Use_Thresholds 

• Beyond applying metrics, should be associated some risks thresholds to some significant metrics.

Search_Usual_Suspects 

•  Feature envy, big size, no separation of concerns; searching for them could offer a quick assessment and a quick reaction

Use_Separation_Of_Concerns

• That is the design principle with biggest impact on debt management.

Long_Term_Steadiness

•  See Software Craftsmanship Manifesto

Honest_development

• Clearly define the responsibility of managing the TD

Are we professionals? (1)

If...
... Robert C. Martin will be your new CTO, then his first question will be:

Are we professionals?

His answer is:

We need to be.

Here is a list of what the professionalism demand in his view:

I Expect...

...We will not ship shit.
...You will always be Ready.
...Stable Productivity.
...Inexpensive Adaptability.
...Continuously Improvement.
...Fearless competence.
.. Extreme quality.
...QA will find nothing.
...We cover for each other.
...Honest Estimates.
...You to say "No".
...Automation!
...Continuous Aggressive Learning.
...Mentoring.

I will post the source later. Please try this exercise:

• try to find the motivations behind each of these sentences
• try to find yourself the source... maybe you will find more interesting subjects from "Uncle Bob".

Uncle Bob quotes - We will not ship shit !

Under no circumstances ... We will not ship shit ! 

(Robert C. Martin (Uncle Bob) - Demanding Professionalism in Software Development )

The Story of Agile Manifesto

You can find the full article here:

http://www.informit.com/articles/article.aspx?p=1743276

>>>
InformIT: You were a co-author of the Agile Manifesto in 2001. What drew you to the gathering?

Bob: In 2000 I asked Martin Fowler to lunch to talk about the idea of a "Lightweight Process Summit." We were both part of the Extreme Programming movement, but we had seen that there were several other similar processes, most notably SCRUM, FDD, DSDM, and Crystal. We thought it would be a good idea to get the advocates of all those processes together with other industry leaders to see if there wasn't some way to find and define common ground. I suggested to Martin at the time that we might be able to create some kind of manifesto. He and I put an invitation list together. I composed the invitation and sent it out. After that the process took on a life of its own.

>>> ("Ten Years Of Agile: An Interview with Robert C. "Uncle Bob" Martin")

The idea (and the initiative) of a "Lightweight Process Summit" and of the manifesto that could define the common ground of that kind of movement belong to Robert C. Martin. "Uncle Bob" and Martin Fowler have created also the invitation list... The resulted manifesto is quite outstanding, at least for the ones that have good experience with software development and could serve as guidance for every practitioner.

Yes, we can say that all those methods are "implementing" these principles, but the great thing is that it was first the demonstration: methods and practices resulted from experience and proven to be working. This "theory" (the values and associated principles) are just the abstraction of real experience.

Thank you, Uncle Bob! :)

Note: "The Manifesto of Softwarecraftsmanship" has the same creator.

Agile fundamentals: Working software

This concept it is highly used when we talk about Agile. It is mentioned in Agile Manifesto, first as a main value and then as part of the agile principles. In the same time it is highly misunderstood, even by some claimed agile practitioners.

Waterfall versus Working Software

The main dilemma concerning the process approaches in software development is not "Agile versus Waterfall" - that is false and confusing - but rather Waterfall versus Working Software, that mean Waterfall versus Iterative Development. Why? Very simple answer: the process approach that has a main attribute the Working Software is Iterative Development. Ok... but what about Agile? Agile is one of the main variants of Iterative Development, and probably most used.

There are 4 main Agile values and associated principles. There are also few others values and principles related to software development. Anyway - Working Software/Iterative development is the first one, if not as value, but at least as attribute that define an entire category of non-Waterfall approaches .

"Traditional" PM main problem

A "traditional" PM for software domain is not the one that use PMBOK based PM style, but the one that one that use Waterfall as project life-cycle model.  (... PMBOK does not propose any life-cycle model because that is out of its scope). The first thing that should know a such project manager is: if Agile is not needed, that could be ok, but Iterative Development is not optional for a good project management in the software development case.

Working Software it is a must!

Agile related confusions

Good understanding of working software it is fundamental for a real Agile process. 

The Bad and the Ugly

An often misinterpretation of the Agile Manifesto is the following: we do not need documentation, we just craft some software. That is not agile, and it is very harmful.

The Good

The right interpretation of W.S. concept from the A.M. is when we are thinking to the working software resulted at the end of an iteration: analyzed, designed , implemented and tested & fixed software. Nothing is missing? The complete "formula" should be: continuous integrated (working) software.

Recap:  we should use iterations (smaller than one month, but better of two weeks of less) and working software should be the main result and measure of the progress at the end of the iteration.

The Great

Softwarecraftsmanship Manifesto states also that we need not only working software, but also "well-crafted" software. Something similar could be found also in the Agile Manifesto principles, where the used terms are "good design" and "technical excellence". Finally, that mean that for Agile we need "well-crafted" working software. Why? That will enable, enhance and offer steadiness to the agility. Also, that mean we will produce less Technical Debt, that is a condition for Agile (and agile methods as Scrum) and also for any good process.