Take care about your impact!

CIVILIZATION & SOFTWARE – There are some common things between human history and software development: the fundamental things in evolution are the people, their collaboration and how they are creating, managing and distributing knowledge.  

“REACT BEFORE DISASTER” – several days ago I have discussed with a younger friend about what we need to improve a country or city status-quo, dealing with an ineffective evolution. Things are stopped improving, groups of interested have now a well-oiled political machine and propaganda that allow them to act discretionary and people seems to be anesthetized. It was interesting that this candid viewpoint seems to be very similar to what really works in human organizations in history, but also in software.  

Until the people do not reach a desperate situation, morality remains just for coffee discussions. More, when people start doing something, they do not agree with each other ... they are hampered in detail and forget the purpose.

Maybe politics is not for us, and that’s it…

Maybe we can ... probably with more patience. The politics is also part of life you do not have to join a political party to do your civic duty ... just that there's the problem that how to communicate well enough to convince people that needs to be involved. Instead of being stuck in some blind principles we can do something against what it is worse.  

There are some macro level things that could be done: if healthy economic interests are growing, something will change.

Let think to the micro level, where we are now: I should ask myself what I can do for my own little community. That is also indispensable.  

“BEFORE DISASTER” IN SOFTWARE  - In software development instead of malefic groups of interests we have specific problems more similar for us with some “natural disasters”. Technical debt is accumulating and will deeply affect our products and business. We are unable to deal with the complexity of software variants. We are unable to produce, manage and effectively transmit the knowledge. The status quo is similar to the one from above dialog:

• Professional ethics is just a discussion at coffee break until a disaster will strike us
• We think that we can do nothing because some forces beyond our powers are influencing our context
• We are stuck in some “local” ideas and principles without collaborating to optimize the whole
• The “global goods” as the product design healthy are the responsibility of no one

What is really happening: we do not react when the problems are small, we let these problems to accumulate, we do not speak loudly about them. It is not our responsibility, it is a “Deux ex Machina” job. We are expecting for formal responsibilities delegation instead of acting according to implicit professional responsibilities (~political vs. civic)  

WHAT GIVE US A CIVILIZATION – “Flexibly cooperate in large numbers” it is the argument of Yuval Noah Harari [Biblio- Harari 1]. What I did not find in Harari book Sapiens [Biblio- Harari 2] it is what always work better regarding this cooperation. It is not the religion, or the empire.  The best advances in civilization were made by “entrepreneurial societies”, where there was (some) liberty, especially liberty of action, and people could directly participate in political decisions. Here are some examples:

• Minoan civilization – beginning of the European civilizatio
• Classical Greek – people are entrepreneurs in science, arts, commerce but also in the military. If the Mycenaeans have only palaces and big defense walls, in Classical Greek, the first most important construction in a city-state will be the Agora. 
• Roman Republic (the Empire just inherited anything that the Republic has built)
• Medieval Renascence in all domains

In human history and even earlier, we can find and observe various ways of human organizations and their specific result. History starts with the first large communities, where people could start “Flexibly cooperate in large numbers”. Anyway, in modern society with a lot of small, medium and large communities, we can find us again isolated as individuals and even as teams.  

LEVEL OF INVOLVEMENT – to have a society that evolves and improve, we need the active involvement of its members. We have modern states where this level is low and ancient states where this level was high.  Consequently, there are modern states with no evolution and there were ancient states with outstanding evolution. Modernity by itself it is not a guarantee for evolution, but our behavior. 

We will go back to the software to see how it is possible to be responsible not only for good ideas but also to have an impact on the community and society.

KENT BECK:  FROM IDEA TO IMPACT (ON COMMUNITY) - There is a kind of specificity for great contributions in software development. These contributions are not some lab researches first published in scientific papers and latter applied in production. This kind of contributions are made for production and it is re-evaluated again and again. More: bright ideas and implementations are not enough. You need to do some hard work to distribute them in a good form.  Kent Beck [Biblio- Idea to Impact]:  

