Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Julian Warszawski, profile picture
Uploaded byJulian Warszawski
PPTX, PDF597 views

Tech debt will kill us

Tech debt can seriously impact a project if not properly managed. It leads to increased costs, slower delivery times, and lower quality code as complexity grows unchecked over time. Measuring and tracking technical debt using tools like SonarQube allows teams to define, measure, analyze, and improve areas of accidental complexity. This helps reduce debt, free up developer time for new features, and maintain predictability and quality as a project evolves. However, care must be taken not to shift focus too much to metrics or mandate thresholds at the expense of actual code quality improvements. Managing technical debt is important for long term products and codebases.

Software◦
Downloaded 24 times
Tech debt will kill us Managing technical debt at enterprise scale with Sonarqube by Julian Warszawski
What is tech debt • Abstract term • Lots of definitions • Not useful
Which terms associate with tech debt? pressure long term goals short term goals clean code hack accidental design automation workaround
What is tech debt forget code quality forget bug count forget engineers morale Delivery Speed ~ 1/Tech Debt Only thing to know about effects of tech debt
Why will it kill us It takes 2 months for anyone to ramp up on this codebase It used to take 5 people to keep up. Now it is 25. 95% of the team is fixing bugs It will be easier to rewrite this component than extend it.
Why delivery speed drops? • Designing from scratch is super fast • After first sprint you don’t design from scratch • Existing complexity slows down further design • Complexity ALWAYS grows • There is domain complexity and accidental complexity • You CAN control accidental complexity
What can we do src: sixsigmadaily.com
Define Accidental complexity Untested code Tangled packages Lack of cohesion Copy-paste code not following best practices
Measure • Java: checkstyle, pmd, jacoco, pitest, … • Python: Pylint • C++: cppcheck, gcov, custom plugins. • Other languages: C#, SQL, PHP, Flex, XML, Groovy and others
Analyze
Improve
Control compile unit testing integration testing quality gate functional testing ship it
Sonarqube sonar dashboard sonar runner source repo CI Server commit pull run publish
DEMO demo
What’s in it for DEV Less tech debt More time for features better software Ambitious DEV My code will be PROLazy DEV Less possibility for something to break. No STRESS
What’s in it for PM Less tech debt More time for features predictability Agile PM We can deliver fasterWaterfall PM Finally everything goes according to PLAN
What’s in it for CEO Less tech debt More time for features improved delivery capabilities Fresh CEO I don’t have to worry about BAU, can focus on strategy Retiring CEO Clients are happy, stocks are up
Doubts • This does not present REAL design debt. It hides the real design debt. • Yet another step in our build pipeline. Can we afford it? • Focus will be shifted from delivering products to improving sonar metrics.
This is not REAL design debt • Accidental complexity is real design debt • Untested code is real design debt • Accurate correlates of design problems • Degradation: correlate of process problems • By observing symptoms, you can be proactive
Another step in the pipeline • No, if set up correctly • Quality gates – warnings and fails • Does not have to monitor every commit (nightly checks) • Do not block the pipeline, allow fast reverts • Focus on prevention
Focus shifted to improving metrics • These metrics are symptoms, not the essence • You don’t fix tech debt by just fixing compiler warnings, test coverage or static violations • Do not compete for grades • DO NOT MANDATE THRESHOLDS!!!
DO NOT MANDATE THRESHOLDS • People should work 8 hours a day • Do you have alerts if they leave job too early? • Thresholds promote ignorance • E. g. it is more important to write good tests than achieving the coverage goal • Boy scout rule: Leave the code simpler and cleaner than it was when you saw it.
Who benefits more Game Development Fire and forget Sales POC Delivering in 1 month more critical than future-proofing Codebase is representing a core product Product addresses long term strategy Product will be extended for years little value lots of value
QUESTIONS any