SlideShare a Scribd company logo

Caring about Code Quality

•
Saltmarch Media, profile picture
Saltmarch Media

The presentation by Venkat Subramaniam emphasizes the importance of code quality in achieving agility and success in software development. It discusses characteristics of good code, the costs associated with defects, and ways to promote high-quality coding practices through individual and team efforts. Strategies include peer reviews, maintaining simplicity, addressing technical debt, and fostering a culture of continuous improvement to enhance software reliability and maintainability.

Technology
1 of 65
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
CARING ABOUT CODE QUALITY speaker.identity { name 'Venkat Subramaniam' company 'Agile Developer, Inc.' credentials 'Programmer', 'Author', 'Trainer' blog 'http://agiledeveloper.com/blog' email 'venkats@agiledeveloper.com' }
Abstract We all have seen our share of bad code. We certainly have come across some good code as well. What are the characteristics of good code? How can we identify those? What practices can promote us to write and maintain more of those good quality code. This presentation will focus on this topic that has a major impact on our ability to be agile and succeed. Characteristics of quality code Metrics to measure quality Ways to identify and build quality 2
Why care about Code Quality? You can’t be Agile if your Code sucks 3
Code Quality 4
Change in Requirements [LARM03] 5
Cost of Defect 100 Cost 80 to correct a 60 defect 40 20 0 Requirements Design Code Test Operation [BOEH01] 6
Magnitude of Computational Problem European Space Agency took 10 years and $8 billion dollars to develop Ariane 5 On June 4, 1996, it took its first voyage with $500 million cargo In 40 seconds its inertial reference system failed 64-bit floating point number representing the horizontal velocity of the rocket was converted into 16-bit signed integer—conversion failed because of overflow Vehicle was deliberately destroyed for safety http://www.cnn.com/WORLD/9606/04/rocket.explode/ 7
Major Misfires September 1999: Metric mishap causes loss of NASA orbiter [CNN99] March 2001: Nike i2 Forecast System found to be inaccurate–Nike takes inventory write-off [CIO03] August 2004: NASA: DOS Glitch Nearly Killed Mars Rover–Story on Spirit: “...The flaw, since fixed, was only discovered after days of agonizingly slow tests...“ [EXTR04] June 2007: United flights grounded by computer glitch [COMP07] ... 8
Software Defect Reduction Top 10 List Finding, fixing problem in production is 100 times more expensive than during requirements/design phase. 40-50% of effort on projects is on avoidable rework. ~80% of avoidable rework comes from 20% of defects. ~80% of defects come from 20% of modules; about half the modules are defect free. ~90% of downtime comes from at most 10% of defects. [BOEH01] 9
Software Defect Reduction Top 10 List Peer reviews catch 60% of defects. Perspective-based reviews catch 35% more defects than nondirected reviews. Disciplined personal practices can reduce defect introduction rates by up to 75%. ...it costs 50% more per source instruction to develop high-dependability software product... ~40-50% of user programs have nontrivial defects. [BOEH01] 10
But, Still... The evidence is overwhelming, but still... We never seem to have time to do it, but always seem find time to redo it?! 11
What’s Quality? Measure of how well the software is designed and implemented Quality is subjective 12
Why care, there’s QA?! Can’t QA take care of quality, why should developers care? QA shouldn’t care about quality of design and implementation They should care about acceptance, performance, usage, and relevance of the application Give them a better quality software so they can really focus on that “Lowering Quality Lengthens Development Time” —First Law of Programming http://c2.com/cgi/wiki?FirstLawOfProgramming 13
More Maintenance... You’ll do more maintenance if quality is better Why? It’s easier to accommodate change, so you can be flexible and relevant “Maintenance is a solution, not a problem” “Better methods lead to more maintenance, not less” [GLAS03] 14
Pay your Technical Debt Technical debt are activities (like refactoring, upgrading a library, conforming to some UI or coding standard, ...) that you’ve left undone These will hamper your progress if left undone for a longer time 15
Measuring Quality Hard to measure Need to find useful metrics Example of wrong metric: Lines-Of-Code (LOC) Is more code better or worse? You can produce more code? You needed that much code for that? 16
Measuring Quality... Highly subjective Highly qualitative Is the code readable, understandable? Is the code verbose? Variable/method names that are meaningful Simple code that works Does it have tests? What’s the coverage? 17
Ways to Improve Quality Start early Don’t Compromise Schedule time to lower your technical debt Make it work; make it right (right away) Requires monitoring and changing behavior Be willing to help and be helped Devise lightweight non-bureaucratic measures 18
Individual Efforts What can you do? Care about design of your code Good names for variables, methods, ... Short methods, smaller classes, ... Learn by reading good code Keep it Simple Write tests with high coverage Run all your tests before checkin Checkin Frequently 19
Individual Efforts Learn your language If you’re switching languages or using multiple languages, know the differences Avoid Cargo cult programming–following rituals, styles, principles, or structure that serves no real purpose Court feedback and criticism 20
Keep It Simple! Don’t build Rube Goldberg Machines–something complex to do simple things 21
Keep It Simple! “There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies,”–C.A.R. Hoare. 22
Team Efforts Avoid shortcuts Take collective ownership–Team should own the code Promote positive interaction Provide constructive feedback Constant code review 23
You said Code Review? Code review is by far the proven way to reduce code defects and improve code quality But, code review does not work? It depends on how it’s done 24
If code review is... Do you get together as a team, project code, and review? At least three problems? You hate being critiqued that way You’d much rather write more code in that time Project manager says “last time you guys got together for review, fight ensued and one guy quit, no more code reviews for you...” Don’t make it an emotionally draining 25
Seeking and Receiving Feedback We’ve used code review very effectively Code reviewed by one developer right after task is complete (or anytime before) Rotate reviewer for each review Say positive things, what you really like Constructively propose changes Instead of “that’s lousy long method” say, “why don’t you split that method...” 26
Tactical Continuous Review Review not only code, but also tests Do not get picky on style, instead focus on correctness, readability, design, ... “Code Review makes me a Hero or makes me Smarter,”– Brian C. 27
Value of Review “Rigorous inspection can remove up to 90 percent of errors before the first test case is run.” “Reviews are both technical and sociological, and both factors must be accommodated.” [GLAS03] 28
Broken Window Problem Study shows broken windows lead to vandalism Code that no one cares for deteriorates quickly Do not tolerate your code being trashed Fix code that’s not elegant or looks broken Keep your code always releasable [SUBR06] [FIBW, THOM99] 29
Treat Warning as Errors Don’t say “that’s only a warning” Warnings may have hidden problems They’re annoying and distracting Use compiler options to treat warnings as errors If unavoidable, suppress (selectively) 30
Cohesion The code is focused, narrow, small It does one thing and one thing well Single Responsibility Principle Higher cohesion -> Lower Cyclomatic Complexity (see later) Strive for higher cohesion At method, class, component, subsystem level 31
Extensibility and Flexibility You build abstraction, hierarchy, ... to make your code extensible Extensibility is an anticipation What if the requirement does not meet what you anticipated? You have more code to work with and it is hard to extend in the new direction because of that Predicting is hard 32
Triangulation Postpone generalization Wait for code to evolve a bit You see evidence of what’s needed and generalize based on real use But, won’t that be expensive? Changes will require less work since you have lesser code to deal with [Beck02] 33
Cohesion and Cost of Change Code that’s doing too many things is hard to maintain Developer who must make change has to understand lots of things Code is complex, has higher cyclomatic complexity Your change likely will break something else Smaller, cohesive code is less expensive to maintain 34
Code Coverage How much (%) of your code is covered by test? How about paths through your code Is there code that deserve not to be tested? Instrumentation tools can tell you which and how much code is covered Tools: [Java] JCover, Cobertura, ... [.NET] NCover,... [C ++] C++ Test Coverage Tool, Bullseye Coverage, CTC++, Visual Studio, ... Tools like Guantanamo and Ashcroft delete code that have no test! 35
Code Coverage Code Test Coverage Tells you how much of your code’s exercised Does not tell you about test quality, however 36
Complexity Long methods cause pain Paths in code Unnecessary and stale comments cause confusion Large classes are hard to maintain ... 37
Cyclomatic Complexity Thomas McCabe’s Counts distinct paths through code Number of decision points + 1 # of edges - # of nodes + 2 Cyclomatic Complexity Number (CCN) > 10 is risky Strive for lower count Consider refactoring and fortify your tests Tools: [Java] JavaNCSS, PMD, CheckStyle, ... [.NET] FxCop, Visual Studio Code Analyzer, Resharper, NDepend, ... [C++] Code Counter, CMT++, Cyclo, ... 38
Cyclomatic Complexity For your tests to have reasonable code coverage: # of tests > CCN 39
Cyclomatic Complexity Cyclomatic Complexity Number Gives an indication of degree of hardness Does not indicate degree of defect 40
Code Size Addresses problems arising from large, low cohesive code Code Size Rules check for the size of code and flags if it exceeds How small is small Code must fit into a screen (without lowering font size) [about 15 to 20 statements per method] 41
Code Duplication Duplicated code is expensive to maintain Hard to fix bugs, hard to make enhancements Why do we duplication code then? Path of least resistance–you’re not breaking existing code, right? What to do? Identify and extract methods Tools: [Java] PMD, ... [.NET] Simian, ... [C++] ... Tools: Simian, StrictDuplicateCode, ... 42
Assessing Risk Complexity Automated Tests Risk Low Low High Low High Low High Low HIGH High High Medium 43
C.R.A.P Metric Change Risk Analysis and Prediction (CRAP) Experimental metrics and tool Measures effort and risk to maintain legacy code Uses Cyclomatic Complexity (comp) and code coverage (cov) Created by Bob Evans and Alberto Savoia of Agitar [SAVO07] For a method m, Version 0.1 of the formula is CRAP(m) = comp(m)^2 * (1-cov(m)/100)^3 + comp(m) Lower value => low change and maintenance risk Lowest value 1. With no tests, risk increases as square of complexity 44
C.R.A.P Metric 45
C.R.A.P Metric 30 = threshold for crappiness A complex method (within 30 CCN) can stay below the threshold with adequate tests CRAP Load: work estimate to address crappiness CRAP Load N means indicates the number of tests you need to write to bring your project below the threshold crap4J is an experimentation tool to measure this metric 46
Test Quality Low coverage indicates inadequate test Higher coverage does not mean adequate test, however How good is the quality of test? Did you cover different conditions, boundaries, ... Mutating testers can help determine that [Java] Jester [.NET] Nester [C++] ? 47
Code Duplication Code duplication is common Increases maintenance cost Makes it hard to fix bugs and make enhancements [Java] Simian, PMD (Copy Paste Detector), ... [.NET] Simian, ... [C++] Simian, ... 48
Code Analysis Analyzing code to find bugs Look for logic errors, coding guidelines violations, synchronization problems, data flow analysis, ... [Java] PMD, FindBugs, JLint, ... [.NET] VS, FxCop, ... [C++] VS, Lint, ... 49
Identifying Problem "It was on one of my journeys between the EDSAC room and the punching equipment that…the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs,"—Maurice V. Wilkes, pioneer in early machine design and microprogramming. 50
What is Code Smell? It’s a feeling or sense that something is not right in the code You can’t understand it Hard to explain Does some magic 51
Code Smells Improper use of inheritance Duplication Unnecessary complexity Convoluted code Useless/misleading comments Tight coupling Long classes Over abstraction Long methods Design Pattern overuse Poor naming Trying to be clever Code that’s not used ... 52
What? 53
Dealing with Code Smell Keep an eye on it Indicates code that needs either refactoring or some serious redesign Technical Debt Take effort to clear the air–frequently 54
From Writing to Coding… William Zinsser Wrote “On Writing Well” 25 years ago! He gives good principles for writing well These principles apply to programming as much as writing non-fiction Simplicity Clarity Brevity Humanity 55
Clear, not Clever Don’t be clever, instead be clear “I never make stupid mistakes. Only very, very clever ones,”—Dr Who 56
No Rush Don’t code in a Hurry—”Haste is Waste” Take time to read the code and see if is what you meant Take the time to write tests—make sure the code does what you meant, not what you typed Code defensively “Act in haste and repent at leisure: Code too soon and debug forever,”—Raymond Kennington. 57
Commenting and Self-Documenting Code Lots of comments are written to coverup bad code Comments should say Why or purpose, not how Don’t comment what a code does—I can read the code for that—keep it DRY Don’t keep documentation separate from code Use javadoc (Java), doxygen (C++), NDoc (C#),... At least provide a pointer to where it is If you copy and paste, check if comments are still relevant 58
Commenting and Self-Documenting Code Don’t use variable names that are cryptic or too brief Keep code simple Keep code small Keep comments minimum and meaningful Give names for constants order(CoffeeSize.LARGE) instead of order(3) // large 59
Commenting and Self-Documenting Code Use Assertions to document assumptions Document unique, special, or unexpected conditions Keep them short and clear, however Don’t pour emotions and arguments Keep an eye for stale comments 60
Code for Clarity—self-documenting... Can someone who does not know English still understand your code? Can someone who does not speak your language still understand your code? Some languages and frameworks are being created by experts who don’t speak English as their first language Ruby - Japan Groovy - European and US collaborators 61
Comments on Commenting Justify violation of good programming practices or styles If you’ve to use some convoluted logic, unroll a loop, ... drop a comments to say why Will avoid unnecessary refactoring attempt only to discover that it has to stay that way Will help check if the assumptions stated are still valid Don’t comment clever code, rewrite it If everyone stumbles on a particular problem, don’t comment to caution, instead fix it 62
Error In Your Face Raise exceptions so they’re in your face Don’t let problems slip by Also, if it is hard to locate problems during development, it will only get worse for your support Find easy ways to identify what’s wrong Log is good, but provide a code to easily located the relevant message in it 63
Summary Practice tactical peer code review Consider untested code is unfinished code Make your code coverage and metrics visible Don’t tolerate anyone trashing your code Write self documenting code and comment whys Use tools to check code quality Use tools continuously—that is automated Treat warnings as errors Keep it small Keep it simple 64
References [Beck02] "Test Driven Development: By Example," by Kent Beck, Addison Wesley, 2002. [BLOC05] "Java Puzzlers: Traps, Pitfalls, and Corner Cases," by Joshua Bloch, Neal Gafter, Addison Wesley, 2005. [BOEH01] "Software Defect Reduction Top 10 List," by Barry Boehm and Victor R. Basili, IEEE Computer, January 2001. (http://www.cebase.org/www/resources/reports/usc/ usccse2001-515.pdf). [GLAS03] "Facts and Fallacies of Software Engineering," by Robert L. Glass, Addison- Wesley, 2003. [FIBW] "Fixing Broken Windows," on Wikipedia (http://en.wikipedia.org/wiki/ Fixing_Broken_Windows). [THOM99] "The Pragmatic Programmer: From Journeyman to Master," by Andy Hunt and Dave Thomas, Addison-Wesley, 2000 (Excerpt on Software Entropy and Broken Window Problem can be found at http://www.pragprog.com/the-pragmatic-programmer/ extracts/software-entropy). You can download examples and slides from http://www.agiledeveloper.com - download 65

More Related Content

What's hot (20)

PPTX
Refactoring legacy code driven by tests - ITA
Luca Minudel
 
PPTX
Agile Testing by Example
Mikalai Alimenkou
 
PPTX
agile vs. traditional methodologies
SWE department, Bogazici university
 
PDF
Product QA - A test engineering perspective
Imaginea
 
PPTX
Agile Testing - presentation for Agile User Group
suwalki24.pl
 
PPTX
QA/Test Engineering Perspectives
Roopesh Kohad
 
PPTX
Acceptance Test Driven Development
Mike Douglas
 
PPT
Trends in Agile Testing by Lisa Crispin
Directi Group
 
PDF
Agile engineering practices – a short overview
Serhiy Yevtushenko
 
PPTX
Teaching Kids Programming
Lynn Langit
 
PDF
What is Agile Testing?
vodQA
 
PPTX
BDD presentation
temebele
 
PDF
DevTestOps
Paul Mateos
 
PPTX
Agile tour ncr test360_degree - agile testing on steroids
Vipul Gupta
 
PPTX
Agile testing presentation
Komal Garg
 
POT
Quality metrics and angular js applications
nadeembtech
 
ODP
Extreme Programming
Knoldus Inc.
 
PDF
John Fodeh Adventures in Test Automation - EuroSTAR 2013
TEST Huddle
 
PDF
What is Agile Testing?
Dr. Alexander Schwartz
 
PDF
Agile Testing
Intelliware Development Inc.
 
Refactoring legacy code driven by tests - ITA
Luca Minudel
 
Agile Testing by Example
Mikalai Alimenkou
 
agile vs. traditional methodologies
SWE department, Bogazici university
 
Product QA - A test engineering perspective
Imaginea
 
Agile Testing - presentation for Agile User Group
suwalki24.pl
 
QA/Test Engineering Perspectives
Roopesh Kohad
 
Acceptance Test Driven Development
Mike Douglas
 
Trends in Agile Testing by Lisa Crispin
Directi Group
 
Agile engineering practices – a short overview
Serhiy Yevtushenko
 
Teaching Kids Programming
Lynn Langit
 
What is Agile Testing?
vodQA
 
BDD presentation
temebele
 
DevTestOps
Paul Mateos
 
Agile tour ncr test360_degree - agile testing on steroids
Vipul Gupta
 
Agile testing presentation
Komal Garg
 
Quality metrics and angular js applications
nadeembtech
 
Extreme Programming
Knoldus Inc.
 
John Fodeh Adventures in Test Automation - EuroSTAR 2013
TEST Huddle
 
What is Agile Testing?
Dr. Alexander Schwartz
 
Agile Testing
Intelliware Development Inc.
 

Viewers also liked (7)

PDF
Increasing code quality with code reviews (poetry version)
David Stockton
 
PDF
Surviving Code Reviews
Codemotion
 
PPTX
Tailor-Made Tax Practice Quality Controls presented at the West Michigan Tax ...
Jina Etiennne
 
PPTX
Code Review
Mikalai Alimenkou
 
PDF
Effektive Code Reviews Solutions
Frank Sons
 
PDF
Effective Code Reviews
Frank Sons
 
PPT
Code Quality Practice and Tools
Bob Paulin
 
Increasing code quality with code reviews (poetry version)
David Stockton
 
Surviving Code Reviews
Codemotion
 
Tailor-Made Tax Practice Quality Controls presented at the West Michigan Tax ...
Jina Etiennne
 
Code Review
Mikalai Alimenkou
 
Effektive Code Reviews Solutions
Frank Sons
 
Effective Code Reviews
Frank Sons
 
Code Quality Practice and Tools
Bob Paulin
 
Ad

Similar to Caring about Code Quality (20)

PDF
caring_about_code_quality
Ketan Patel
 
PPTX
Software Quality via Unit Testing
Shaun Abram
 
PPTX
Defect free development - QS Tag2019
Arnon Axelrod
 
PPTX
Test driven development
Sunil Prasad
 
PDF
Technical debt management strategies
Raquel Pau
 
PPTX
Slides for Houston iPhone Developers' Meetup (April 2012)
lqi
 
PDF
Effective Testing Practices in an Agile Environment
Raj Indugula
 
PPTX
Modern software architect post the agile wave
Niels Bech Nielsen
 
PDF
Taming Big Balls of Mud with Diligence, Agile Practices, and Hard Work
Joseph Yoder
 
PDF
Software Defect Prevention via Continuous Inspection
Josh Gough
 
PPTX
Lect3 conventional vs modern spm
meena466141
 
PPTX
Automation and Technical Debt
IBM UrbanCode Products
 
PPTX
code_review_checklist_6_actions_to_improve_the_quality_of_your_reviews.pptx
sarah david
 
PDF
Are You a SOLID Coder?
Steve Green
 
PPT
1.Basic Introduction (1).ppt
AshutoshPandey389106
 
PDF
Leveraging AI and ML in Test Management Systems - DevOps Next
Perfecto by Perforce
 
PDF
code_review_checklist_6_actions_to_improve_the_quality_of_your_reviews.pdf
sarah david
 
PDF
01 the value of quality
Clemens Reijnen
 
PDF
Top 10 clean code practices to reduce technical debt
Sparity1
 
PPTX
SCA in an Agile World | June 2010
Klocwork
 
caring_about_code_quality
Ketan Patel
 
Software Quality via Unit Testing
Shaun Abram
 
Defect free development - QS Tag2019
Arnon Axelrod
 
Test driven development
Sunil Prasad
 
Technical debt management strategies
Raquel Pau
 
Slides for Houston iPhone Developers' Meetup (April 2012)
lqi
 
Effective Testing Practices in an Agile Environment
Raj Indugula
 
Modern software architect post the agile wave
Niels Bech Nielsen
 
Taming Big Balls of Mud with Diligence, Agile Practices, and Hard Work
Joseph Yoder
 
Software Defect Prevention via Continuous Inspection
Josh Gough
 
Lect3 conventional vs modern spm
meena466141
 
Automation and Technical Debt
IBM UrbanCode Products
 
code_review_checklist_6_actions_to_improve_the_quality_of_your_reviews.pptx
sarah david
 
Are You a SOLID Coder?
Steve Green
 
1.Basic Introduction (1).ppt
AshutoshPandey389106
 
Leveraging AI and ML in Test Management Systems - DevOps Next
Perfecto by Perforce
 
code_review_checklist_6_actions_to_improve_the_quality_of_your_reviews.pdf
sarah david
 
01 the value of quality
Clemens Reijnen
 
Top 10 clean code practices to reduce technical debt
Sparity1
 
SCA in an Agile World | June 2010
Klocwork
 
Ad

More from Saltmarch Media (18)

PDF
Concocting an MVC, Data Services and Entity Framework solution for Azure
Saltmarch Media
 
PDF
Learning Open Source Business Intelligence
Saltmarch Media
 
PDF
Java EE 7: the Voyage of the Cloud Treader
Saltmarch Media
 
PDF
Is NoSQL The Future of Data Storage?
Saltmarch Media
 
PDF
Introduction to WCF RIA Services for Silverlight 4 Developers
Saltmarch Media
 
PDF
Integrated Services for Web Applications
Saltmarch Media
 
PDF
Gaelyk - Web Apps In Practically No Time
Saltmarch Media
 
PDF
CDI and Seam 3: an Exciting New Landscape for Java EE Development
Saltmarch Media
 
PDF
JBoss at Work: Using JBoss AS 6
Saltmarch Media
 
PDF
WF and WCF with AppFabric – Application Infrastructure for OnPremise Services
Saltmarch Media
 
PDF
“What did I do?” - T-SQL Worst Practices
Saltmarch Media
 
PDF
Building RESTful Services with WCF 4.0
Saltmarch Media
 
PDF
Building Facebook Applications on Windows Azure
Saltmarch Media
 
PDF
Architecting Smarter Apps with Entity Framework
Saltmarch Media
 
PDF
Agile Estimation
Saltmarch Media
 
PDF
Alternate JVM Languages
Saltmarch Media
 
PDF
A Cocktail of Guice and Seam, the missing ingredients for Java EE 6
Saltmarch Media
 
PDF
A Bit of Design Thinking for Developers
Saltmarch Media
 
Concocting an MVC, Data Services and Entity Framework solution for Azure
Saltmarch Media
 
Learning Open Source Business Intelligence
Saltmarch Media
 
Java EE 7: the Voyage of the Cloud Treader
Saltmarch Media
 
Is NoSQL The Future of Data Storage?
Saltmarch Media
 
Introduction to WCF RIA Services for Silverlight 4 Developers
Saltmarch Media
 
Integrated Services for Web Applications
Saltmarch Media
 
Gaelyk - Web Apps In Practically No Time
Saltmarch Media
 
CDI and Seam 3: an Exciting New Landscape for Java EE Development
Saltmarch Media
 
JBoss at Work: Using JBoss AS 6
Saltmarch Media
 
WF and WCF with AppFabric – Application Infrastructure for OnPremise Services
Saltmarch Media
 
“What did I do?” - T-SQL Worst Practices
Saltmarch Media
 
Building RESTful Services with WCF 4.0
Saltmarch Media
 
Building Facebook Applications on Windows Azure
Saltmarch Media
 
Architecting Smarter Apps with Entity Framework
Saltmarch Media
 
Agile Estimation
Saltmarch Media
 
Alternate JVM Languages
Saltmarch Media
 
A Cocktail of Guice and Seam, the missing ingredients for Java EE 6
Saltmarch Media
 
A Bit of Design Thinking for Developers
Saltmarch Media
 

Recently uploaded (20)

PPTX
IT Runs Better with ThousandEyes AI-driven Assurance
ThousandEyes
 
PDF
Per Axbom: The spectacular lies of maps
Nexer Digital
 
PPTX
AI and Robotics for Human Well-being.pptx
JAYMIN SUTHAR
 
PDF
Economic Impact of Data Centres to the Malaysian Economy
flintglobalapac
 
PDF
How Open Source Changed My Career by abdelrahman ismail
a0m0rajab1
 
PPTX
Dev Dives: Automate, test, and deploy in one place—with Unified Developer Exp...
AndreeaTom
 
PDF
A Strategic Analysis of the MVNO Wave in Emerging Markets.pdf
IPLOOK Networks
 
PDF
MASTERDECK GRAPHSUMMIT SYDNEY (Public).pdf
Neo4j
 
PDF
How ETL Control Logic Keeps Your Pipelines Safe and Reliable.pdf
Stryv Solutions Pvt. Ltd.
 
PPTX
What-is-the-World-Wide-Web -- Introduction
tonifi9488
 
PPTX
Agile Chennai 18-19 July 2025 Ideathon | AI Powered Microfinance Literacy Gui...
AgileNetwork
 
PDF
Trying to figure out MCP by actually building an app from scratch with open s...
Julien SIMON
 
PDF
The Future of Mobile Is Context-Aware—Are You Ready?
iProgrammer Solutions Private Limited
 
PPTX
AI in Daily Life: How Artificial Intelligence Helps Us Every Day
vanshrpatil7
 
PDF
Data_Analytics_vs_Data_Science_vs_BI_by_CA_Suvidha_Chaplot.pdf
CA Suvidha Chaplot
 
PDF
Brief History of Internet - Early Days of Internet
sutharharshit158
 
PDF
Responsible AI and AI Ethics - By Sylvester Ebhonu
Sylvester Ebhonu
 
PDF
Presentation about Hardware and Software in Computer
snehamodhawadiya
 
PPTX
AVL ( audio, visuals or led ), technology.
Rajeshwri Panchal
 
PPTX
The Future of AI & Machine Learning.pptx
pritsen4700
 
IT Runs Better with ThousandEyes AI-driven Assurance
ThousandEyes
 
Per Axbom: The spectacular lies of maps
Nexer Digital
 
AI and Robotics for Human Well-being.pptx
JAYMIN SUTHAR
 
Economic Impact of Data Centres to the Malaysian Economy
flintglobalapac
 
How Open Source Changed My Career by abdelrahman ismail
a0m0rajab1
 
Dev Dives: Automate, test, and deploy in one place—with Unified Developer Exp...
AndreeaTom
 
A Strategic Analysis of the MVNO Wave in Emerging Markets.pdf
IPLOOK Networks
 
MASTERDECK GRAPHSUMMIT SYDNEY (Public).pdf
Neo4j
 
How ETL Control Logic Keeps Your Pipelines Safe and Reliable.pdf
Stryv Solutions Pvt. Ltd.
 
What-is-the-World-Wide-Web -- Introduction
tonifi9488
 
Agile Chennai 18-19 July 2025 Ideathon | AI Powered Microfinance Literacy Gui...
AgileNetwork
 
Trying to figure out MCP by actually building an app from scratch with open s...
Julien SIMON
 
The Future of Mobile Is Context-Aware—Are You Ready?
iProgrammer Solutions Private Limited
 
AI in Daily Life: How Artificial Intelligence Helps Us Every Day
vanshrpatil7
 
Data_Analytics_vs_Data_Science_vs_BI_by_CA_Suvidha_Chaplot.pdf
CA Suvidha Chaplot
 
Brief History of Internet - Early Days of Internet
sutharharshit158
 
Responsible AI and AI Ethics - By Sylvester Ebhonu
Sylvester Ebhonu
 
Presentation about Hardware and Software in Computer
snehamodhawadiya
 
AVL ( audio, visuals or led ), technology.
Rajeshwri Panchal
 
The Future of AI & Machine Learning.pptx
pritsen4700
 

Caring about Code Quality

  • 1. CARING ABOUT CODE QUALITY speaker.identity { name 'Venkat Subramaniam' company 'Agile Developer, Inc.' credentials 'Programmer', 'Author', 'Trainer' blog 'http://agiledeveloper.com/blog' email '[email protected]' }
  • 2. Abstract We all have seen our share of bad code. We certainly have come across some good code as well. What are the characteristics of good code? How can we identify those? What practices can promote us to write and maintain more of those good quality code. This presentation will focus on this topic that has a major impact on our ability to be agile and succeed. Characteristics of quality code Metrics to measure quality Ways to identify and build quality 2
  • 3. Why care about Code Quality? You can’t be Agile if your Code sucks 3
  • 6. Cost of Defect 100 Cost 80 to correct a 60 defect 40 20 0 Requirements Design Code Test Operation [BOEH01] 6
  • 7. Magnitude of Computational Problem European Space Agency took 10 years and $8 billion dollars to develop Ariane 5 On June 4, 1996, it took its first voyage with $500 million cargo In 40 seconds its inertial reference system failed 64-bit floating point number representing the horizontal velocity of the rocket was converted into 16-bit signed integer—conversion failed because of overflow Vehicle was deliberately destroyed for safety http://www.cnn.com/WORLD/9606/04/rocket.explode/ 7
  • 8. Major Misfires September 1999: Metric mishap causes loss of NASA orbiter [CNN99] March 2001: Nike i2 Forecast System found to be inaccurate–Nike takes inventory write-off [CIO03] August 2004: NASA: DOS Glitch Nearly Killed Mars Rover–Story on Spirit: “...The flaw, since fixed, was only discovered after days of agonizingly slow tests...“ [EXTR04] June 2007: United flights grounded by computer glitch [COMP07] ... 8
  • 9. Software Defect Reduction Top 10 List Finding, fixing problem in production is 100 times more expensive than during requirements/design phase. 40-50% of effort on projects is on avoidable rework. ~80% of avoidable rework comes from 20% of defects. ~80% of defects come from 20% of modules; about half the modules are defect free. ~90% of downtime comes from at most 10% of defects. [BOEH01] 9
  • 10. Software Defect Reduction Top 10 List Peer reviews catch 60% of defects. Perspective-based reviews catch 35% more defects than nondirected reviews. Disciplined personal practices can reduce defect introduction rates by up to 75%. ...it costs 50% more per source instruction to develop high-dependability software product... ~40-50% of user programs have nontrivial defects. [BOEH01] 10
  • 11. But, Still... The evidence is overwhelming, but still... We never seem to have time to do it, but always seem find time to redo it?! 11
  • 12. What’s Quality? Measure of how well the software is designed and implemented Quality is subjective 12
  • 13. Why care, there’s QA?! Can’t QA take care of quality, why should developers care? QA shouldn’t care about quality of design and implementation They should care about acceptance, performance, usage, and relevance of the application Give them a better quality software so they can really focus on that “Lowering Quality Lengthens Development Time” —First Law of Programming http://c2.com/cgi/wiki?FirstLawOfProgramming 13
  • 14. More Maintenance... You’ll do more maintenance if quality is better Why? It’s easier to accommodate change, so you can be flexible and relevant “Maintenance is a solution, not a problem” “Better methods lead to more maintenance, not less” [GLAS03] 14
  • 15. Pay your Technical Debt Technical debt are activities (like refactoring, upgrading a library, conforming to some UI or coding standard, ...) that you’ve left undone These will hamper your progress if left undone for a longer time 15
  • 16. Measuring Quality Hard to measure Need to find useful metrics Example of wrong metric: Lines-Of-Code (LOC) Is more code better or worse? You can produce more code? You needed that much code for that? 16
  • 17. Measuring Quality... Highly subjective Highly qualitative Is the code readable, understandable? Is the code verbose? Variable/method names that are meaningful Simple code that works Does it have tests? What’s the coverage? 17
  • 18. Ways to Improve Quality Start early Don’t Compromise Schedule time to lower your technical debt Make it work; make it right (right away) Requires monitoring and changing behavior Be willing to help and be helped Devise lightweight non-bureaucratic measures 18
  • 19. Individual Efforts What can you do? Care about design of your code Good names for variables, methods, ... Short methods, smaller classes, ... Learn by reading good code Keep it Simple Write tests with high coverage Run all your tests before checkin Checkin Frequently 19
  • 20. Individual Efforts Learn your language If you’re switching languages or using multiple languages, know the differences Avoid Cargo cult programming–following rituals, styles, principles, or structure that serves no real purpose Court feedback and criticism 20
  • 21. Keep It Simple! Don’t build Rube Goldberg Machines–something complex to do simple things 21
  • 22. Keep It Simple! “There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies,”–C.A.R. Hoare. 22
  • 23. Team Efforts Avoid shortcuts Take collective ownership–Team should own the code Promote positive interaction Provide constructive feedback Constant code review 23
  • 24. You said Code Review? Code review is by far the proven way to reduce code defects and improve code quality But, code review does not work? It depends on how it’s done 24
  • 25. If code review is... Do you get together as a team, project code, and review? At least three problems? You hate being critiqued that way You’d much rather write more code in that time Project manager says “last time you guys got together for review, fight ensued and one guy quit, no more code reviews for you...” Don’t make it an emotionally draining 25
  • 26. Seeking and Receiving Feedback We’ve used code review very effectively Code reviewed by one developer right after task is complete (or anytime before) Rotate reviewer for each review Say positive things, what you really like Constructively propose changes Instead of “that’s lousy long method” say, “why don’t you split that method...” 26
  • 27. Tactical Continuous Review Review not only code, but also tests Do not get picky on style, instead focus on correctness, readability, design, ... “Code Review makes me a Hero or makes me Smarter,”– Brian C. 27
  • 28. Value of Review “Rigorous inspection can remove up to 90 percent of errors before the first test case is run.” “Reviews are both technical and sociological, and both factors must be accommodated.” [GLAS03] 28
  • 29. Broken Window Problem Study shows broken windows lead to vandalism Code that no one cares for deteriorates quickly Do not tolerate your code being trashed Fix code that’s not elegant or looks broken Keep your code always releasable [SUBR06] [FIBW, THOM99] 29
  • 30. Treat Warning as Errors Don’t say “that’s only a warning” Warnings may have hidden problems They’re annoying and distracting Use compiler options to treat warnings as errors If unavoidable, suppress (selectively) 30
  • 31. Cohesion The code is focused, narrow, small It does one thing and one thing well Single Responsibility Principle Higher cohesion -> Lower Cyclomatic Complexity (see later) Strive for higher cohesion At method, class, component, subsystem level 31
  • 32. Extensibility and Flexibility You build abstraction, hierarchy, ... to make your code extensible Extensibility is an anticipation What if the requirement does not meet what you anticipated? You have more code to work with and it is hard to extend in the new direction because of that Predicting is hard 32
  • 33. Triangulation Postpone generalization Wait for code to evolve a bit You see evidence of what’s needed and generalize based on real use But, won’t that be expensive? Changes will require less work since you have lesser code to deal with [Beck02] 33
  • 34. Cohesion and Cost of Change Code that’s doing too many things is hard to maintain Developer who must make change has to understand lots of things Code is complex, has higher cyclomatic complexity Your change likely will break something else Smaller, cohesive code is less expensive to maintain 34
  • 35. Code Coverage How much (%) of your code is covered by test? How about paths through your code Is there code that deserve not to be tested? Instrumentation tools can tell you which and how much code is covered Tools: [Java] JCover, Cobertura, ... [.NET] NCover,... [C ++] C++ Test Coverage Tool, Bullseye Coverage, CTC++, Visual Studio, ... Tools like Guantanamo and Ashcroft delete code that have no test! 35
  • 36. Code Coverage Code Test Coverage Tells you how much of your code’s exercised Does not tell you about test quality, however 36
  • 37. Complexity Long methods cause pain Paths in code Unnecessary and stale comments cause confusion Large classes are hard to maintain ... 37
  • 38. Cyclomatic Complexity Thomas McCabe’s Counts distinct paths through code Number of decision points + 1 # of edges - # of nodes + 2 Cyclomatic Complexity Number (CCN) > 10 is risky Strive for lower count Consider refactoring and fortify your tests Tools: [Java] JavaNCSS, PMD, CheckStyle, ... [.NET] FxCop, Visual Studio Code Analyzer, Resharper, NDepend, ... [C++] Code Counter, CMT++, Cyclo, ... 38
  • 39. Cyclomatic Complexity For your tests to have reasonable code coverage: # of tests > CCN 39
  • 40. Cyclomatic Complexity Cyclomatic Complexity Number Gives an indication of degree of hardness Does not indicate degree of defect 40
  • 41. Code Size Addresses problems arising from large, low cohesive code Code Size Rules check for the size of code and flags if it exceeds How small is small Code must fit into a screen (without lowering font size) [about 15 to 20 statements per method] 41
  • 42. Code Duplication Duplicated code is expensive to maintain Hard to fix bugs, hard to make enhancements Why do we duplication code then? Path of least resistance–you’re not breaking existing code, right? What to do? Identify and extract methods Tools: [Java] PMD, ... [.NET] Simian, ... [C++] ... Tools: Simian, StrictDuplicateCode, ... 42
  • 43. Assessing Risk Complexity Automated Tests Risk Low Low High Low High Low High Low HIGH High High Medium 43
  • 44. C.R.A.P Metric Change Risk Analysis and Prediction (CRAP) Experimental metrics and tool Measures effort and risk to maintain legacy code Uses Cyclomatic Complexity (comp) and code coverage (cov) Created by Bob Evans and Alberto Savoia of Agitar [SAVO07] For a method m, Version 0.1 of the formula is CRAP(m) = comp(m)^2 * (1-cov(m)/100)^3 + comp(m) Lower value => low change and maintenance risk Lowest value 1. With no tests, risk increases as square of complexity 44
  • 46. C.R.A.P Metric 30 = threshold for crappiness A complex method (within 30 CCN) can stay below the threshold with adequate tests CRAP Load: work estimate to address crappiness CRAP Load N means indicates the number of tests you need to write to bring your project below the threshold crap4J is an experimentation tool to measure this metric 46
  • 47. Test Quality Low coverage indicates inadequate test Higher coverage does not mean adequate test, however How good is the quality of test? Did you cover different conditions, boundaries, ... Mutating testers can help determine that [Java] Jester [.NET] Nester [C++] ? 47
  • 48. Code Duplication Code duplication is common Increases maintenance cost Makes it hard to fix bugs and make enhancements [Java] Simian, PMD (Copy Paste Detector), ... [.NET] Simian, ... [C++] Simian, ... 48
  • 49. Code Analysis Analyzing code to find bugs Look for logic errors, coding guidelines violations, synchronization problems, data flow analysis, ... [Java] PMD, FindBugs, JLint, ... [.NET] VS, FxCop, ... [C++] VS, Lint, ... 49
  • 50. Identifying Problem "It was on one of my journeys between the EDSAC room and the punching equipment that…the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs,"—Maurice V. Wilkes, pioneer in early machine design and microprogramming. 50
  • 51. What is Code Smell? It’s a feeling or sense that something is not right in the code You can’t understand it Hard to explain Does some magic 51
  • 52. Code Smells Improper use of inheritance Duplication Unnecessary complexity Convoluted code Useless/misleading comments Tight coupling Long classes Over abstraction Long methods Design Pattern overuse Poor naming Trying to be clever Code that’s not used ... 52
  • 53. What? 53
  • 54. Dealing with Code Smell Keep an eye on it Indicates code that needs either refactoring or some serious redesign Technical Debt Take effort to clear the air–frequently 54
  • 55. From Writing to Coding… William Zinsser Wrote “On Writing Well” 25 years ago! He gives good principles for writing well These principles apply to programming as much as writing non-fiction Simplicity Clarity Brevity Humanity 55
  • 56. Clear, not Clever Don’t be clever, instead be clear “I never make stupid mistakes. Only very, very clever ones,”—Dr Who 56
  • 57. No Rush Don’t code in a Hurry—”Haste is Waste” Take time to read the code and see if is what you meant Take the time to write tests—make sure the code does what you meant, not what you typed Code defensively “Act in haste and repent at leisure: Code too soon and debug forever,”—Raymond Kennington. 57
  • 58. Commenting and Self-Documenting Code Lots of comments are written to coverup bad code Comments should say Why or purpose, not how Don’t comment what a code does—I can read the code for that—keep it DRY Don’t keep documentation separate from code Use javadoc (Java), doxygen (C++), NDoc (C#),... At least provide a pointer to where it is If you copy and paste, check if comments are still relevant 58
  • 59. Commenting and Self-Documenting Code Don’t use variable names that are cryptic or too brief Keep code simple Keep code small Keep comments minimum and meaningful Give names for constants order(CoffeeSize.LARGE) instead of order(3) // large 59
  • 60. Commenting and Self-Documenting Code Use Assertions to document assumptions Document unique, special, or unexpected conditions Keep them short and clear, however Don’t pour emotions and arguments Keep an eye for stale comments 60
  • 61. Code for Clarity—self-documenting... Can someone who does not know English still understand your code? Can someone who does not speak your language still understand your code? Some languages and frameworks are being created by experts who don’t speak English as their first language Ruby - Japan Groovy - European and US collaborators 61
  • 62. Comments on Commenting Justify violation of good programming practices or styles If you’ve to use some convoluted logic, unroll a loop, ... drop a comments to say why Will avoid unnecessary refactoring attempt only to discover that it has to stay that way Will help check if the assumptions stated are still valid Don’t comment clever code, rewrite it If everyone stumbles on a particular problem, don’t comment to caution, instead fix it 62
  • 63. Error In Your Face Raise exceptions so they’re in your face Don’t let problems slip by Also, if it is hard to locate problems during development, it will only get worse for your support Find easy ways to identify what’s wrong Log is good, but provide a code to easily located the relevant message in it 63
  • 64. Summary Practice tactical peer code review Consider untested code is unfinished code Make your code coverage and metrics visible Don’t tolerate anyone trashing your code Write self documenting code and comment whys Use tools to check code quality Use tools continuously—that is automated Treat warnings as errors Keep it small Keep it simple 64
  • 65. References [Beck02] "Test Driven Development: By Example," by Kent Beck, Addison Wesley, 2002. [BLOC05] "Java Puzzlers: Traps, Pitfalls, and Corner Cases," by Joshua Bloch, Neal Gafter, Addison Wesley, 2005. [BOEH01] "Software Defect Reduction Top 10 List," by Barry Boehm and Victor R. Basili, IEEE Computer, January 2001. (http://www.cebase.org/www/resources/reports/usc/ usccse2001-515.pdf). [GLAS03] "Facts and Fallacies of Software Engineering," by Robert L. Glass, Addison- Wesley, 2003. [FIBW] "Fixing Broken Windows," on Wikipedia (http://en.wikipedia.org/wiki/ Fixing_Broken_Windows). [THOM99] "The Pragmatic Programmer: From Journeyman to Master," by Andy Hunt and Dave Thomas, Addison-Wesley, 2000 (Excerpt on Software Entropy and Broken Window Problem can be found at http://www.pragprog.com/the-pragmatic-programmer/ extracts/software-entropy). You can download examples and slides from http://www.agiledeveloper.com - download 65