“Here are the stages:

1.      Adopt personally

2.      Find the totem

3.      Repetitively broadcast”

Kent Beck “Idea to impact” it is the road from micro to macro level, nurturing and validating a good idea, then trying to distribute and making an impact.

“When I have convinced myself by personal experience that an idea has the potential for impact, I start talking about it.”

“These conversations help me find the spirit of the idea. I know the mechanics and maybe the theory of the idea, but I don't know the intellectual and emotional hooks that will interest and motivate other people to try what, if I'm doing it right, sounds pretty crazy.”

“Along the way I pay attention to what other people are saying about the idea. When I hear someone repeat the idea to someone else without referring to me, then I know I have won.”

“TEAL IS THE NEW BLACK” – Scott Ambler propose (inside Disciplined Agile) the same parallel with the civilization progress [Biblio – Teal Orgs]. He uses the model of the author of Reinventing organizations, Frederick Laloux, where the most advanced forms of organization are [Biblio – Teal Orgs]:  

Teal: Self-organizing/Adaptive

• Cellular. living organism
• Awareness, fulfillment
• Evolutionary purpose

Green Post Modern/Information

• Consensus/Participative style
• Value based motivational culture

You can see here that evolution it is strictly related with (direct) Participation and Awareness.

For effective, efficient (Agile) teams, Ambler recommends a Teal-like organization or at least a Green one. He specified, that most likely “Your Organization is Probably a Rainbow” and your strategy should be adapted to the context [Biblio – Teal Orgs].

WE HAVE IDEAS, REFERENCES, AND GUIDANCE!  

What we do in each second will have an impact. Longer period with no improvements it is also a kind of (negative) impact in evolution. As Yuval Noah Harari said [Biblio- Harari 1] humans have done also horrible things while they have collaborated in large numbers.  For a positive impact we need not only to collaborate, but also we need to be aware and “civically”/”ethically” involved both at work and as citizens.

Some find references from history as in “Reinventing Organization” [Biblio – Teal Orgs].  According to others, even the newest organizational types are not so new, and are proved or not by the history. “If we don’t learn from our successes as species, in the course of reinventing organizations we will spend a lot of time reinventing the wheel.” [Biblio- Jessica Prentice].

We have references and guidance in the software industry. Kent Beck has told as a story about how to go “From Idea to Impact”. Robert C. Martin writes about “responsibility of the programmer”. Discipline Agile (Scott Ambler and Mark Lines) offer guidance about how developers and other stakeholders could be actively involved and collaborate at team, enterprise and community level.

Last, but not least, we have “the next Jedi”, young people with the same good intuition and common sense as their predecessors.

Take care about your impact!   

REFERENCE AND BIBLIOGRAFY

[Biblio- Idea to Impact] - Idea to Impact, Kent Beck· Wednesday, July 8, 2015

• https://www.facebook.com/notes/kent-beck/idea-to-impact/990860537613477/

[Biblio- Harari 1] - Why humans run the world - Yuval Noah Harari

• https://www.youtube.com/watch?v=nzj7Wg4DAbs&fbclid=IwAR2QeGYd9ycAxGFOKuv4Z6vEWvQ9B8DAJwQKJejYXt1YTXr_155FPTc_uq8

[Biblio- Harari 2] - Sapiens: A Brief History of Humankind Hardcover

• February 10, 2015, by Yuval Noah Harari

[Biblio – Teal Orgs] - Teal is the New Black, Scott Ambler

• https://www.disciplinedagiledelivery.com/tag/teal-organizations/
• Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage in Human Consciousness by Frederic Laloux (2014)

[Biblio – Jessica Prentice] - The Most Dangerous Notion in “Reinventing Organizations” by Jessica Prentice

• https://medium.com/@jessicajprentice/the-most-dangerous-notion-in-reinventing-organizations-9032930295e2

