This presentation introduces the viewer to the concept of the technical debt and provides strategies to eliminate it as much as possible by using tools and processes.
6. https://en.wikipedia.org/wiki/Technical_debt
“Technical debt is a 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 the consequence if
we don’t deal with it now?
8. The term “technical debt” 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."
21. In 2018,
Stripe published the
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 $300 BILLION 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 Developer Coefficient:
Software engineering efficiency and its
$3 trillion impact on global GDP
28. In his book The Mythical
Man-Month: Essays in
Software Engineering
(1975), Prof. Frederick P.
Brooks distinguishes two
types of complexity:
Essential Complexity
Accidental Complexity
29. Essential complexity is the fundamental
implementation of functionalities to make the
system work according to its intended purpose
regardless of the inherent complexity
30.
31. Accidental complexity is the 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.
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.
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.
Technical debt is a metaphor that equates to financial debt.
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.
This is the project management conundrum. In many cases, only two of these factors can be picked.
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.
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.
In order to answer this question, we must first answer a few “real-life” questions that should provide an answer to this one.
Why do we wash our cars?
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
For those that may not have a car…Why do you wash your bike?
Next slide for the answer…
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…
Why do you work out?
Next slide…
Because you want to take care of your body. It’s the only vehicle you have to travel and discover your world.
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.
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
We’ll understand complexity in the next slide…
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.
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
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.
The result of it is also called a “big ball of mud”.
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. .
- Commit messages not being descriptive enough
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).
What are the consequences or effects of technical debt?
If you have to scrollbar a lot within a method, that’s already a sign that the method might suffer from accidental complexity.
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.
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
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
Integrates with your CI process (Azure DevOps, TeamCity)
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.
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.
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]
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.
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.
Implementing these tools or adopting some the practices is not a hard thing to do.