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.

The True Corruption of Agile (Robert C. Martin)

"You can't have a culture without practices; and the practices you follow identify your culture."  
(Robert C. Martin) 

Please read this post "The True Corruption of Agile" from Robert C. Martin blog:

http://blog.8thlight.com/uncle-bob/2014/03/28/The-Corruption-of-Agile.html

The above quote it is an answer to these statements (quotes from the same post):

Holub says:

"...agile is a culture, not a set of practices..."

Binstock amplifies:

"Whether a site is Agile or not depends on its culture. Does the culture support the personal values of the manifesto? If so, it's Agile, if not, then it's doing something else. So, indeed you could have a fully Agile site without TDD, continuous integration, or scrum. Likewise, you can have a site that uses all three practices, but cannot adapt to changes and is wholly inflexible in its work — so, not at all Agile."

 The answer of Martin continue (quote):

The biggest problem I have seen within the Agile movement is the elimination of the practices. One by one, over the years, the practices have been de-emphasized, or even stripped away. This loss of practice has diluted and changed the Agile culture into something that I don't recognize as Agile any more. It has been a shift away from excellence towards mediocrity, away from hard realities, towards feel-good platitudes.

It began with the notion that anyone could become a "master" of anything by sitting in a two day class and getting a piece of paper. Soon to follow was the dilution and eventual loss of the technical practices. This prompted Martin Fowler to publish his classic and definitive blog: Flaccid Scrum. Then came the emphasis of project management over craftsmanship and the rise of the soft skills (attitudes) over the hard skills (practices). 

The (Uncle Bob) conclusion is that you cannot have a culture outside a set of practices that are part of the professions, where both management and engineering culture is expressed with practices. Abandoning practices it is just a  "shift away from excellence towards mediocrity".

      

Binstock says that you could have full agile result also without significant practices such TDD, continuous and Scrum (related practices) , where all that count is to be adaptive to changes and being flexible in the work and the mentioned practices could not guarantee that.

Somehow, both are right, but Binstock example is not so good, because mentioned that you may have one case where... A better logic should be generic, not based on a possible example.

Yes, you could have not be enough adaptive with TDD, Continuous Integration and Scrum practices, but that because the number of indispensable practices is much bigger.

Yes, you could be adaptive without these three practices, but not for any case but only for some cases. Example: the Agile Manifesto promise to support late changes with good results it is mostly impossible without TDD. 

