Managing Software Debt Workshop at Intel
4 likes•1,364 views
The document provides an overview of a workshop on managing software debt. It discusses various types of software debt including technical debt, quality debt, configuration management debt, design debt, and platform experience debt. It emphasizes the importance of focusing on quality and design through activities like refactoring, test automation, and defining a done approach to prevent further accumulation of software debt over time. The workshop agenda covers topics like continuous integration, quality dashboards, release management, and wrapping up with a discussion of software debt management strategies.
![THE
DISECONOMIES
OF
SCALE
IN
SOFTWARE
DEVELOPMENT*
Project
size
is
easily
the
most
significant
determinant
of
effort,
cost
and
schedule
[for
a
soHware
project].*
*
“SoHware
EsOmaOon:
DemysOfying
the
Black
Art
“
–
Steve
McConnell](https://image.slidesharecdn.com/managingsoftwaredebt-intel-120404112720-phpapp01/85/Managing-Software-Debt-Workshop-at-Intel-6-320.jpg)
![Merciless
Refactoring
Refactoring:
a
disciplined
technique
for
restructuring
an
exisOng
body
of
code,
altering
its
internal
structure
without
changing
its
external
behavior.*
Merciless:
having
or
showing
no
[mercy
-‐
showing
great
kindness
toward
the
distressed]
Relieve
your
distressed
code
through
kindness
and
disciplined
restructuring
*
From
h)p://www.refactoring.com/
17](https://image.slidesharecdn.com/managingsoftwaredebt-intel-120404112720-phpapp01/85/Managing-Software-Debt-Workshop-at-Intel-17-320.jpg)
![Ken
Schwaber
“For
every
[dollar]
of
compe22ve
advantage
gained
by
cu9ng
quality,
it
costs
$4
to
restore
it;
and
so@ware
is
an
organiza2onal
asset
and
decisions
to
cut
quality
must
be
made
by
execu2ve
management
and
reflected
in
the
financial
statements.”
hIp://www.infoq.com/presenta2ons/agile-‐quality-‐canary-‐coalmine](https://image.slidesharecdn.com/managingsoftwaredebt-intel-120404112720-phpapp01/85/Managing-Software-Debt-Workshop-at-Intel-36-320.jpg)
Managing Software Debt Workshop at Intel
- 1. Managing So)ware Debt Workshop
- 2. First Things First... Follow on Twi)er: @csterwa Hash Tag: #swdebt 2
- 3. Chris Sterling Co-‐founder & CTO of Agile Advantage www.AgileAdvantage.com Author of Book “Managing SoHware Debt: Building for Inevitable Change” Consults on soHware technology, Agile technical pracOces, Scrum, and effecOve management techniques InnovaOon Games® Trained Facilitator Email: [email protected] Web: h<p://www.agileadvantage.com CerOfied Scrum Trainer Follow me on Twi)er: @csterwa Blog: h<p://www.ge?ngagile.com Open Source Developer Hashtag for presentaOon: #swdebt 3
- 4. Agenda Managing SoHware Debt • ConOnuous IntegraOon • An Overview • Quality Dashboards Types of SoHware Debt Release Management • Technical • The Power of 2 Scripts: Deploy • Quality and Rollback • ConfiguraOon Management • ConOnuous IntegraOon • Design • Automated PromoOon • PlaZorm Experience • Turn On/Off Features AsserOng Quality & Design Wrap Up • Refactoring • SoHware Debt Management Strategy • Test AutomaOon • The “No Defect” Mindset • DefiniOon of Done 4
- 5. Managing So)ware Debt An Overview
- 6. THE DISECONOMIES OF SCALE IN SOFTWARE DEVELOPMENT* Project size is easily the most significant determinant of effort, cost and schedule [for a soHware project].* * “SoHware EsOmaOon: DemysOfying the Black Art “ – Steve McConnell
- 7. Big Ball of Mud “A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-‐tape-‐and-‐baling-‐wire, spaghei-‐code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. InformaOon is shared promiscuously among distant elements of the system, oHen to the point where nearly all the important informaOon becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recogniOon. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inerOa of the day-‐to-‐day chore of patching the holes in these failing dikes, are content to work on such systems.” * * Brian Foote and Joseph Yoder, Big Ball of Mud. Fourth Conference on Pa)erns Languages of Programs (PLoP '97/EuroPLoP '97) MonOcello, Illinois, September 1997
- 9. Lack of emphasis on so'ware quality a2ributes contributes to decay
- 10. Types of So)ware Debt Technical, Quality, ConfiguraOon Management, Design, and PlaZorm Experience
- 11. Why not just call it all “ Technical Debt” Technical debt tended to focus more on programming aspects of soHware delivery and leH out full soHware development life cycle Each type of soHware debt can be managed and monitored using different tools and approaches Focusing on managing each type of soHware debt simplifies creaOon of an overall strategy that promotes holisOc perspecOve 11
- 12. Types of SoHware Debt Technical Debt: These are the acOviOes that a team or team members take shortcuts on now that will impede future development if leH as is. Quality Debt: There is a diminishing ability to verify the funcOonal and technical quality of soHware: the “Break/Fix” mentality. Configura<on Management Debt: IntegraOon and release management become more risky, complex, and error-‐prone. Design Debt: The cost of adding features is increasing toward the point where it is more than the cost of wriOng from scratch. Pla?orm Experience Debt: The availability and alignment of people to business objecOves that involve soHware changes is becoming more limited or cost-‐prohibiOve. 8
- 13. Exercise: Discuss the 5 Types of SoHware Debt and Examples You’ve Seen in the Real World
- 14. Principle: No ma)er what, the cost of addressing soHware debt increases with Ome.
- 15. Asser<ng Quality & Design Teams must focus on asserOng sustainable quality and design to support future customer needs
- 16. Principles of Executable Design The way we design can always be improved. We’ll get it “right” around the third Ome. We most likely won’t get it “right” the first Ome. Design and construct for change rather than longevity. Lower the threshold of pain. If we are not enhancing the design then we are just wri3ng a bunch of tests. 16
- 17. Merciless Refactoring Refactoring: a disciplined technique for restructuring an exisOng body of code, altering its internal structure without changing its external behavior.* Merciless: having or showing no [mercy -‐ showing great kindness toward the distressed] Relieve your distressed code through kindness and disciplined restructuring * From h)p://www.refactoring.com/ 17
- 18. Where to Start Refactoring? Does this change directly affect feature I am working on? Would change add clarity for feature implementaOon? Will change add automated tests where there are none? If “yes” to any ques3on above, ask following ques3on to decide if you should work on it now: At first glance, does refactoring look like a large endeavor involving significant porOons of the soHware’s components? 18
- 19. When to Stop Refactoring? Am I refactoring code not directly affected by feature? Is other code directly affected by feature I am working on that has not been refactoring sufficiently? If refactoring is exploding feature esOmate given to Customer then I should bring it up to Team to decide how we should progress If Team decides that refactoring can be absorbed into current iteraOon without affecOng delivery on our commitments then conOnue refactor If refactoring affects commitments then bring it to Customer for discussion how to proceed 19
- 20. Automate TesOng to Support Refactoring cannot be done effecOvely without automated tests surrounding code Start by creaOng automated test which fails If difficult to create at unit level look at automated acceptance tests from funcOonal perspecOve Over Ome look for ways to create automated unit tests 20
- 21. Case Study: Test AutomaOon Reduces Cost of Change
- 22. Manual Regression TesOng TesOng was taking 75 person hours during 2 full test runs consisOng of: • Comprehensive manual regression tesOng • Data conversion and validaOon Cost for tesOng was $17,000 each iteraOon 22
- 23. Introducing Fit into TesOng Process AHer 8 iteraOons team had introduced healthy amount of Fit fixtures and automated tests Reduced 70+ hour test runOme down to 6 hours which now included: • Fit automated regression tesOng • Data conversion and validaOon automated with Fit fixtures Reduced cost of tesOng each iteraOon from $17,000 to $7,000 23
- 24. The Agile Regression TesOng Triangle* Smoke++ Tests Risk-‐based UI & API Automated Integra3on Tests Tests Automated & Exploratory Automated Unit Tests Make up largest porOon of regression tests and are developed by programmers * The Agile Triangle has been modified from Mike Cohn’s original version 24
- 25. Test-‐Driven Design (TDD) Lets Walk Through a Scenario Using TDD to Implement a SoluOon
- 26. TDD -‐ Basic “Flow” Write Failing Test Refactor to Acceptable Make Test Pass Design 26
- 27. Ji)er – Example TDD Session Fake micro-‐blogging tool named “Ji)er” is made by Sea)le-‐based ficOOous company that focuses on enabling coffee injected folks to write short messages and have common online messaging shorthand expanded for easy reading. The user story we are working on is: So it is easier to read their kid’s messages, Mothers want to automa3cally expand common shorthand nota3on The acceptance criteria for this user story are: • LOL, AFAIK, and TTYL are expandable • Expand lower and upper case versions of shorthand 27
- 28. Expand LOL to “laughing out loud” public class WhenMotherWantsToExpandMessagesThatContainShorthandTest { @Test public void shouldExpandLOLToLaughingOutLoud() { JitterSession session = mock(JitterSession.class); when(session.getNextMessage()).thenReturn("Expand LOL please"); MessageExpander expander = new MessageExpander(session); assertThat(expander.getNextMessage(), equalTo("Expand laughing out loud please")); } } public class MessageExpander { public String getNextMessage() { String msg = session.getNextMessage(); return msg.replaceAll("LOL", "laughing out loud"); } } 28
- 29. But wait…what if…? What if LOL is wri)en in lower case? What if it is wri)en as “Lol”? Should it be expanded? What if some variaOon of LOL is inside a word? What if characters surrounding LOL are symbols, not le)ers? Write these down as upcoming programmer tests as comments so I don’t forget them. // shouldExpandLOLIfLowerCase // shouldNotExpandLOLIfMixedCase // shouldNotExpandLOLIfInsideWord // shouldExpandIfSurroundingCharactersAreNotLetters 29
- 30. Expand LOL If Lower Case @Test public void shouldExpandLOLIfLowerCase() { when(session.getNextMessage()).thenReturn("Expand lol please"); MessageExpander expander = new MessageExpander(session); assertThat(expander.getNextMessage(), equalTo("Expand laughing out loud please")); } This forced use of java.u1l.regex.Pa6ern to handle case insensi1vity. public String getNextMessage() { String msg = session.getNextMessage(); return Pattern.compile("LOL”, Pattern.CASE_INSENSITIVE) .matcher(msg).replaceAll("laughing out loud"); } 30
- 31. Don’t Expand “Lol” – Mixed-‐Case @Test public void shouldNotExpandLOLIfMixedCase() { String msg = "Do not expand Lol please"; when(session.getNextMessage()).thenReturn(msg); MessageExpander expander = new MessageExpander(session); assertThat(expander.getNextMessage(), equalTo(msg)); } This forced me to stop using Pa6ern.CASE_INSENSITIVE flag in pa6ern compila1on. Only use “LOL” or “lol” for now. public String getNextMessage() { String msg = session.getNextMessage(); return Pattern.compile("LOL|lol").matcher(msg) .replaceAll("laughing out loud"); } 31
- 32. Don’t Expand “LOL” If Inside Word @Test public void shouldNotExpandLOLIfInsideWord() { String msg = "Do not expand PLOL or LOLP or PLOLP please"; when(session.getNextMessage()).thenReturn(msg); MessageExpander expander = new MessageExpander(session); assertThat(expander.getNextMessage(), equalTo(msg)); } The pa6ern matching is now modified to use spaces around each varia1on of valid LOL shorthand. return Pattern.compile("sLOLs|slols").matcher(msg) .replaceAll("laughing out loud"); 32
- 33. Expand “LOL” If Not Inside Word @Test public void shouldExpandIfSurroundingCharactersAreNotLetters() { when(session.getNextMessage()).thenReturn("Expand .lol! please"); MessageExpander expander = new MessageExpander(session); assertThat(expander.getNextMessage(), equalTo("Expand .laughing out loud! please")); } Final implementa1on of pa6ern matching code: return Pattern.compile("bLOLb|blolb").matcher(msg) .replaceAll("laughing out loud"); 33
- 34. Quality Debt “Promises make debt, and debt makes promises.” -‐ Dutch Proverb
- 35. Effect of Project Constraints on Quality 35
- 36. Ken Schwaber “For every [dollar] of compe22ve advantage gained by cu9ng quality, it costs $4 to restore it; and so@ware is an organiza2onal asset and decisions to cut quality must be made by execu2ve management and reflected in the financial statements.” hIp://www.infoq.com/presenta2ons/agile-‐quality-‐canary-‐coalmine
- 38. DefiniOon of Done -‐ Assert Quality Acceptance defined criteria for each Code checked in with reference to user story US#/Task# Unit tests written and passed Tested on FE Code compiles with no errors and no Integration test written & passes warnings Test code reviewed New code doesn’t break existing code Environment requirements documented Test case review (Dev to review test Interface document updated/added case written) and checked in to SVN Architectural impact assessed and Acceptance criteria verified complete artifacts updated if necessary All P1-P3 bugs for the story are Comments in code closed Error codes added Test approves user story Code reviewed by peer Story demonstrated to product owner and accepted on Target Platform 38
- 39. Release DefiniOon of Done Every release should have clear quality criteria With a “Release DefiniOon of Done” you can understand targets be)er Measure the gap between the teams’ DefiniOon of Done and a Release DefiniOon of Done. • This gap is a source of quality issues and represents significant risk to schedule
- 40. Exercise: What’s in Your DefiniOon of Done?
- 41. Advanced Quality Asser<ons Using Automated Tools and Dashboards
- 42. ConOnuous IntegraOon 42
- 43. Quality Dashboard -‐ Sonar 43
- 44. Quality Dashboard -‐ Sonar 44
- 45. Quality Dashboard -‐ Sonar 45
- 46. Quality Dashboard -‐ Sonar 46
- 47. Early Warning Signs Early Warnings: •Broken Builds •Broken Automated Tests •Broken Custom Thresholds 47
- 48. Early Warning on Quality Dashboard Early Warnings: •Design Debt in DuplicaOon (DRY) •Technical Debt in Code Complexity •Quality Debt in Bug DB (Break/Fix) •Other Custom Thresholds 48
- 49. Release Management “If releases are like giving birth, then you must be doing something wrong.” -‐ Robert Benefield
- 50. Case Study: Enterprise Agile AdopOon 180+ person “Web 2.0” product organizaOon Waterfall SDLC that development uses to deliver in 6 month release cycles Want to use Agile methods to be more responsive to users and keep up with other “Web 2.0” companies TransiOoned to Agile methods on 15 teams in 3 months Changed release management strategy, added XP technical pracOces, and implemented Scrum product development framework for scaled coordinaOon Able to release every week to users within 4 months Used streamlined deployment environment process to validate product changes daily using ConOnuous IntegraOon and automated promoOons 50
- 51. The Power of 2 Scripts: Deploy & Rollback 51
- 52. TradiOonal Source Control Management Code Complete Version 1 Integrate for Branch Version 2 Debt Main Branch Death March { Debt accrues quickly within stabiliza<on periods 52
- 53. Flexible Source Control Management Version 1 Version 2 Main Branch { Not Easy! Must have proper infrastructure to do this. 53
- 54. Scaling ConOnuous IntegraOon End-‐to-‐End & Load/Stress Integrated Component Valida<on Component Valida<on 54
- 55. Automated PromoOon to Environments 55
- 56. Principle: The value of technical aspects in an applicaOon or its surrounding infrastructure is the cost of not addressing them. 29
- 57. Describe as Abuse User Stories Implement Security As a Malicious Hacker I want to steal credit card for User Information information so that I can make fraudulent charges * From “User Stories Applied” presented by Mike Cohn Agile 2006 30
- 58. Some PotenOal Abusers • Malicious Hacker • Mass of users • SQL injector • Disgruntled employee • Naïve API user • ImpaOent clicker • Denial-‐of-‐service (DoS) a)acker • Sleazy user 31
- 59. Exercise: Abuse Story WriOng
- 60. SoHware Quality A)ributes Defined 32
- 61. SoHware Quality A)ributes RaOng Tool 33
- 62. Exercise: Focusing on SoHware Quality A)ributes
- 63. Pla?orm Experience Debt “As in Nature, if an organizaOon is too inflexible or stands sOll too long it will get eaten.” -‐ James Burke (author and historian)
- 64. Principle: Rather than creaOng teams to work on projects, let’s find ways to give projects to cross-‐ funcOonal teams.
- 65. Component Team ConfiguraOon “Component Team” structure Separate Product Backlog Managing dependencies is oHen serialized ProblemaOc integraOon issues are typically faced if mulOple components are required to release Use an “IntegraOon Team” to pull components together Causes more rework than “Feature Team” structure 65
- 66. Feature Team ConfiguraOon “Feature Team” structure Uses common Product Backlog Integra2on is done in parallel Requires high levels of communica2on across teams to resolve integra2on issues Forces Product Owners to be more coordinated Sprints should be synchronized Cross team fer2liza2on is a requirement to successfully deliver in parallel 66
- 67. Exercise: CreaOng a SoHware Debt Management Strategy
- 68. The “No Defect” Mindset “What he needs is some way to pay back. Not some way to borrow more.” -‐-‐ Will Rogers 39
- 69. Case Study: Field Support ApplicaOon 2000+ users access applicaOon each day ApplicaOon supports mulOple perspecOves and workflows from Field Support OperaOons to Customer Service Team of 5 people delivering features on exisOng Cold Fusion plaZorm implementaOon MigraOng Architecture to Spring/Hibernate in slices while sOll delivering valuable features 36 2-‐week Sprints, 33 producOon releases, and only 1 defect found in producOon So, what was the defect you say? Let me tell you… 40
- 70. Can We Afford a “No Defect” Policy? This team worked on legacy codebase inherited from another vendor Other vendor had been slowing down month aHer month and cost of development was increasing In first iteraOon this team was able to deliver more than other vendor was able to in previous 2 months AHer 24 iteraOons this team was 10 Omes faster delivery than1st iteraOon Acceptance Test-‐Driven Development and ConOnuous IntegraOon were greatest technical factors to support team in these results Can you afford not to have a “No Defect” policy? 41
- 72. The Power of 2 Scripts: Deploy & Rollback 72