Clean Code, a definition (essay)

Important note – TDD discussions are deliberately out of scope, to be discussed later, because of the complexity of the subjects.

NO ACCURATE DEFINITION. Can be accurate? Perhaps not. We need a good enough definition. What we have now are not definitions, but rather descriptions about Clean Code attributes. At the end of this post, you can find the thoughts of some well-known programmers interviewed by Robert C. Martin for the book “Clean Code”.

SCHOOLS OF THOUGHT.  Also, there are some different “schools” of thoughts related to this part of software design. Quoting from Robert C. Martin, from the same “Clean Code” book (“Schools of Thought”): 

“None of these different schools is absolutely right. Yet within a particular school we act as though the teachings and techniques are right. After all, there is a right way to practice Hakkoryu Jiu Jitsu, or Jeet Kune Do. But this rightness within a school does not invalidate the teachings of a different school.” 

“Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art.” 

Clean Code & Refactoring are not “invented” by Robert C. Martin, Martin Fowler, Kent Beck and their collaborators. This is rather a category of software design where are more significant contributions. Examples of books: “Clean Code” (by The Object Mentors:Robert C. Martin, Michael C. Feathers Timothy R. Ottinger, Jeffrey J. Langr Brett L. Schuchert, James W. Grenning Kevin Dean Wampler), “Refactoring” book (by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts),  “Pragmatic Programmer” (by Andrew Hunt David Thomas),  “Code Complete” (by Steve McConnell), “Implementation patterns” (Kent Beck).

CLEAN CODE AND REFACTORING. In fact, using other names, we have similar guidance from other authors, before or after the book “Clean Code”. The first name that comes to my mind is “Refactoring” book (by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts). In fact, we refactor to a cleaner code. Paying the technical debt (refactoring) too late and for huge amount of debt it is a waste: we need to stop the other works and it is a huge effort.  It is much better to learn how too write clean code and to refactor early (… we already know that if we know how to refactor, but we need to share the expertise with the whole team).

ATTRIBUTES. Here some attributes of the Clean Code that are more often mentioned: simple, easy to read (also by the others), meaningful names, straightforward, designer’s intent is clear, no duplication, each part do what you expected.

TIMING. As you see these attributes are rather generic aspects, not particular design patterns. In the same time, as opposed to some design patterns as Observer, Template, Adapter, MVC or architectural patterns as Pipes and Filters, Microservices, the “patterns” related to Clean Code are small, and are used much more often. Clean Code it is used to refer all kind of design decisions from smaller one to architecture, but in practice, the authors or experienced engineers talk mostly about the ones that are small, generic and are used very often.

A good programmer will do some refactoring daily and very often during every day, for both legacy and new code. How much refactoring and which the refactoring principles and patterns will be used? That depends on the context. What we can observe is that a good programmer will use refactoring very often. Sometime the same programmer could write a good enough code from the first time.

How many times in a day we are deciding about naming, functions responsibilities or about how clear we express intents in the code for us and for other? Very often! How often we will use a particular “big” design or architectural pattern? No so often. We cannot decide to use refactoring or clean code only later, in the next release, next product or next month. We will rather use them daily. Not all the rules, not always, we will still need to decide where, what and how. We can combine various sources and we are free to innovate.

Figure 1 - Design Decisions Timing Pyramid

WHAT IS CLEAN CODE?  It is a set of principles & practices for getting a good software design that are rather generic and are applied to some categories of design decisions that occur very often.

CLEAN CODE IN CONTEXT. Each design decision must consider the opportunity in context. Decisions about applying these principles & practices are still related to context, that including also the necessary “amount of care”. In some cases, such building a small throw-away prototype we could spend less time and consume less effort on getting the code clean, but we will still do it because we still need to read the code and we need to not get false-positive or false-negative answers caused by messy code.

