Anti-Viscosity

Agile Delivery - Anti-Viscosity

Robert C. Martin establishes viscosity as a ‘Symptom of Rotting Design’. Developers who need to make a change to a system can either follow the rules of the software architecture and design or implement a quick hack. If doing the hack is easier than following the design this is a symptom of viscosity. In other words: It is easy to do the wrong thing, but hard to do the right thing.

Anti-viscosity demands that following the architecture is the easiest path. High integrity is not enforced, but suggested.

Low Rating:

  • There are a multitude of rules, comprising a binding ‘architectural standard’
  • Diversity in the solution space is seen as a problem and labeled ‘inconsistency’
  • Innovation is driven by a view appointed masterminds
  • Communication is oriented towards teams and focuses on how to do things the right way.
  • Problems are seen as setbacks and associated with unprofessional behavior or personal mistakes

High Rating:

  • Soft standards are in place – consisting of suggestions with associated goals. It is allowed to deviate from suggestions, but the goals are binding
  • When developing a solution it is easy to stay within the communicated architectural ideas. Blueprints, templates, libraries and/or central roles support it
  • Architectural principles and guiding values are well established and communicated
  • Innovation is driven by everybody, constantly challenging the status-quo

Core Ideas

Create soft standards and suggestions

Software developers try to solve problems. Complicated software designs or difficult-to-use APIs and frameworks prevent them from doing so. Blueprints of architectural solutions, libraries or ready-to-use artifacts make it easier to focus on the problem, not on the technology. Solutions and technical ideas are not forced onto developers though. Divergence is allowed within basic boundaries. Soft standards are established by making suggestions easy to follow.

Provide organizational support

Often software architecture is defined and documented meticulously and then expected to be followed. Software developers having ad hoc questions are referred to the documentation. Instead the organization needs to install ways to provide support to answer questions around and challenges with the existing architecture. Offering this support can enhance anti-viscosity over time, provided it is easier to follow a supported technology path than to invent a new one.

Install principles and guiding values

Hard rules define exactly what to do in different situations. They usually consist of simple if-then-else decision trees, which makes them easy to define and check. But it also makes them inflexible and rigid. We instead try to install principles and guiding values. They describe how we want to work together and what we try to achieve. The specific solution can then be decided by those doing the work.

Sector Rating Aspects

These are aspects that can be used to assess your performance and maturity in this sector. For a detailed explanation please have a look at our how to page

AspectAdoption Lifecycle
Basic architecture principles are available as a blueprintLate majority
Central architecture boards discuss, share and improve architecture proposalsEarly majority
Architecture proposal creation is incentivizedEarly majority
Specialists’ support is requested in a pull-approachEarly majority
Architecture proposals are used instead of hard architecture governanceEarly adopters
A few well formulated architecture principles are used to guide decisions (principles vs. rules)Early adopters
Deviations from central proposals are motivated by teamsEarly adopters
Self-service infrastructure is offered for easy accessEarly adopters
Software evolution is driven by architectural and quality goals, not rulesInnovators
Tested and validated solution proposals are offered to others in an internal marketplaceInnovators

Connections

Connections

  • Empirical Process Control: Stimulate proposals and an evolutionary creation of your macro architecture.
  • Feedback & Transparency: Measure proposal quality to incentivize the implementation and maintenance of proposal-based solutions.
  • Responsibility: Install identification with proposals and solutions in order for teams to realize when to not follow the easy standard path.