The document discusses avoiding software insanity by maintaining technical quality and structure. It identifies symptoms of architectural erosion like rigidity, fragility, and opacity. Technical quality is defined and aspects like architecture, metrics, coding rules, and test coverage are explained. The costs of neglecting structure and allowing technical debt to accumulate are outlined. Methods to measure technical quality factors like architecture, structure, metrics, rules, and test coverage are provided. Finally, some simple rules for maintaining a structured architecture and package design are recommended to create high quality software.

1. Avoiding Software Insanity
Joseph Naveen
Extended Enterprise Pte Ltd.,
20:21 1

2. Code Quality?
Nice to have, but we can address that later…
Does that sound familiar?
Interactive poll:
Do you have binding rules for code quality?
Is your architecture defined in a formal way?
Do you measure quality rule violations on a daily base?
Do you measure architecture violations on a daily base?
Does quality management happen at the end of development?
Do you think, that more needs to be done in that area and that this would be
beneficial for the team and the company?
24.04.12 2

3. Part I: Well Known Symptoms of Complexity
20:21 3

4. What is Software Entropy?
“The tendency for software, over time, to become difficult and costly to
maintain.”
A software system that undergoes continuous change, such as having
new functionality added to its original design, will eventually become more
complex and can become disorganized as it grows, losing its original
design structure.
20:21 4

5. Erosion of Architecture – Symptoms (Robert C. Martin)
Rigidity – The system is hard to change because every change
forces many other changes.
Fragility – Changes cause the system to break in conceptually
unrelated places.
Immobility – It's hard to disentangle the system into reusable
components.
Viscosity – Doing things right is harder than doing things wrong.
Opacity – It is hard to read and understand. It does not express
its intent well.
Overall: “The software starts to rot like a bad piece of meat”
20:21 5

6. Erosion of Architecture – Reasons
System knowledge and skills are not evenly distributed
Complexity grows faster than system size
Unwanted dependencies are created without being noticed
Coupling and complexity are growing quickly. When you realize
it, it is often too late
Most projects don’t measure quality on a regular base
Management considers software as a black box
Quality measurement is done at the end of development
Time pressure is always a good excuse to sacrifice structure
The Law of Entropy?
20:21 6

7. Part II: Technical Quality
24.04.12 7

8. What is Technical Quality
“Technical quality of software can be defined as the level of conformance of
a software system to a set of rules and guidelines derived from common
sense and best practices. Those rules should cover software architecture,
programming in general, testing and coding style.”
Technical quality affects:
Testability, Expandability, Maintainability, Comprehensibility
It cannot be achieved by testing only
Technical quality has the following aspects
Architecture and dependency structure of the code
Software metrics
Common sense coding rules
Test coverage
24.04.12 8

9. Cost of Structural Erosion / Technical Debt
20:21 9

10. Structure vs. Defects
Structure vs. Time to Change
Structure vs. Cost to Change
24.04.12 Courtesy: NIST 10

11. How to Measure Technical Quality
Architecture
Measure number of dependencies violating architecture rules
Structure
Measure size and coupling of package cycle groups in relation to the size of the
system
Metrics
Define a reasonably (small) number of metric thresholds and measure the
number of threshold violations
Coding rules
Use automated rule checkers and configure a reasonable set of guidelines and
rules. Measure number of rule violations
Test Coverage
Run your unit tests with a coverage tool to measure the test coverage. Focus
efforts to improve coverage on complex code
24.04.12 11

12. How to model Architecture
Your System
Natural subsystems
User Interface
Customer
Contracts
Common
User
Business Logic
Data Access
• Step 1: Cut horizontally into Layers
• Step 2: Cut vertically into vertical slices by functional aspects
• Step 3: Defines the rules of engagement
20:21 12

13. 24.04.12 13

14. Cyclic dependencies are evil
"Guideline: No Cycles between Packages. If a group of packages have
cyclic dependency then they may need to be treated as one larger
package in terms of a release unit. This is undesirable because
releasing larger packages (or package aggregates) increases the
likelihood of affecting something." [AUP]
"The dependencies between packages must not form cycles." [ASD]
"Cyclic physical dependencies among components inhibit
understanding, testing and reuse. Every directed a-cyclic graph can be
assigned unique level numbers; a graph with cycles cannot. A physical
dependency graph that can be assigned unique level numbers is said to
be levelizable. In most real-world situations, large designs must be
levelizable if they are to be tested effectively. Independent testing
reduces part of the risk associated with software integration " [LSD]

15. How to measure coupling
ACD = Average Component Dependency
NCCD: normalized cumulated component dependency
Graph 2 (CCD=19) Graph 1 (CCD=23)
ACD = 3.29 ACD = 2.71
20:21 15

16. Example : Cyclic Dependency
Presentation Model
Main
AlarmClock
AlarmHandler
AlarmToConsole
AlarmToFile

17. Breaking the Cycle
<<bottom>>
Presentation Model
Main AlarmClock
<<abstract>> <<interface>>
AlarmHandler IAlarmHandler
AlarmToConsole
AlarmToFile

18. Example : Another Cyclic Dependency
Order Customer
Order
__________________
Customer
Customer cust; ___________________
Order[] listOrders() { …}

19. Example : Breaking the Cycle
Order Customer
Order
__________________
Customer cust; Customer
static Order[] listOrders(Customer c) { …} ___________________

20. Structural Debt Index
This metric measures structural erosion by analyzing cyclic
package dependencies. Very good for tracking project health.
24.04.12 20

21. Part III: How to Create a Master Piece ?
24.04.12 21

22. Improvement requires Awareness
Six Sigma for Software
24.04.12 22

23. Measurable Quality must be a Process Goal
You can’t reach high quality if you do not measure it (daily !)
It is also of no use if you do measure, but don’t use the
measurements (why do I have to mention that ??)
Quality as a goal must be backed an enforced by the
management (requiring more than just getting the job done)
Things will always get worse, before they get better (getting rid
of old habits is always difficult)
Its all about people, processes and tools (in that order)
But it also does not work without tools – the process must be
automated as much as possible
Potential gains are tremendous
Start simple – fewer rules are better
24.04.12 23

24. Some Simple Rules for a Masterpiece
Rule 1:
Define a cycle free logical architecture down to the level of subsystems
and a strict and consistent package naming convention
Rule 2:
Do not allow cyclic dependencies between different packages
Rule 3:
Keep the relative ACD low (< 7% for 500 compilation units, NCCD < 6)
Rule 4:
Limit the size of Java files (700 LOC is a reasonable value)
Rule 5:
Limit the cyclomatic complexity of methods (e.g. 15)
Rule 6:
Limit the size of a Java package (e.g. less than 50 types)
20:21 © 2005-2011, 24

25. “Designing Quality Software” Refcard
Download from www.ext-ent.com
24.04.12 25 © 2005-2011,

26. Relevant White-Papers:
Download from www.ext-ent.com
24.04.12 26 © 2005-2011,

27. QUESTIONS?
Contact
Joseph Naveen
joseph@ext-ent.com
www.ext-ent.com
+919003035025
20:21 27