IMPACT OF THE CLEAN CODE/MESSY CODE.  We take a lot of small design decisions each day, each hour and each minute. All these rather small decisions will massively influence our product design and architecture, our product technical debt. This a cumulative process. If we check the code of a software product that is hard & change with symptoms like fragility, rigidity, viscosity, we will find un-necessary complexity related to messy code.

IMPACT ON USAGE. A messy code with a lot of technical debt will have more bugs, bugs will be much harder to fix, changes will be harder to perform and more expensive. Depending on the criticality of the target system we will need a different “minimum amount of care” related to the software design. Also, similar problems could have a  much different impact in a different context.

IMPACT FOR DEVELOPMENT. Beyond repercussions resulted from the impact at usage, we will have a direct impact for development side. Simple, clean and adaptive code:    

• Contribute to better software economics for development side: easy and less expensive to build and change the software products.
• Increase the comfort (and decrease the stress) for the other developers that need to read, understand and change that code

A code with high technical debt that harms the development business will also harm the people that work for that business (beyond comfort, they could lose money or even their jobs).

INDUSTRY LEVEL PROBLEMS. One of the main problems of the software industry is the unnecessary, undesired complexity with all known resulted problems. Software development has as main traits: complexity, incertitude and knowledge work. Considering this generic context of the domain, we want to avoid producing unnecessary complexity by massive accumulation of technical.  Developers, teams, organizations need skills to manage this technical debt and keep it down in an appropriate way for the needs of target business but also for the needs of development side.

WE NEED CLEANER CODE. Software will rule the world. All aspects of our lives will be highly dependent on software. The software industry is growing, the number of developers is growing fast, but the necessary skills for avoiding big problems on software usage are not appropriate. The produced software is too messy to meet these needs. The software community must react and must reduce this unnecessary complexity of the software design.  

(LEARNING) HOW TO MAKE A CLEANER CODE. How do we learn refactoring and clean code? Can we select in which releases, components or products we will use them and in which we will not? Can we learn them for the next release? It is like a basketball player will train for running or for shooting only for specific games or competitions. You will always train, and you will always use them, but is your decision and your team decision how you will combine running, shooting and dribbling. You cannot learn how to build clean code or how-to refactor if that is not a long-term ongoing & collaborative activity.

 

HUMAN FACTOR ON CLEAN CODE. Clean code is a result of the whole team work. Each developer will take clean code/messy code decisions in every minute. If 20 developers produce messy code and 1-2 will occasionally clean & refactor, that is waste. Knowledge about refactoring and building a cleaner code must be shared between team members in many ways, but especially by collaborative work. More: one of the main benefits of the collaborative work will be cleaner code. Even senior developers will produce much cleaner code and better design if they learn from their colleagues. More, by helping others, you will understand which kind of design is more effective for working in a team.

CLEAN CODE AND TEAM WORK. One of the goals of clean code is to make the code readable for your team. Your colleagues will be able to understand and change your code. The existent code is an inherent source of learning for newer team members and juniors: you want to provide them good examples.

CLEAN CODE AND PRODUCT. The cleanness of the code (also by refactoring) massively contributes the design quality status of our product. We want a product that is easy to change? Keep it clean enough. We want quality? Keep it clean enough for the context.  We want agility? If the code is not clean enough forget about that.

CLEAN CODE IS ABOUT CARING. If you care about: your colleagues (to use your work, to learn, to have a job), your products and your company (better software economic: you can easily change the products), your customers (to avoid possible disastrous effects of messy code), then please keep your code clean. If you care about the effects of “software will rule the world” then collaborate with software community to improve the techniques & practices for making the code cleaner.    

PROGRAMMERS ABOUT CLEAN CODE

For “Clean Code” book Robert C. Martin “ask some very well-known and deeply experienced programmers what they thought”. Here are extracts from their responses

Bjarne Stroustrup: “I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.”     

Grady Booch: “Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.”

Dave Thomas: “Clean code can be read and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined and provides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone.”

