Uploaded byBrian Di Croce
Purging the Technical Debt
The document discusses technical debt in software development, defined as the cost of rework due to taking shortcuts in coding. It highlights the consequences of ignoring technical debt, including lost productivity and increased complexity, and identifies causes such as poor understanding and immature design. The document also suggests tools and processes to manage technical debt, emphasizing the importance of continuous improvement and effective communication.
More Related Content
Similar to Purging the Technical Debt
Purging the Technical Debt
- 1. Purging The TechnicalDebt Brian Di Croce, B.Eng., MCPD @bdicroce
- 2. Context Side Effects Tools andTechnologies Processes Wrap Up
- 3.
- 5. What is atechnical debt?
- 6. https://en.wikipedia.org/wiki/Technical_debt “Technical debt isa concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.” - Wikipedia
- 7. What is theconsequence if we don’t deal with it now?
- 8. The term “technicaldebt” was coined by Ward Cunningham (co-creator of XP) almost 30 years ago. "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."
- 11.
- 13. Why should wenot ignore our technical debt?
- 15. Because it givesus a sense of pride
- 17. Because we careabout the things we value
- 19. Because we’re init for the long run
- 21. In 2018, Stripe publishedthe results on an interesting study related to the current state of software development The Developer Coefficient: Software engineering efficiency and its $3 trillion impact on global GDP (PDF)
- 22. COMPANIES WASTE $300BILLION OF DEVELOPER PRODUCTIVITY EVERY YEAR “Developers spend over 17 hours every week dealing with maintenance issues like debugging and refactoring, and about a quarter of that time is spent fixing bad code. That’s nearly $300B in lost productivity every year. It’s not how many software engineers a company has; it’s how their talent is being utilized.” Source: The Developer Coefficient: Software engineering efficiency and its $3 trillion impact on global GDP
- 23. Source: The DeveloperCoefficient: Software engineering efficiency and its $3 trillion impact on global GDP
- 24.
- 25.
- 26. The law ofsoftware entropy states that as a system is modified, its disorder (entropy) tends to increase
- 27. In software development,that disorder (entropy) is represented by the delta of complexity
- 28. In his bookThe Mythical Man-Month: Essays in Software Engineering (1975), Prof. Frederick P. Brooks distinguishes two types of complexity: Essential Complexity Accidental Complexity
- 29. Essential complexity isthe fundamental implementation of functionalities to make the system work according to its intended purpose regardless of the inherent complexity
- 31. Accidental complexity isthe non-essential code or quick fixes that are implemented to prove a temporary idea or get a short-term gain, but remains intrinsic in the system.
- 33. Accidental complexity isthe main contributor to the technical debt.
- 34. But it’s notthe only one…
- 35.
- 37. Poor understanding ofthe problem
- 38. Lack of acomprehensive suite of tests
- 39. Immature design orsystem architecture (high coupling and low cohesion)
- 40. An incomplete orweak CI/CD strategy
- 41. Inefficient tools andprocesses
- 42. Software entropy increases indirect proportion to the technical debt
- 43. The Side Effectsof Technical Debt
- 44. Business logic intertwinedall over the codebase
- 45. Hundreds or thousandslines of code within a method or stored procedure
- 46. Continuous deployments solelyto fix bugs in production
- 47. Security vulnerabilities exposedpublicly
- 48. Unit tests thatrandomly pass or fail depending whether they’re executed individually or in parallel
- 49. Tools and Technologies SonarQube JetBrainsRider/ReSharper NDepend (.NET) StepSize (VSCode ext.)
- 50.
- 51. JetBrains Rider/ReSharper (IntelliJ forJava folks)
- 52.
- 53.
- 54.
- 55. Look into thepractices of Extreme Programming
- 56. Rapid Feedback Pair programming Planninggame Whole team
- 57.
- 58. Shared Understanding Coding standards Collectivecode ownership Simple design System metaphor
- 59.
- 60. Look into thevalues of Extreme Programming…
- 61.
- 62.
- 63.
- 64.
- 65.
- 66.
- 67. Remember that youdon’t have to ask permission to do the right thing
- 68.
Editor's Notes
- #2 I’ll upload the PowerPoint slides after the interview and send you a link. You can post it on Twitter and I’ll do the same.
- #7 Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.
- #9 Technical debt is a metaphor that equates to financial debt.
- #10 It’s the concept of time vs. money to market. Image URL: https://commons.wikimedia.org/wiki/File:Time_n_Money.jpg For a startup, contrary to an established brand, the decisions won’t be influenced by the same factors. Depending on the adopted solution, the result can be positive or negative down the road. The negative part is that there will be work, time and effort to plan in order to get back to the path of success.
- #11 This is the project management conundrum. In many cases, only two of these factors can be picked.
- #12 It’s about the NOW vs LATER question. It’s not easy to answer this question. It’s super hard. Technical debt will always be present…its importance, its weight will be determined by the answer to this question. What if you’re building a new software that you have to publish to a user base because of the competition? What if you’re building a mission-critical app that could affect people’s health, the financial market or the environment…the answer will vary.
- #13 Eat delicious, juicy, tasty junk food and you might enjoy it now, but you’ll pay it later with health issues. Eat boring, monotonous, but nutritious food now and you’ll reap the benefits of a healthy lifestyle in the future. It’s about the NOW vs LATER.
- #14 In order to answer this question, we must first answer a few “real-life” questions that should provide an answer to this one.
- #15 Why do we wash our cars?
- #16 Because you’re proud of your car. You also want to know early on if there are any defects before you drive it on the road. Think about your software, your code…Pride in our work is important because it motivates us to do good work
- #17 For those that may not have a car…Why do you wash your bike? Next slide for the answer…
- #18 Because you care. Because you want to know that your tires and drivetrain are operational before you hop on it and pedal away with it. Think about your software, your code…
- #19 Why do you work out? Next slide…
- #20 Because you want to take care of your body. It’s the only vehicle you have to travel and discover your world.
- #21 Technical debt can slow you down or shut you down (startup). You’ll get to your destination, but it’ll be painful, you’ll get there late…and you might get there in last position.
- #24 Forbes: Technical debt drives developers mad: It makes their jobs progressively more difficult, more time-consuming, and less rewarding. Considering that it costs up to $67,500 to recruit and train a new developer, the costs of technical debt add up quickly when it’s chasing developers out the door. https://www.forbes.com/sites/falonfatemi/2016/05/30/technical-debt-the-silent-company-killer/#6bd4c8f84562
- #26 We’ll understand complexity in the next slide…
- #27 To understand what complexity is and the different nature of complexity, we should get familiarize with the law of software entropy. READ SLIDE Now that we’re building more distributed systems, the law of software entropy is much more important than before, because not only do we have the codebase to nurture, but now we have to consider the supporting systems such as the hardware, the virtual machines, the hard drives, the system memory, the third party services, and more importantly the networks where all these component live and communicate with each other. Things can break.
- #30 Essential complexity is the fundamental required blocks that are assembled to make a system serve and react according to its intended purpose regardless of the inherent complexity
- #31 Take for example a tree. It looks very simple in appearance, but inside of it lives quite a complex system that collaborates in a so-called “distributed environment”. The roots, the leaves, the bark are all affected by its input (water, wind, sunlight and other nutrients). But in return, it produces photosynthesis to output an essential product for life on earth and under the water. Most things in nature have an essential complexity.
- #32 The result of it is also called a “big ball of mud”.
- #33 Maybe this place started with one sign…then another one was put up…then another…someone forgot to leave the system in a clean state after changing it. Most things made by men have an accidental complexity. .
- #42 - Commit messages not being descriptive enough
- #43 The “debt” is what you will pay or reimburse in both time and effort to reduce or eliminate the accidental complexity or its secondary effects (bugs, missing functionalities, refactoring, etc.) If that debt is not repaid, it can accumulate “interest” which makes it harder to implement changes. You can still advance, but not as fast because now you have potential bugs or performance issues waiting for you at runtime (as if you’re walking attached to a chain ball).
- #44 What are the consequences or effects of technical debt?
- #46 If you have to scrollbar a lot within a method, that’s already a sign that the method might suffer from accidental complexity.
- #50 The tools are there to help you make logical decisions based on quantitative metrics instead of being directed with your emotions or assumptions. They help you decide what to fix and why, so that you don’t have to waste time in guessing what to improve during a sprint.
- #51 Show demo of SonarQube Show how it integrates with CI pipeline Show how it integrates with other IDEs (SonarLint) You can’t understand what you don’t measure Opensource web application that analyzes source code and provides various kind of quality metrics based on the analysis Metrics helps to make smart decisions that are not driven by emotions - Supports over 20 programming languages and keeps up with the majority of the languages updates - You can install it on premise or on a Docker container (perfect scenario for quickly hosting it on Digital Ocean for example) - You can use it as part of your CI pipeline
- #52 Using a smart, fast, simple IDE not only helps to write code quickly, but looks over our shoulder to make sure we didn’t miss anything…or created a potential defect in the code. Rider: Code inspections (project vs solution) Plugins: CodeStream: great extension if working with remote colleagues. Communicate about your code within the IDE CognitiveComplexity (one of the metrics for SonarQube) Visual Studio/R# Solution > Code Metrics Select project > ReSharper > Inspect > Code Issue Solution > Dependency Graph
- #53 Integrates with your CI process (Azure DevOps, TeamCity)
- #62 Building software systems requires communicating system requirements to the developers of the system. In formal software development methodologies, this task is accomplished through documentation. Extreme programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team. The goal is to give all developers a shared view of the system which matches the view held by the users of the system. To this end, extreme programming favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback.
- #63 Extreme programming encourages starting with the simplest solution. Extra functionality can then be added later. The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow, next week, or next month. This is sometimes summed up as the "You aren't gonna need it" (YAGNI) approach.[11] Proponents of XP acknowledge the disadvantage that this can sometimes entail more effort tomorrow to change the system; their claim is that this is more than compensated for by the advantage of not investing in possible future requirements that might change before they become relevant. Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed, while perhaps delaying crucial features. Related to the "communication" value, simplicity in design and coding should improve the quality of communication. A simple design with very simple code could be easily understood by most programmers in the team.
- #64 Within extreme programming, feedback relates to different dimensions of the system development: Feedback from the system: by writing unit tests,[5] or running periodic integration tests, the programmers have direct feedback from the state of the system after implementing changes. Feedback from the customer: The functional tests (aka acceptance tests) are written by the customer and the testers. They will get concrete feedback about the current state of their system. This review is planned once in every two or three weeks so the customer can easily steer the development. Feedback from the team: When customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement. Feedback is closely related to communication and simplicity. Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break. The direct feedback from the system tells programmers to recode this part. A customer is able to test the system periodically according to the functional requirements, known as user stories.[5] To quote Kent Beck, "Optimism is an occupational hazard of programming. Feedback is the treatment."[12]
- #65 Several practices embody courage. One is the commandment to always design and code for today and not for tomorrow. This is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else. Courage enables developers to feel comfortable with refactoring their code when necessary.[5] This means reviewing the existing system and modifying it so that future changes can be implemented more easily. Another example of courage is knowing when to throw code away: courage to remove source code that is obsolete, no matter how much effort was used to create that source code. Also, courage means persistence: a programmer might be stuck on a complex problem for an entire day, then solve the problem quickly the next day, but only if they are persistent.
- #66 Respect for others and the system The respect value includes respect for others as well as self-respect. Programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers. Members respect their own work by always striving for high quality and seeking for the best design for the solution at hand through refactoring. Adopting the four earlier values leads to respect gained from others in the team. Nobody on the team should feel unappreciated or ignored. This ensures a high level of motivation and encourages loyalty toward the team and toward the goal of the project. This value is dependent upon the other values, and is oriented toward teamwork.
- #68 Implementing these tools or adopting some the practices is not a hard thing to do.