"Adaptive to change" - I have tried to define this capability reflected in a set of indispensable practices for engineering aspects in the post "A roadmap to an Agile Design" on agiledesign.org (see http://agiledesign.org/2014/09/09/i-roadmap-to-an-agile-design/ ).

Agile could be a "mindset", but not acquired by two days course (that could help), but from hard work and deep experience with applying of engineering and management practices.  

A Declaration of Practice Independence (from Ivar Jacobson)

A Declaration of Practice Independence

We hold these truths to be self- evident, 
that all practices are created equal,  
that they are endowed by their Creator with certain unalienable Rights, 
that among these are life (constant evolution), liberty (method independence) and the pursuit of excellence.
 (Ivar Iacobson)

Sources:
http://www.ivarjacobson.com/google_presentation/
http://www.ivarjacobson.com/uploadedFiles/Pages/Knowledge_Centre/Resources/Presentations/Resources/SEMAT%20presentation%20at%20Google.pdf


My thoughts about practices:

• could and should be used outside the (original) methods
• could and should be used even are not in some methods (the problem with Agile Design,  Clean Code and Clean Architecture - see agiledesign.org )
• modern methods such DAD - Disciplined Agile Delivery have a better and flexible approach about practices and offer guidance on selecting them in context
• building process it is (also) about selecting practice in context
• BUT ... there are some remaining questions. Do you know that are the remaining questions?

Agile Design - new site/blog - agiledesign.org

http://agiledesign.org 

Here are the reasons to dedicate a distinct site/blog to the problems and solutions related to Agile Design.

Agile software development make a strong promise to the customers – that will offer good results (sustainable, effective, efficient) for an adaptive context (quick, often and even late).

In most of the cases , the claimed Agile process does not keep the full promise, especially for toughest parts:

• a sustainable,  long term collaboration with the customer
• good response for late changes

The main reason is the lack of coverage of some aspects related to design. The teams does not use all necessary engineering practices, or in the worst case are considering only Agile management practices.

There must be a better way!

We need to define a set of indispensable design related practices and use them in order to to keep the promise. There must be an Agile Design, defined as an Adaptive Design and used to build Adaptive Products.

An introduction to Agile Design propsal could be found here:

http://agiledesign.org/2014/09/09/i-roadmap-to-an-agile-design/

"Upgrading" Pair Programming (2) - Non-Solo Development

Notes

.

•  See http://agiledesign.org/2014/09/09/i-roadmap-to-an-agile-design/ for a view of Non-Solo Developmental in context of practices for an Agile Design
• Non-Solo Development it is Agile practice explicitly included in DAD - Disciplined Agile Delivery method
• Here it is presented a custom experience with this practice
• See previous : http://agileand.blogspot.ro/2014/09/upgrading-pair-programming.html  

Introduction

Non-Solo Development it is an Agile practice that goes beyond programming/coding ("Pair Development") and could combine pairing and solo-development techniques in a mixed approach.

Pair Programming and any other Pair Development techniques could bring significant advantages on fulfilling some process goals as: better decisions, collective ownership, knowledge sharing and fast learning. Anyway, many times, the decisions to adopt or not the pairing it is seen as an option between:

• Full-time Pair Programming/Pair Development 
• Solo-Development (no pairing)

That it is a false and harmful dilemma.

We will see later  that:

• It is mandatory to use, at least for critical decisions, a mixed approach of Non-Solo Development, in order to not jeopardize some significant process goals
• Discipline it is a major factor for getting good results from cooperative development  

 

Non-Solo Development - goals and techniques

.

The main goals of Non-Solo Development could be:

• increased capability of taking decisions
• sharing knowledge and collective ownership
• effective learning

N-SD could be successfully in combining pairing with solo development only if the most important parts related to these goals are realized. For example, pairing it is mandatory for taking the most important decisions.

In fact, there are 3 techniques that could be used:

• Pair Development 
• Solo Development 
• Simple Conversation (just inform the others, and if is necessary, switch to Pair Development)

 

Comparing mixed approach with pure pairing 

. 

(Mixed - combine paring with solo development and conversations)

Pairing advantages

• force/ensure collaboration (built-in discipline)
• larger channel of sharing  the information 

Mixed approach advantages

• more flexibility on using resources versus concurrent tasks
• enable sometime necessary solo-development
• enable direct collaboration beyond pairing: 3 or more persons (up to "mob" development) 
• seems to be more "natural" 

IMPORTANT: Mixed approach is more flexible , but it is very fragile in case of  poor collaboration  discipline. 

 

Pairing/Direct collaboration need

. 

When pairing and direct collaboration are highly desired? When the work is associated with critical parts related to the goals:

• most important decisions 
• sharing critical info
• learning critical issues

Because of that, we can evaluate some significant practices versus N-SD approach:

• All the practices
• N-SD it is mandatory at least as a mixed approach

• Architecture envisioning , Look Ahead Modeling
• Some of the most important decisions related to the solution - direct collaboration must be also used
• Model Storming 
• Need pairing at least to validate and inform
• The practice from AM - Agile Modeling suppose mostly the direct collaboration
• Requirements clarification
• Need pairing at least to validate and inform
• Coding
• Need paring at least for significant decisions: transforming to code the ones from the envisioning and modeling and for the ones taken directly in the code 

For some of the mentioned practices, see http://agilemodeling.com/.  

 

Mixed approach example - discipline versus problems

.

A, B, C, D are agile developers involved in a software project. Here it is possible disciplined  sequence of activities based mainly on Non-Solo Development and inspired from a real case (Where A,B or A,B,C means paring/direct collaboration):

• A - Requirements clarification with the customer
• A, B -  Requirements analysis
• A - document requirements 
• A, B -  Requirements clarification with the customer
• A,B, C - Requirements conversation 
• A - document requirements
• A, B - Architecture Envisioning
• A,B, C - Architecture conversation
• B - Look Ahead Modeling
• B, C - Look Ahead Modeling
• A,B,C  - Design conversation 
• B - Solo Programming
• B, C- Pair Programming 
• B - Solo Programming
• A,B, C - Programming Conversation

The above sequence could have fulfill all the listed goals: capability, sharing, collective ownership ans fast learning.
Let consider another sequence:

• A - Requirements clarification with the customer
• A - Requirements analysis
• A -  document requirements, but not saved in the repository
• A, C - Requirements conversation 
• A - Architecture Envisioning
• A, C - Architecture conversation
• A - Look Ahead Modeling
• C - Solo Programming

For this sequence, with significant less discipline on adopting direct collaboration on critical parts, we have the following problems:

• B it is totally excluded from collective ownership and C only partial
• Most of the important decisions have been taken by a single person 
• There is no sharing for a lot of information 
• B and C will need a significant effort to recuperate the gaps in their knowledge

Some conclusions

• Full paring could be optionally, but direct collaboration, at least for critical development decisions, is mandatory for good results on both short and long terms
• Discipline on adopting cooperative development it is essential  
• Solo-development hast its place in the process, but individualism has not 

"Upgrading" Pair Programming

Re-interpreting Pair Programming

NOTE:  See http://agiledesign.org/2014/09/09/i-roadmap-to-an-agile-design/ for a view of Non-Solo Developmental in context of practices for an Agile Design

XP has introduced Pair Programming as an essential Agile practice. PP is a form of very direct cooperative work: “2 people working at a single computer”. This practice try to boost the most important activity in an Agile process, the coding, using the strongest form of direct collaboration inside the team. 

Remember that Agile uprising against traditional approaches (read Waterfall) has tried to restore the importance of the coding as the true ground to deal with the design and architecture. That was an uprising against the “paper architects”, that try to delimit themselves from concrete code and coding. 
Agile states that “Code is design”, that mean real design and real architecture are only the ones finally realized and validated by the real code and not the ones just drawn on paper.

Pair Programming it is a highly effective practices, but the remaining question if has enough coverage to describe the needed cooperative work inside the team.

Unfortunately,  the practice name it is interpreted too literally, only for direct coding activities. Yes, Agile has restore the importance of the coding in the overall development, but let think a little: what is the meaning of “Programming” from XP name?
In fact it is “Development”, where the effective programming/coding it is, of course, very important. An XP programmer it is, in fact, a multi-role developer involved also in planning, requirements, architecture, and design, coding and testing. A much better term could be then “Pair Development”. 
Also, the “pairing” could be the most common approach, but a “cooperative development” could occasionally include more developers.

The extensions points for high-cooperative work are: 

•  including all the development related actvities
• considering more than 2 developers, when pairing and direct collaboration it is alternated with solo-development 

Non-Solo Development

In DAD (Disciplined Agile Delivery), Scott W. Ambler has introduced the term and the practice of “Non-Solo Development” for this extended cooperative development approach. See: 

http://disciplinedagiledelivery.wordpress.com/2011/09/13/non-solo-development/\

http://www.ambysoft.com/essays/agileTesting.html#NonSoloDevelopment

From my experience (in various projects,/products /teams/development cases) this practice was very useful for very difficult complex cases of requirements clarification, finding best architecture and design decisions, in very difficult bug-fixing activities, or even in complex planning. 

There are two main dimensions for defining cooperative development:

• Type of activity 
• “coding” (working with on the code, while design decisions are also included)
•  other: requirements, architecture/design, testing, planning
•  mixed (combining related types)
•  Type of collaboration
•  “pairing” (usually 2 persons)
•  combined:  mixing solo-development with "pairing" (2 or more persons)

	“Pairing”	Mixed
Activity - “Coding”	Pair Programming	Non-solo Programming
Activity – Modeling	Pair Modeling	Non-solo Modeling
…	…	…
Activity - Mixed	Pair Development	Non-Solo Development

Existent examples

Some already existent Agile practices are in fact sub-parts of Non-Solo Development 

• Planning Poker, Sprint Planning (and any re-planning) -  are Non-Solo Development practices where the goal is planning, but the activity types are rather mixed (requirements, solution, planning)
• Model Storming (from DAD) - the main activity type is design

Conclusions…we need both

Conclusions - I

• The most generic category/term is “Non-Solo Development” and “Pair programming” it is just a particular case

Conclusions - II

• “Non-Solo development” cannot replace “Pair Programming” because that practice has a specific, very important role in Agile and software development. “Non-Solo development” just add other missing aspects of  cooperative work 
•  It is better to be always to distinct  (by name)
•  Pair Programming  - a practice that want to boost the core activity , the “coding”
• Pair Development – a practice where the overall development is performed mainly  by pairing
• Non-Solo Development – the generic case, when are combined more than one type of activity and are involved more than 2 persons

 

Some practical results

When we have used "Non-Solo Development" for the above mentioned activities the number of involved persons was 2-3 and sometime more. Some interesting results of the experiments:

•  Overall results are much better when we have involved 3 team members instead of 2 for the specific cases with increased difficulty
• The most experienced/skilled people have a bigger ability and desire to perform cooperative work (the others have still something to prove by solo-development…)
• Unfortunately, the resulted practice from team self-organization it is solo-development. The cooperative works need to be “protected” by the most experienced team members.
• The learning curve about product knowledge has significantly improved

For goals, techniques and examples see Part 2:

http://agileand.blogspot.ro/2014/09/upgrading-pair-programming-2-non-solo.html

Agile "Missing Link": Adaptive product - Scenarios when you are not Agile

Does not matter the adopted practices, and the Agile claiming:  a team will be Agile only if will be able to respect the Agile values and principles in a steady manner, by serving the customer business also on medium and long term. That suppose also having Adaptive Products (see previous post).

Here some scenarios when the product is not adaptive, and that will not qualify that team for real Agile development.

Big Bang Delivery of new product

Similar with that cosmic (hypothetical) phenomenon, you could try to deploy to the market to more customers a completely new product (or a significant part) where the functional and non-functional attributes (performance, usability and others) are not yet subject of a real business feedback (from production usage). 

Does not matter if you have Small Iterations, Product Backlog, Self-Organization, or Technical Excellence, because are missing Often Delivery and Close Customer Collaboration. Usually, when you are building a new product will collaborate rather with one customer, that mean you are really close only to that customer. Also there is high probability that both functional and non-functional product proprieties will not fit too well for the rest of the customers.

There is the custom to have a "pilot" deployment, but that it is not enough, because, after the pilot should not be adopted the Big Bang delivery, but, also in this case, an incremental approach. 

See Scott W. Ambler solution "An Exploratory “Lean Startup” Lifecycle"
https://disciplinedagiledelivery.wordpress.com/2014/04/25/an-exploratory-lean-startup-lifecycle/

Long projects - Big Releases

 

It is a similar context with the "Big Bang" delivery to multiple customers. The Work In Progress will be too long, your result will get too late a real business feedback. Many feature could not match with real business needs or could become deprecated.

Anyway, big releases are not Agile also because the Agile solution for complexity of the software projects are the Small Releases. 

Spaghetti Code, Big Technical Debt 

 

Poor design , Spaghetti Code, accumulated Technical debt will reduce the product adaptability, the reaction to changes, the overall quality (the list of damages remain open). Such products are definitely destroy the agility.

Just a good design ...

 

"Continuous attention to technical excellence and good design enhances agility. "  that is a great principles from Agile Manifesto.

Well ... That is not enough, from technical point of view, to sustain the Agility!

A real agile product must be an ADAPTIVE PRODUCT, where the business is well modeled, it is decoupled from the technological aspects. The business representation inside the product should have the following properties for supporting Agility:

• must survive with smaller costs, quick adaptation and no quality problems to the technological changes
• must support also quick adaptation, with smaller cost and no quality problems to the business changes

Two design principles will give the biggest help to realize these capabilities

• Separation of concerns - especially to decouple technological aspects from business aspects. Also could be applied to decouple different technological parts from one of other , or business aspects
• Functional cohesion - should be the main instrument in injecting the business DNA into the product, where the software system design should match its functions 

An agile product must have a "Business DNA" , realized by functional cohesion and protected by separation of concerns and a good design.

My witness :-)

