Avoiding Software Insanity

27
17:16 1 Avoiding Software Insanity Joseph Naveen Extended Enterprise Pte Ltd.,

Transcript of Avoiding Software Insanity

Page 1: Avoiding Software Insanity

10:02 1

Avoiding Software Insanity

Joseph Naveen

Extended Enterprise Pte Ltd.,

Page 2: Avoiding Software Insanity

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?

12.04.23 2

Page 3: Avoiding Software Insanity

Part I: Well Known Symptoms of Complexity

10:02 3

Page 4: Avoiding Software Insanity

What is Software Entropy?

10:02 4

“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.

Page 5: Avoiding Software Insanity

10:02 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”

Page 6: Avoiding Software Insanity

10:02 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?

Page 7: Avoiding Software Insanity

Part II: Technical Quality

12.04.23 7

Page 8: Avoiding Software Insanity

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 aspectsArchitecture and dependency structure of the code

Software metrics

Common sense coding rules

Test coverage

12.04.23 8

Page 9: Avoiding Software Insanity

Cost of Structural Erosion / Technical Debt

10:02 9

Page 10: Avoiding Software Insanity

12.04.23 10

Structure vs. Cost to Change

Structure vs. Defects

Structure vs. Time to Change

Courtesy: NIST

Page 11: Avoiding Software Insanity

How to Measure Technical Quality

ArchitectureMeasure number of dependencies violating architecture rules

StructureMeasure size and coupling of package cycle groups in relation to the size of the system

MetricsDefine a reasonably (small) number of metric thresholds and measure the number of threshold violations

Coding rulesUse automated rule checkers and configure a reasonable set of guidelines and rules. Measure number of rule violations

Test CoverageRun your unit tests with a coverage tool to measure the test coverage. Focus efforts to improve coverage on complex code

12.04.23 11

Page 12: Avoiding Software Insanity

10:02 12

Your System

User Interface

Business Logic

Data Access

How to model Architecture

• Step 1: Cut horizontally into Layers

• Step 2: Cut vertically into vertical slices by functional aspects

Co

ntr

act

s

Cu

sto

me

r

Use

r

Co

mm

on

• Step 3: Defines the rules of engagement

Natural subsystems

Page 13: Avoiding Software Insanity

12.04.23 13

Page 14: Avoiding Software Insanity

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]

Page 15: Avoiding Software Insanity

10:02 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

Page 16: Avoiding Software Insanity

Example : Cyclic Dependency

AlarmClock

AlarmHandler

Presentation Model

Main

AlarmToConsole

AlarmToFile

Page 17: Avoiding Software Insanity

Breaking the Cycle

AlarmClock

<<abstract>>

AlarmHandler

Main

<<interface>>

IAlarmHandler

AlarmToConsole

AlarmToFile

Presentation<<bottom>>

Model

Page 18: Avoiding Software Insanity

Example : Another Cyclic Dependency

Customer___________________

Order[] listOrders() { …}

Order Customer

Order__________________

Customer cust;

Page 19: Avoiding Software Insanity

Example : Breaking the Cycle

Customer___________________

Order Customer

Order__________________

Customer cust;static Order[] listOrders(Customer c) { …}

Page 20: Avoiding Software Insanity

Structural Debt Index

This metric measures structural erosion by analyzing cyclic package dependencies. Very good for tracking project health.

12.04.23 20

Page 21: Avoiding Software Insanity

Part III: How to Create a Master Piece ?

12.04.23 21

Page 22: Avoiding Software Insanity

Improvement requires Awareness Six Sigma for Software

12.04.23 22

Page 23: Avoiding Software Insanity

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

12.04.23 23

Page 24: Avoiding Software Insanity

10:02 © 2005-2011, 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)

Page 25: Avoiding Software Insanity

“Designing Quality Software” Refcard

12.04.23 © 2005-2011, 25

Download from www.ext-ent.com

Page 26: Avoiding Software Insanity

Relevant White-Papers:

12.04.23 © 2005-2011, 26

Download from www.ext-ent.com

Page 27: Avoiding Software Insanity

10:02 27

QUESTIONS?

Contact

Joseph Naveen

[email protected]

www.ext-ent.com

+919003035025