Transitioning to quality software

Transitioning from working software to quality software

a.k.a. caring instead of peonage

What is peonage?

Constantly growing technical debt in the name of business needs. This results in a code base that makes it more expensive to respond to changes over time. More and more programmers are hired to keep control of the evolving code base. This leads to Defect-Driven Development, where developers keep introducing more defects while trying to fix them. The code is constantly monitored and hacked while trying to converge to it's original intention.

Ward Cunningham first drew the comparison between technical complexity and debt in a 1992 experience report:Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

What is Technical Debt?

What generates Technical Debt?

Pressure Lack of skills Lack of information

• "If we don't get this release done on time, there won't be a next release"

• "We don't have time to implement this the right way; just hack it in and we'll fix it after we ship."

• Expectation of increasing velocity.

• Defining concrete goals.

• Creating Clean Code.

• Unclear definition of done.

• Insufficient business knowledge.

What is caring?

Constantly monitoring metrics that indicate the health of the code base and responding to the changes in the trends.

What do you get in return?

As a developer As a business owner As a customer

• Fearless code modification.• Fearless code commit.• Fearless release. • Won't need to apologize

when showing your code to others.

• Self-confidence.• Fast and constant feedback

about your work.

• Constant overview of the evolution of your product.

• Ability to know the current state of development without any human interactions.

• Confidence in your product.• Trust in your team.

• Working software.• Significantly less bugs.

Metrics regarding code health

1. Number of coding standard violations.2. Number of duplicated code.3. Amount of dead code. 4. Amount of code covered by (automated) tests.

1. Number of open tasks. (todo, etc. in code) 2. Amount of overly complicated expressions. 3. Relationship between packages and objects

(modularity).

Exact measurements, straight-forward meanings:

Complex measurements and meanings:

What do these trends generally indicate*?

Constant low (~0) Constant high Lowering Growing

• Change is welcomed.• The code is stable.• Fixing bugs is fast and

cheap.

• Lack of morale or discipline.

• A fix of a bug usually is hard and expensive.

• High probability of introducing one or more defects while fixing one.

• Change is hard and expensive.

• The development team wants to take control over the code.

• Change will be cheaper and less time-consuming.

• Transition to a higher level of software development and demanding.

• Change in circumstances that caused low morale or discipline.

• Too much pressure on the programmers.

• Growing technical debt.

• Software becoming unstable.

* assuming the engineers have the knowledge to realize the problems.

Measuring coding standard violations

Normally every coding society has a standard that they try to stick to. It usually helps co-workers in understanding each-other's code and preventing bugs.

Measuring coding standard violationsWhat does the trend mean?

Constant low (~0) Growing• Internal API-s are well documented,

reusability is easy.• Programmers do a good job keeping

their artifact clean.• Code is anytime easily readable and

presentable to anyone.

• Insane standard requirements.

Measuring coding standard violations

What does it take to utilize the metric?

• A company-wide standard that all members know about. (Requires constant training)

• The standard written in the form that an automated tool can understand.

• An automated tool that can evaluate the code-base and report violations.

• Continuous maintenance of the standard and the tool.

• People caring about the trend!

Measuring duplicated codeWhat impact does duplicated code have?

"Code duplication harms the uniqueness of entities within a system.For example, a class that offers a certain functionality should besolely responsible for that functionality. If duplication appears, it becomes much harder to locate errors because the assumption “only class X implements this, therefore the error can be found there” does not hold anymore. Thus, the presence of code duplication has (at least) a double negative impact on the quality of a system: (1) the bloating of the system and (2) the co-evolution of clones (the clones do not all evolve the same way) which also implies the cloning of errors."

Michele Lanza, Radu Marinescu, Stéphane Ducasse - Object-oriented metrics in practice.

Measuring duplicated code

What does the trend mean?

Constant low (~0) Growing Constant high

• Optimal, clean code.• Bug fixes are cheap and

fast.

• Fear of code modification.

• Bug fixes are expensive, time-consuming and error prone.

Measuring duplicated code


• A company-wide policy about the maximum (lines/tokens) tolerated to be identical.

• Developer skill to avoid duplication.• An automated evaluation and reporting tool. • People caring about the trend!

Measuring dead codeWhat is dead code?

The dead code metrics measure the amount of dead or inoperative code in the source. Dead code means unnecessary, inoperative code that can be removed. Being dead means that the element is not used and you can remove it without affecting the functionality of the program.

Measuring dead code



• The code is commonly understood and the responsibilities of objects is clear to everyone.

• There's no trigger for at least one feature.

• Too complex code base.

Measuring dead code


• Full end-to-end tests with code-coverage logs.• Regression tests to verify code removal has not broken