Well, if you do not believe me, maybe you trust in Robert C. Martin.  His design principles are a great "testimony" in favor of Separation of Concerns (Single Responsibility, Dependency Injection). I recommend also these presentations, that promote Functional Cohesion as main attribute of a good architecture.

Clean Architecture and Design-2012 COHAA The Path to Agility Conference

https://www.youtube.com/watch?v=asLUTiJJqdE

Ruby Midwest 2011 - Keynote: Architecture the Lost Years by Robert Martin

https://www.youtube.com/watch?v=WpkDN78P884

Agile "Missing Link" (2): Agile product = Adaptive product

Product problems compromise value delivery

 

Agile most marketable and viral aspect it is “value delivery”. That sounds great, but that will not solve all the problems of the software development and also it is just a one-dimensional representation of Agile.

The biggest remaining problem for Agile development are the product problems.  Often delivery and small releases will address some well known problems in software development that too often will cause project failures. Small releases, working software and close customer collaboration will reduce the project level complexity, one of the major reasons for these failures. 

What about product problems? Generic problems are related with accumulation of technical debt, brittle architectures and loss of intellectual control over the product knowledge. We need a solution also for that aspect.

Technical Excellence

A great response to such problems it is introduced by Agile Manifesto by demanding “technical excellence” and good design. Jeff Sutherland says that as a conclusion after 10 year of the Agile Manifesto, “technical excellence” it is a key factor of success of Agile teams.

