Managing Technical Debt - WordCamp Orlando 2017
•Download as PPTX, PDF•
0 likes•276 views
Slides for my talk about technical debt. Originally presented at at WordCamp Orlando 2017 and at MergeConf 2017. Find me on twitter @drmmr763 #wcorl
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Managing Technical Debt - WordCamp Orlando 2017
Similar to Managing Technical Debt - WordCamp Orlando 2017 (20)
More from Chad Windnagle
More from Chad Windnagle (10)
Recently uploaded
Recently uploaded (20)
Managing Technical Debt - WordCamp Orlando 2017
- 1. Managing Technical Debt In Your Software Team Chad Windnagle
- 2. T O P I C I N T R O D U C T I O N
- 7. T E A M P L A Y E R
- 8. D E F I N I N G T E C H N I C A L D E B T
- 9. D E B T M E T A P H O R @WardCunningham
- 10. M I N D S E T
- 11. A C T U A L T E C H N I C A L D E B T Duplicate Code Inconsistent Code Parsing Errors Slow Code Inflexible Code Dead Code
- 12. W H A T C A U S E S T E C H N I C A L D E B T ?
- 13. A C C E P T A B L E D E B T : T E C H N I C A L L O A N
- 14. A C C E P T A B L E D E B T : P R O O F O F L I F E
- 15. U N A C C E P T A B L E D E B T : C A R E L E S S D E V E L O P E R S
- 16. U N A C C E P T A B L E D E B T : C A R E L E S S M A N A G E M E N T
- 17. T H E D E B T Q U A D R A N T
- 18. D E B T Q U A D R A N T @MartinFowler
- 19. D E B T Q U A D R A N T Reckless Prudent Inadvertent Deliberate 12 8 6 3 4 1 3 6 Technical Debt Accrued
- 20. P A U S E
- 21. N O P R O B L E M C A N B E S O L V E D B Y T H E S A M E K I N D O F T H I N K I N G T H A T C R E A T E D I T . A L B E R T E I N S T E I N , T H E O R Y O F S P E C I A L R E L A T I V I T Y .
- 22. I G N O R E D T E C H N I C A L D E B T I S A P R O B L E M
- 23. S L O W I N G D E V E L O P M E N T V E L O C I T Y
- 24. V E L O C I T Y 0 3 6 9 12 developer 1 developer 2 developer 3 developer 4 Technical Debt Feature Development Sprint Velocity: 44 (11 x 4) Debt Points: 11 Feature Points: 33
- 25. V E L O C I T Y 0 3 6 9 12 developer 1 developer 2 developer 3 developer 4 Technical Debt Feature Development Sprint Velocity: 44 (11 x 4) Debt Points: 25 Feature Points: 19
- 26. L A C K O F T E A M G R O W T H
- 27. B R O K E N W I N D O W S
- 29. B R O K E N W I N D O W S
- 30. D E V E L O P E R B U R N O U T
- 31. T E A M C O N F L I C T
- 32. I N T E R - D E P A R T M E N T C O N F L I C T
- 33. T U R N O V E R / A T T R I T I O N
- 34. L O C A T I N G T E C H N I C A L D E B T Strict Mode Logging IDE Code Quality Code Analysis Utilities Code Quality Gatekeepers Talk To Developers
- 35. S T R A T E G I E S F O R D E B T M A N A G E M E N T
- 36. R E B U I L D O R R E F A C T O R ?
- 37. R E F A C T O R I N G E F F E C T I V E L Y
- 38. R E B U I L D I N G S U C C E S S F U L L Y
- 39. I N C R E A S I N G V E L O C I T Y
- 40. C O N C L U S I O N
Editor's Notes
- Key Points: thank you for coming please ask me questions at the _end_ Let’s start
- Key Points: Joined Advanced 2 years ago started maintaining a legacy application Written in perl code bases change over time.
- Key Points perl is _old_ as efff Perl was first released in 1987
- Key Points: The top song in 1987 was “I wanna dance with somebody” by Whitney Houston
- Key Points: I wasn’t born until 1990. All this to say - perl has been around for a while.
- Key Points: legacy applications tend to breed technical debt Legacy applications show their age You can look at a code base and see the evidence of change and growth and expansion of features different code styles different design patterns team members have changed the application vision and purpose has evolved ultimately what I wanted to do was learn how to deal with technical debt
- Key Points: I wanted to help my team deal with technical debt Its not just old systems running on something like COBOL who have technical debt, many organizations have this problem some organizations may not acknowledge that they have it
- Key Points Defining the term and what it means is important You can’t begin to solve the problem unless you understand it change this to define debt first, then talk about cunningham.
- Key Points The debt metaphor was coined by this guy - Ward Cunningham It was intended to be a metaphor for explaining the process of code refactoring in the software development life cycle He was trying to communicate the need to go back and change code that was already written and working, but because the team had improved their knowledge and understanding of the problem, they could rewrite the code to better address the problem they needed to solve. the metaphor works well because it allows us to talk about other aspects of finance and compare them to software development.
- Key Points it’s important to have a proper mindset when talking about technical debt. Technical debt can be the result of many different factors. Remember Cunningham? He explains further that the debt metaphor can be taken further with the idea of something like a loan. You can have a loan within a software project implement a solution faster than normal understand that you’ll have to go back and change it later it might be worthwhile to do this to get a feature to users faster Big point: its because of these idiosyncrasies that technical debt is complex - and therefore requires an open mind to fully understand and resolve.
- Key points make these pop in Its easy to theorize about technical debt - let’s look at actual examples Duplicate code Duplicate code is code that simply is copy and pasted throughout the system to do the same thing everywhere. If you’re having to copy and paste functionality throughout your code base, you should be finding a way to implement that in a single place and have it inherited to other sections of your codebase. Inconsistent Coding Practices If your team has failed to settle on, and enforce a code style with an automated code style tool then you will incur a small amount of technical debt in the form of visual debt. Code Warnings / Errors Many programming languages have levels of strictness when compiling and parsing the language. These minor errors will result in error warnings. Poorly Performing Code I rarely have written a program that runs fast in its first iteration. Most programs a developer writes start out sloppy without consideration of memory usage, cpu cycles. The problem is when developer stop here, instead of refactoring the code once they have it working to try to be as performant as possible Non-Modularized Code Modularized code is not object oriented code. While object oriented code should be modularized, That may not always be the case. And, not all procedural style code is automatically awful bad code that can’t be modular. This is all about following good software development practices. Dead Code Dead code happens when code is added to your code base, but then is no longer needed or has been replaced. Instead of deleting it, the developer simply comments out large blocks of code and leaves it there. This code goes on to scrolled past and confuse future developers for years to come.
- When I talked about mindset I mentioned it was important to understand when you have technical debt, it’s not always necessarily always bad debt. Ultimately what this means is that most projects have an acceptable amount of technical debt.
- Key Points Debt should be viewed as a tool. Abuse is possible. Use to your benefit Cunningham uses the debt metaphor to explain how you can do things faster but it must be “paid back” before too much time goes by. Example: An example of this might be a company that is pushing a new software product to market to get ahead of competitors. Sometimes it’s more valuable from a business perspective to produce lower quality code so that the company can enter a market. This should always be done with buy in from the development team and management that this is a strategy, and that there is an understanding that this technical loan needs to be re-payed for the maintainability of the codebase. Do not engage in technical debt unless you are fully aware of what you are doing and accept the cost of paying back the loan.
- Key Points Technical debt is evidence of your team doing its job Dev Team Leaders: defend your team’s technical debt to upper management Not all debt is the result if bad technical decisions If a lot of debt is building up, it may be because the team is not being given enough information to make good decisions
- Key Points Organizations should accept that the first implementation of a feature may not be the best implementation Providing value to users faster is usually of more value than not releasing new features while most developers do not add technical debt to your project intentionally, if your organization is not seeking to enforce good quality, laziness and complacency can begin to occur it is never acceptable for developers to output poor code simply because they are lazy, or refuse to adopt best practices if the organization leadership hasn’t indicated that they want to take out a technical loan, the development team should not assume that they have permission to output less than excellent quality code leadership over development teams should always encourage, and enforce, where possible, adherence to best practices. This can be done with: code reviews code styles unit tests
- Key Points the development teams might be doing the best with what they have if you saw the development team intentionally delivering bad quality or being lazy, you’d probably be upset and start trying to replace those people management can do better provide better specifications ahead of time before asking for features make sure requests are well defined and thought out ensure that you ask for reasonable deliverables and trust your team ensure that you are following your development team’s chosen project management philosophy
- Key Points as I’ve shown there are examples of acceptable debt and unacceptable debt
- Key points new person we have to meet: martin fowler martin fowler is a well known author, developer, and project management guru something like a risk cost analysis quadrant
- Key points mentioned four categories technical debt “size” I mentioned those four categories of debt, acceptable and unacceptable, and then the reasons behind them. Things like acknowledging cutting corners for the sake of getting a product to market or a feature to users. Or maybe management is mistreating the development team. This graph shows the potential technical debt “size” that can be accrued in those different categories. We have lots of debt accumulated by reckless teams basically being ignorant to what they are doing. This is the worst type of debt because you don’t even know you have it. Then you have debt that comes by way of acknowledging you’re creating it, but you’re doing so on purpose for a good reason. Still going to be a fair amount of debt but at least you’re aware of it, so you should be taking care to pay it down. Good developers servicing a legacy system, proof of life type of technical debt. This is our prudent but reckless category. there’s still gonna be some debt here as the business grows, requirements change, there is turnover, or a change in vision.
- Key Points Let’s just pause for a second I want to see if I’m doing my job do we feel like we have a good understanding of the complexities of technical debt do we have any questions
- Key Points fill this in - why do we have this quote?
- Key points you must not ignore technical debt once you’ve been alerted to its existence imagine you’ve accumulated thousands of dollars in credit card debt then you simply ignore it for years and years Eventually bad things start to happen debt collectors calling bankruptcy, court proceedings, IRS problems etc.. it gets bad it can ruin your life technical debt has the power to ruin and destroy many lives. let’s look at the ways that ignored technical debt can start to have a negative impact on your organization
- Key Points Velocity just like physics Scrum is a project management methodology. velocity measures the amount of work that a team can deliver in a regular work cycle. the rate at which the team can execute tasks if there is a high level of technical debt is much lower scrum, agile, waterfall, kanban scrum out of scope. velocity is a scrum term
- Key points this demonstrates the velocity a team has achieved during a normal week the team has a total velocity of 44. Each team member executes 11 “work points” each. Some of those work points go to technical debt, some go to feature development this team is mostly healthy. some technical debt features > service debt continually adding value to the company mention some of the technical debt code categories like duplicate code
- Key points The work points devoted to technical debt service is much higher. mention some of the technical debt code categories like duplicate code - this is where the debt might be this team is unhealthy - they are having to spend more time working through technical debt in a regular sprint than deliver features.
- Key Points slowed professional development spending too much time maintaining, not able to learn locked into doing what they know no time for professional development every feature is a heavy lift the organization is not able to benefit from new knowledge the developers are unable to progress professionally
- Key Points Broken windows not talking about these broken windows
- Key Points lol
- Key Points introduced by scientists in 1980s James Q. Wilson and George L. Kelling theory that a building with a broken window attracted more crime applied to codebases, code left un-corrected can be looked at as a broken window developers become complacent, and lazy wide spread “crimes” will be committed throughout the codebase.
- Key Points Developers enjoy the “work” of programming Code with high levels of debt destroys passion and professional development Developers get tired, worn out dealing with spaghetti code all the time - loss of interest Search for new employment
- Key Points projects take longer which can add stresses to the team team members will lash out at each other blame game can be played results in sour work culture
- Key Points Departments will blame each other Bad requirements or specifications by the requesting department poor implementation by the development team lack of testing a breakdown in communication productivity
- Key Points ultimately employees will leave retraining employees is expensive institutional knowledge is highly valuable technical debt leaks and seeps into every aspect of the organization. it does not stay contained to just the software team. it affects everyone.
- key points make these icons pop in one at a time Code bases are _huge_ Open Source Joomla CMS for example has a codebase of around 370,000 lines of code The private-sourced project I work on daily has around 200,000 lines of code Locating anything in that can be challenging Here’s some tips on how to better locate code with debt. enable strict mode your parser can help you identify code that is written poorly log the extraneous errors to a log file inspect the data, fix areas that generate a lot of bugs all the time or clearly need updating code will perform better! use static code analysis tools you can inspect code for copy / pasted sections you can inspect code for code style consistency (spaces, tabs, line breaks, code comments) Use an IDE an IDE will give you a lot of code inspection tools at your finger tips as you are writing it it will help you be consistent if you’re using a supported language, it can help you locate existing functions to reduce writing new ones. Code Quality Gate Keepers You can force your developers to follow coding standards by ensuring nothing that is committed violates your coding standards Some gate keepers will incorporate static code analysis to help you better navigate code and resolve problem areas. you can use tools like SonarQube, Github, JenkinsCI for continuous integration / delivery pipelines that help run automated test and code style suites on code. Talk to your developers! chances are they know exactly where the the bad areas are at. ask them what they would change and why get time estimates and add these fixes to your sprint
- Key Points now that know how to identify the debt we can talk about removing it there’s a few different approaches we can go about.
- Key points: The first decision to make is: is your application even worth saving? Should you even spend the time refactoring code? Most of the time: yes It should be very rare that you would want to rewrite from scratch for now lets assume that you want to go down the refactor route - we can talk about rewriting in a minute.
- Key Points: Start small. Don’t try to fix all your warnings in one commit. Create new, blessed versions of the code. Unit test the heck out of it follow all those best practices If you have unit tests for the old version, compare the results! if the code is low risk, go ahead and launch it. if the code is high risk, add the new code adjacent to the old code. Continue using the old version, but log the results of each in a log file compare the results, make sure they keep returning the same values deprecate the old version once you’re confident its working
- Key Points: rewriting is hard. super hard you should avoid it. Most rewrites fail. you’ll probably fail if you don’t proceed with caution. reasons to take pause: you might just make the same mistakes the old code is battle tested you’ll invariably miss some feature someone needed it will take forever you don’t have the resources New applications today are tomorrow’s legacy applications. Learn how to maintain something rather than throwing away and starting over. If you must rewrite: Select an approach like the StranglerApplication This acts as a layer of a new application on top of old one route requests to the new one feature by feature. keep rewriting and making improvements until the old system is essentially phased out of use because you’ve replaced it all with new golden code.
- Key points consider removing? you can increase velocity by removing debt that is encumbering you you can increase velocity by adding more team members
- Key Points: we don’t have it all figure out yet technical debt is a lot like tending a garden, it requires continual maintenance and upkeep if you let it get out of hand its really hard to control