Transitioning to quality software
5 likes727 views
The document discusses the importance of measuring metrics related to code quality and health in order to transition from working software to high quality software. It provides examples of metrics that can be measured such as coding standard violations, duplicated code, dead code, code coverage by tests, number of open tasks, complexity of expressions, and modularity. It explains what different trends in these metrics may indicate and considerations for utilizing the metrics such as tools, policies, and developer skills. Regular measurement and response to trends helps avoid issues like increasing technical debt and the "Broken Window Syndrome."
Transitioning to quality software
- 1. Transitioning from working software to quality software a.k.a. caring instead of peonage
- 2. 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.
- 3. What is Technical Debt? 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.
- 4. What generates Technical Debt? Pressure Lack of skills Lack of information • "If we don't get this • Defining concrete • Unclear definition of release done on time, goals. done. • Creating Clean Code. • Insufficient business there won't be a next knowledge. 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.
- 5. 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. • Constant overview of the • Working software. • Fearless code commit. evolution of your product. • Significantly less bugs. • Fearless release. • Ability to know the current • Won't need to apologize state of development without when showing your code to any human interactions. others. • Confidence in your product. • Self-confidence. • Trust in your team. • Fast and constant feedback about your work.
- 6. Metrics regarding code health Exact measurements, straight-forward meanings: 1. Number of coding standard violations. 2. Number of duplicated code. 3. Amount of dead code. 4. Amount of code covered by (automated) tests. Complex measurements and meanings: 1. Number of open tasks. (todo, etc. in code) 2. Amount of overly complicated expressions. 3. Relationship between packages and objects (modularity).
- 7. What do these trends generally indicate*? Constant low (~0) Constant high Lowering Growing • Change is welcomed. • Lack of morale or • The development • Change in • The code is stable. discipline. team wants to take circumstances that • Fixing bugs is fast and • A fix of a bug control over the caused low morale cheap. usually is hard code. or discipline. and expensive. • Change will be • Too much pressure • High probability of cheaper and less on the introducing one or time-consuming. programmers. more defects • Transition to a • Growing technical while fixing one. higher level of debt. • Change is hard software • Software becoming and expensive. development and unstable. demanding. * assuming the engineers have the knowledge to realize the problems.
- 8. 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.
- 9. Measuring coding standard violations What does the trend mean? Constant low (~0) Growing • Internal API-s are well documented, • Insane standard requirements. reusability is easy. • Programmers do a good job keeping their artifact clean. • Code is anytime easily readable and presentable to anyone.
- 10. 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!
- 11. Measuring duplicated code What 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 be solely 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.
- 12. Measuring duplicated code What does the trend mean? Constant low (~0) Growing Constant high • Optimal, clean code. • Fear of code • Bug fixes are • Bug fixes are cheap and modification. expensive, time- fast. consuming and error prone.
- 13. Measuring duplicated code What does it take to utilize the metric? • 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!
- 14. Measuring dead code What 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.
- 15. Measuring dead code What does the trend mean? Constant low (~0) Growing Constant high • The code is commonly • There's no trigger • Too complex code understood and the for at least one base. responsibilities of objects is feature. clear to everyone.
- 16. Measuring dead code What does it take to utilize the metric? • 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!
- 17. 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.
- 18. Measuring code covered by (automated) tests. What does the trend mean? Code-coverage has the only trend where the higher is better. G Constant low (~0) Constant high r o w i n g • • Fearless code commit. T Modification of the code is expensive, h e r e ' s • n o t r i g g time-consuming and error-prone. e r f o r a t l e a s t o n e f e a t u r e . 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.
- 19. Measuring code covered by (automated) tests. What does it take to utilize the metric? • 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!
- 20. Number of open tasks What is it? Occurrence of comments or annotations in the source code that indicate an unfinished Marked tasks are identified as possible engineering task, suboptimal or sources of technical hard-to-read code, or other kinds debt. of technical debt. • todo • review Can occur in comment • fixme • refactor blocks, having @ //, etc. • xxx • wtf prefixes. • hack • omg
- 21. Number of open tasks What does the trend mean? Constant low (~0) Lowering • Programmers have the opportunity • The development team is paying to always do their best. back technical debt. • No identified source of technical debt. • Well maintained code. 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.
- 22. Number of open tasks What does it take to utilize the metric? • 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!
- 23. 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.
- 24. Amount of overly complicated expressions. What does the trend mean? Constant low (~0) Growing Constant high • Optimal, well structured • Unclear business • Untestable, code. logic. unreadable, hard to • Lack of refactoring maintain code base. skills. • Generates fear of change. • Not optimal code.
- 25. Amount of overly complicated expressions. What does it take to utilize the metric? • Automated measurement and reporting tool. • Company-wide policy for value limits. • Developer skill to eliminate valuations. • People caring about the trend!
- 26. 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
- 27. Measuring modularity A tightly coupled application operates with concrete implementations where the slightest modification to one of the collaborators can cause big impacts to the others.
- 28. Measuring modularity A loosely coupled architecture relies on interfaces. (Output, Database, NoSql) Swapping one implementation to another causes no impact on any other collaborator!
- 29. Measuring modularity 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.
- 30. Measuring modularity What does it take to utilize the measurements? • Packages. • Automated measurement and reporting tool. • Developer skill to introduce abstraction. • People caring about the trend!
- 31. Broken Window Syndrome If a window in a building is broken and left unrepaired all the rest of the windows will soon be broken. . .
- 32. Broken Window Syndrome One unrepaired If disorder goes unchecked, a vicious window is a signal cycle begins. First, it kindles a fear of that no one cares, crime among residents, who respond by so breaking more staying behind locked doors. Their windows costs involvement in the neighborhood nothing. . . . 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.
- 33. Broken Window Syndrome 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/
- 34. "You can't improve what you don't measure." When do you start improving?
Editor's Notes
- #33: kindles = fellángol declines = csökken cease = megszűnik loitering = csavargás truant = iskolakerülő