The question is if these two principles to follow - close to the customer and technical excellence - are sufficient to cover all kinds’ of possible problems.

Others problems

A tough real-life scenario is related to new products or new significant part of the product that need to be distributed, deployed to more clients. An initial one-time distribution to more clients it is rather Waterfall than Agile despite the fact that developing could use iterations and customer collaboration. There are several reasons for that: a full-new product deployment it is equivalent with a big release (also with a rare delivery) and it is hard to imagine that we will work close with all the customers.  

A great Agile solution for such kind of problem suppose, an (obviously!) incremental approach. Scott W. Ambler has described such solution here (“An Exploratory “Lean Startup” Lifecycle”):

http://disciplinedagiledelivery.wordpress.com/2014/04/25/an-exploratory-lean-startup-lifecycle/

 This problem and the product knowledge problem need supplementary solutions.

Solution step #1 – Inject the business 

 

The main conclusion is that we have a supplementary dimension of Agility beyond often delivery: we need to often and continuously inject back the business into the product. The product should be kept close to the business where will be integrated.   

Solution step #2 – Products with “Business DNA”

 

Other question:  how we could know that that business “injection” will be effective, when some recurrent problems are the loss of the intellectual control over the product knowledge and the product fragility because of increasing technical debt. Let remember what will request Robert C. Martin if will be your CTO (): "We will not ship shit.", "You will always be Ready.”, "Inexpensive Adaptability."