Michael Feathers: “I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. (my note: this is my favorite description) There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you’re led back to where you are, sitting in appreciation of the code someone left for you—code left by someone who cares deeply about the craft.”

Ron Jeffries: “In recent years I begin, and nearly end, with Beck’s rules of simple code. In priority order, simple code:

•       Runs all the tests;

•       Contains no duplication; 

·        Expresses all the design ideas that are in the system;

•       Minimizes the number of entities such as classes

methods, functions, and the like.

Of these, I focus mostly on duplication. When the same thing is done over and over, it’s a sign that there is an idea in our mind that is not well represented in the code. I try to figure out what it is. Then I try to express that idea more clearly. […] “

Ward Cunningham: “You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.”

BIBLIOGRAPHY , REFERENCES

• Clean Code: A Handbook of Agile Software Craftsmanship 1st Edition ,by Robert C. Martin (The Object Mentors:Robert C. Martin, Michael C. Feathers Timothy R. Ottinger, Jeffrey J. Langr Brett L. Schuchert, James W. Grenning Kevin Dean Wampler), Prentice Hall; 1 edition (August 11, 2008)
• Refactoring: Improving the Design of Existing Code 1st Edition, by Martin Fowler (Author), Kent Beck (Author), John Brant (Author), Addison-Wesley Professional; 1 edition (July 8, 1999)
• Implementation Patterns 1st Edition , by Kent Beck, Addison-Wesley Professional; 1 edition (November 2, 2007)
• The Pragmatic Programmer: From Journeyman to Master 1st Edition
  by Andrew Hunt , David Thomas  , Addison-Wesley Professional; 1 edition (October 30, 1999)
• Code Complete: A Practical Handbook of Software Construction, Second Edition 2nd Edition, by Steve McConnell  Microsoft Press; 2nd edition (June 19, 2004)

Pitfalls using Agile

Fail to address domain core problems – do not cover core capability: adaptive & lean (with undesired results as slowness, low quality, expensive). Example: if your product is fragile, rigid and have a lot of technical debt (a symptom for Flaccid Scrum), there is no way to be Agile, and there is no way to have a good software economics. Example: if there is no collaborative work, there is no room for process improvement.  The first step toward a solution is to develop core capabilities around Agile Core Practices (as the ones recommended by XP and DA, beyond Scrum offer).  

Fail to address context problems – each context could have different kinds of risks and problems. The main pitfall is to copy-paste the process from one context to another. That is a common risk when are used “prescriptive” methods, with too few guidance for tailoring.  Example: we cannot copy-paste a process from a product with a lower complexity to another one with a bigger complexity. Example: releasing a whole new product is very different that a small release with a delta for an existing product. Example: An Agile scaling approach that does not have options per context.

Too small set of practices – When teams are relying only on practices existent in lightweight methods (as Scrum or XP), and the rest process has severe skill gaps or, it is too ad hoc. So, both domain and context problems could not be addressed well.  You cannot excel in managing software development only with 10-15 practices.

“Modernization” by dilution – any approach could evolve, but regression it is also possible. There are many attempts to modernize or enhance or “scale” Core Agile (Manifesto and Core Agile Practices). Everything is fine if the agility itself it is not diluted until disappearance. Any enhancement is good if will address the domain and context problems and offer responses for core needed capabilities: adaptive-lean and tailoring /context. 

Recommended readings

The Land that Scrum Forgot, by Robert C. Martin

• https://www.scrumalliance.org/community/articles/2010/december/the-land-that-scrum-forgot

 Flaccid Scrum, by Martin Fowler

• https://martinfowler.com/bliki/FlaccidScrum.html

Agile support for context problems

Many of the domain or context problems will be directly solved by Core Agile (Manifesto and Core Agile Practices). However, some of the problems cannot be addressed only with Core Agile or even with non-core Agile practices. 

What is the Agile response for adapting to context? 

 
The possible problems are induced by context related perturbation/scaling factors. Problems: teams cannot apply Agile practices because of context constraints, or you need to go beyond the 15-20 core practices to address the context.  