functionality.• Developer confidence in removing code.• People caring about the trend!

Measuring code covered by (automated) tests.What is code coverage?

An analysis method that determines which parts of the software have been executed (covered) by the test case suite and which parts have not been executed and therefore may require additional attention.

Measuring code covered by (automated) tests. What does the trend mean?

Constant low (~0) Constant highGrowing

• Modification of the code is expensive, time-consuming and error-prone.

• Fearless code commit. •

There's no trigger for at least one feature.

Code-coverage has the only trend where the higher is better.

Although 100% code coverage may appear like a best possible effort, even 100% code coverage is estimated to only expose about half the faults in a system. Low code coverage indicates inadequate testing, but high code coverage guarantees nothing.

When you focus more and more on making the coverage numbers better, your motivation shifts away from finding bugs.

Measuring code covered by(automated) tests.


• A testing environment identical to the production environment, but decoupled from it.

• Automated end-to-end, integration and unit tests with code-coverage logs.

• Developer skill: creating all kinds of automated tests.• Product skill: writing acceptance criteria for stories.• QA skill: helping Product and Developer with efficient testing.• Visualization of the log. • People caring about the trend!

Number of open tasks

What is it? Occurrence of comments or annotations in the source code that indicate an unfinished engineering task, suboptimal or hard-to-read code, or other kinds of technical debt.

• todo• fixme• xxx• hack

Can occur in comment blocks, having @ //, etc. prefixes.

• review• refactor• wtf• omg

Marked tasks are identified as possible sources of technical debt.



Constant low (~0) Lowering

• Programmers have the opportunity to always do their best.

• No identified source of technical debt.

• Well maintained code.

• The development team is paying back technical debt.

Annotations can be grouped by importance. Critical, normal and low priority can be distinguished. If such categories exist, a more precise trend can be drawn.


• Automated task scanner and reporting tool.• Company-wide policy for task annotations and their

categories.• Developer confidence in completing these tasks.• People caring about the trend!


Amount of overly complicated expressions.

Code complexity can be defined as a metric which is directly proportional to the amount of effort required to understand the code and modify it correctly. Code complexity metrics are directly related to the maintainability and testability of the code. The more complex a code is, the less maintainable and testable it is. If the code is object oriented, the complexity metrics also have a direct bearing on the extensibility and modularity of the code.




• Optimal, well structured code.

• Unclear business logic.

• Lack of refactoring skills.

• Untestable, unreadable, hard to maintain code base.

• Generates fear of change.

• Not optimal code.


• Automated measurement and reporting tool.• Company-wide policy for value limits.• Developer skill to eliminate valuations.• People caring about the trend!


Measuring modularity

"Modularity is a general systems concept, typically defined as a continuum describing the degree to which a system’s components may be separated and recombined. It refers to both the tightness of coupling between components, and the degree to which the “rules” of the system architecture enable (or prohibit) the mixing and matching of components."

Wikipedia


A tightly coupled application operates with concrete implementations where the slightest modification to one of the collaborators can cause big impacts to the others.


A loosely coupled architecture relies on interfaces.(Output, Database, NoSql)

Swapping one implementation to another causes no impact on any other collaborator!


Designs are more extensible when they are independent of implementation details, allowing them to adapt to new implementations without internal modification or breaking their existing contracts.

The maintainability of a design is improved when changes can easily be made without propagating to other parts of the system.


What does it take to utilize the measurements?

• Packages.• Automated measurement and reporting tool.• Developer skill to introduce abstraction.• People caring about the trend!

If a window in a building is broken and left unrepaired all the rest of the windows

will soon be broken. . .

Broken Window Syndrome

One unrepaired window is a signal that no one cares, so breaking more

windows costs nothing. . . .

If disorder goes unchecked, a vicious cycle begins. First, it kindles a fear of crime among residents, who respond by staying behind locked doors. Their involvement in the neighborhood declines…they cease to exercise social regulation over little things like litter on the street, loitering strangers, or truant schoolchildren. When law-abiding eyes stop watching the streets, the social order breaks down and criminals move in.



Understanding that such a vicious cycle exists is important in creating a higher level of discipline and ownership in your current projects. Teams who are not vigilant about immediately fixing broken unit tests or builds, are in a sense, creating a downward spiral within the project. Team members who witness a single blatant act of project vandalism will undoubtedly give into the lazy human nature and retaliate with the common quote, “Well if he isn’t going to do that, than neither am I…”. The spiral begins…

http://www.codesqueeze.com/

"You can't improve what you don't measure."

When do you start improving?

Transitioning to quality software

Technology

Transcript of Transitioning to quality software