We will always be ready with inexpensive adaptability if will be performed a creative work to model that business before include it in the product.

The deliver product or product change will need to “live” inside the customer business and will need to adapt and evolve in that environment. 
.

In order to realize a „natural” evolution inside the target business, the software system must have „Business DNA”. Translating that in engineering measures that mean all architectural aspects must serve that business integration.
.

 

Solution step #3 – Implementing the “Business DNA”

 

There are some software engineering instruments that could build and protect the „Business DNA” for a software product.
.

Functional cohesion

• The core structure of the software should match the real business functions. A change in the business will be reflected with minimum effort and with maximum quality in these cases
• That will be the core representation of Business DNA

Separation of concerns

• Beyond any particular architectural or design patterns, a basic rule is to kept distinct concerns decoupled. A default separation should be the one between technological aspects and functional aspects
• That will protect the Business DNA from technological changes

Good design & technical excellence

• Good design will enhance any software development enterprise  

Solution step #4 – Agile product = Adaptive product

The missing link in Agile Development seems to be a principle that requires an “Adaptive Product”, with good design and “business DNA”. We should always think to “Agile Products” as “Adaptive Products”.

Agile products - an Agile "Missing Link"

Agile Manifesto: "Customer collaborations", "Early and continuous delivery", "Deliver working software frequently", "Business people and developers must work together daily".

