Creative Commons Attribution 3.0 Kane Mar and Others (see credits)

1
(No Transcript)
2
Creative Commons Attribution 3.0Kane Mar and
Others (see credits)

• You are free
• to Share to copy, distribute and transmit the
  work
• to Remix to adapt the work
• Under the following conditions
• Attribution. You must attribute the work in the
  manner specified by the author or licensor (but
  not in any way that suggests that they endorse
  you or your use of the work)
• http//creativecommons.org/licenses/by/3.0/

3
(No Transcript)
4
What is Technical Debt

• The concept of software complexity as debt was
  originally coined by Ward Cunningham in an
  experience report for OOPSLA 92 ()
• Reference http//c2.com/doc/oopsla92.html

5
What is Technical Debt

• During the planning or execution of a software
  project, decisions are made to defer necessary
  work
• It's too late in the LifeCycle? to upgrade to the
  new release of the compiler. We'll do it next
  time around.
• We're not completely conforming to the
  UserInterface guidelines. We'll get to it next
  time.
• We don't have time to uncruft the hyper-widget
  code. Punt until next time.

6
What is Technical Debt

• A big pile of deferred work can gum up a project,
  yet many of the items on the list don't appear on
  a project team's radar, especially if the focus
  is primarily on new product features. Yet
  removing accumulated sludge needs to be accounted
  for in planning!
• Therefore Make the debt visible. Keep an
  explicit list Technical Debt

7
(No Transcript)
8
(No Transcript)
9
How does Technical Debt occur?

• By not enforcing high quality standards in the
  definition of done.
• Cutting corners to achieve a higher velocity and
  meet impossible timelines leads to build up of
  low quality, unmaintainable code.
• Death spiral As the maximum velocity of system
  goes down, even more corners are cut to
  compensate until the velocity approaches zero.

10
Signs of Technical Debt

• The code is considered part of a core or legacy
  system
• There is either no testing, or minimal testing
  surrounding the code
• There is highly compartmentized knowledge
  regarding the core/legacy system, and it may be
  supported by only one or two people in the
  company (over specialization)

11
Signs of Technical Debt

• The legacy system is not in a know state
• It takes as long to fix defects caused be adding
  new functionality, as it does to add the new
  functionality
• Re-platforming ... and then repeat the mistakes
  of the past

12
What to do about Technical Debt

• Avoid accumulating technical debt
• Pay it off over time (mortgage)
• Working with legacy code by Michael Feathers
• An anti-pattern worth mentioning

13
Avoid Technical Debt

• Implement the Agile Engineering practices
• Continuous Integration
• Test Driven Development
• Refactoring
• Pair Programming

14
Avoid Technical Debt

• Development teams must curb over-optimism in
  assessing availability and capacity
• Management redirects attention from applying
  pressure to removing organizational impediments
  to progress
• Product Owners understand the iron triangle,
  ownership of risks, and impact of cutting quality
• ScrumMaster must prevent demonstration of any
  work that is not done

15
Paying off Technical Debt

• Described by Michael Feathers in Working
  Effectively with Legacy code
• Start by introducing Continuous Integration
• Write Tests around customer reported defects
• Over a period of time a testing framework will be
  built up around the most brittle code

16
And Avoid this anti-pattern

• There is a temptation to try and write a
  comprehensive testing framework around the entire
  product
• Does not address the defects that the customer
  views as most important
• May run out of money before you complete the
  framework

17
(No Transcript)
18
Photos Credits

• http//www.flicker.com/photos/yujin_it
• http//www.flickr.com/photos/66164549_at_N00/
• http//www.flicker.com/photos/vernhart/
• http//www.flickr.com/photos/lambda_x/