• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Transitioning to quality software
 

Transitioning to quality software

on

  • 1,957 views

Transitioning from working software to quality software

Transitioning from working software to quality software

Statistics

Views

Total Views
1,957
Views on SlideShare
1,728
Embed Views
229

Actions

Likes
5
Downloads
8
Comments
0

9 Embeds 229

http://alternateillusion.com 159
http://www.meza.hu 44
http://www.linkedin.com 12
http://feeds.feedburner.com 5
https://www.linkedin.com 5
http://translate.googleusercontent.com 1
http://posterous.alternateillusion.com 1
http://alternateillusion.posterous.com 1
http://alternateillusion.blogspot.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • kindles = fellángol declines = csökken cease = megszűnik loitering = csavargás truant = iskolakerülő

Transitioning to quality software Transitioning to quality software Presentation Transcript

    • 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
      • Number of coding standard violations.
      • Number of duplicated code.
      • Amount of dead code.
      • Amount of code covered by (automated) tests.
      • Number of open tasks. (todo, etc. in code)
      • Amount of overly complicated expressions.
      • Relationship between packages and objects (modularity).
      Exact measurements, straight-forward meanings:
      Complex measurements and meanings:
    • What do these trends generally indicate*?
      * assuming the engineers have the knowledge to realize the problems.
      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.
    • 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 violations
      What 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 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.
    • 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
      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!
    • 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.
    • Measuring dead code
      What does the trend mean?
      Constant low (~0)
      Growing
      Constant high
      • 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
      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!
    • 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?
      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.
      Constant low (~0)
      Constant high
      Growing
      • Modification of the code is expensive, time-consuming and error-prone.
      • Fearless code commit.
      • There's no trigger for at least one feature.
    • 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!
    • 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.
    • Number of open tasks
      What does the trend mean?
      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.
      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.
    • 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!
      Number of open tasks
    • 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.
    • Amount of overly complicated  expressions.
      What does the trend mean?
      Constant low (~0)
      Growing
      Constant high
      • 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.
    • 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!
      Amount of overly complicated  expressions.
    • 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
    • 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.
    • Measuring modularity
      A loosely coupled architecture relies on interfaces. (Output, Database, NoSql)
      Swapping one implementation to another causes no impact on any other collaborator!
    • 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.
    • 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!
    • 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.
      Broken Window Syndrome
    • 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/
    • "You can't improve what you don't measure."
      When do you start improving?