Extreme programming: "Make frequent small releases.",  "This is critical to getting valuable feedback in time to have an impact on the system's development. The longer you wait to introduce an important feature to the system's users the less time you will have to fix it".

Scrum: Maximizing value delivery.

Yes,  all the Agile logic it is about serving the customer business by delivering value, early and often and by a close collaboration.

That sounds great, but it is only one viewpoint.

Our software should be developed in above mentioned manner ... The product must be able to follow the customer business...But that mean should be in proper shape for a such endeavor. It is that simple? I think it is a little more complicated.

In each moment of time, the product need to be easy and quickly adapted to some new requests that corespondent do some new business needs. It is that simple?

When time = zero. The product it is new and need to be deployed to more customers - there it is a big probability that many product features to not match to the business.

When time = several years. The product it is "old" by accumulating a lot of technical debt and the respond to the changes become slow.

We need to care about customer business, but in the same time we need to care about the product! 

There is a TWO WAY ROAD TO AGILE :

• Development to Business -  DELIVER VALUE to the customer
• Business to Development - INJECT BUSINESS into the product 

 "Delivering value",  "Delivering value",  "Delivering value" ... in fact there is more than that. The delivered product will "live" in the customer business process and need to be able to evolve and adapt with that business. The BUSINESS DNA must be injected into the product, in order to accomplish such goals.

Here some useful principles:

- adapt the product to the business

• with the same pace with early, continuous and frequently delivery of valuable software.
• with  close customer collaboration, "business people and developers must work together daily throughout the project."
• with "small releases" (~XP), because any big release will lose contact with the busines
• with  "constant pace indefinitely", that suppose low level of Technical Debt
• with a good visibility and work optimization via a a well refined Product Backlog

- keep this business clean: easy to read and change inside the product 

• "well crafted software", "technical excellence and good design" - that enhance adaptability
• "steadily adding value"
• Test-driven development - the business value is constantly and often checked and demonstrated
•  TDD sustain refactoring and refactoring sustain adaptability
• Clean Code and less Technical Debt
• System Architecture that serve the business concerns

(Quotes, principles and practices from: Agile Manifesto, XP, Scrum, and  Software Craftsmanship Manifesto)

There are two different Agile promises
- "We are Agile and currently we can serve your business" - management practices from Agile can support a such promise - such many of the Scrum Practices
- "We are Agile and we can serve your business now and indefinitely" - that need all the engineering parts that suppose "steadily adding value" , technical excellence and management of the Technical Debt.

The product level concerns: inject the business and keep that business clean are mandatory for that second and stronger promise.

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