Expected response - I expect at least the following support from Agile and its methods:

• Support for Core Agile Practices, in order to directly backup Manifesto values and principles
• Description of main Scaling/Tailoring Factors 
• Guidance for  process tailoring in Context
  

Manifesto response – it has an indirect response: if you manage very well generic domain problems, you will maximize the remaining resources to address the context. Also, the generic development strength will be high.

Methods responses – each method try to address in some way the “adapt to context” problem. Their solutions are, anyway, quite different.

Scrum response – Scrum offer a very lightweight framework, with very few practices. For the rest of the process, it is supposed that teams/organizations will figure out what they need. The only guidance in the basic Scrum are the main principles: Transparency, Inspect and Adapt. Some Scrum extensions try to manage (only) the size scale factor.

XP response – XP offer a lightweight framework and a good coverage in overall Core Agile Practices. That mean XP is effective/efficient for solving core domain problems. What about context? Here are some XP solutions for context:

• XP recognize Scaling Factors (beyond team size)
• Offer some very short, but good guidance for dealing with the scaling factors
• XP main support for scaling it is its robustness and resilience on solving the core domain problems
• Recently Kent Beck describes its refreshed experience with software at scale: You Aren’t Going to Need It (YAGNI) could become, at scale, “You Are Going to Need It” [b8].

Scaling XP, Conclusion: “With awareness and appropriate adaptations, XP does scale. Some problems can be simplified to be easily handled by a small XP team. For others, XP must be augmented. The basic values and principles apply at all scales. The practices can be modified to suit your situation.” [b1]

Disciplined Agile Response – DA offer support for both aspects: a lightweight core of principles/practices /guidance to address the domain specific problems (as XP does), plus a guidance about how to adapt to context by offering a map of choices from important software engineering practices. In addressing core domain problems, DA add some few outstanding practices (as Agile Modeling practices) to core XP and Scrum, making the adaptive/lean support much more robust. In addressing the context problems, DA choose to offer guidance and not recipes:

• DA explicitly describe Scaling Factors
• Offers robustness and resilience on solving domain core problems
• Offers process tailoring guidance: options available per decisions points per generic process goals
• Offers Agile life-cycle options: basic, continuous delivery, advanced lean, exploratory lean startup
• Offers enterprise aware guidance: linking solution delivery with DevOps and Lean Enterprise.

Remember that Enterprise aspects are always part of the context and need to be addressed.     

Free-methods practices – there are outstanding Agile practices that are not part of the methods such as Clean Code, Clean Architecture, Adaptive Programming (Law of Demeter) that offer support for both domain generic and context problems. 

Bibliography and recommendations

[b1] Extreme Programming Explained: Embrace Change, Second Edition, by Kent Beck, Cynthia Andres, Addison Wesley Professional, November 16, 2004. Related sections: 

•  Chapter 15 – Scaling XP (and Conclusion)

• Chapter 20 – Applying XP   

[b2] Disciplined Agile 2.X - A Process Decision Framework:  www.disciplinedagiledelivery.com 

•  DA, Scaling Factors - http://www.disciplinedagiledelivery.com/agility-at-scale/scaling-factors/
•  DA, The Software Development Context Framework - http://www.disciplinedagiledelivery.com/sdcf/ 

[b3] DA, Agile Modeling - http://www.agilemodeling.com/

[b4] Clean Coders series, by Robert C. Martin

[b5] Scrum Guide, EN version only - http://www.scrumguides.org/

[b6] Interview with Kent Beck, by Andrew Binstock – Java Magazine November December 2016

[b7] Agile Software Development: The Cooperative Game, Second Edition, by Alistair Cockburn, Addison Wesley Professional, 2006

[b8] Making Your Methodology Crystal Clear and More, by Alistair Cockburn

• http://alistair.cockburn.us/get/3606