Ad
More Related Content
What's hot (20)
Similar to How To Manage And Reduce Development Techical Debt (20)
Ad
More from Abdul Khan (7)
Ad
Recently uploaded (20)
How To Manage And Reduce Development Techical Debt
- 1. How To Manage and Reduce Development Technical Debt By Abdul khan https://www.linkedin.com/in/abdul-khan-uk/
- 2. Author โข Abdul Khan โข IT Consultant based in Manchester, UK โข Engineering Lead, Executive, Technologist, Architect โข IT experience, within the private and public sectors (Retail, Banking, Digital, Insurance, M.O.D., HMRC, Aviation, Telecommunication, Housing Associations, Education, Travel, and Pharmaceutical companies). Excellent architectural and strong DevOps experience with proven-track record of delivering E2E, B2B and B2C solution on regional and global programs. โข SME in specializing in providing integration, data migration, digital transformations to the cloud solutions (Azure and AWS) โข Wealth of experience in global projects across EMEA, ASPAC and LATAM โข Liked in profile https://www.linkedin.com/in/abdul-khan-uk/
- 3. Accreditations Thank you to my brother, good friends and colleagues for reviewing, adding value, sharing their vast experience and knowledge. โข Samad Khan (IT Manager), specialising in enterprise solution in finance and wealth Management โข Steve Langton (IT Consultant, Cloud SME) specialising in NetOps, DevOps and SecOps โข Phil Eaton-Dykes (IT Consultant) 30+ years experience in enterprise solutions
- 4. Audience Main Audience โข Managers โข Product Owners โข Technical Managers โข Architects โข Technical Leads and Engineers
- 5. How to Manage and Reduce Development Technical Debt
- 6. Content 1. Presentation Objectives 2. Presentation Scope 3. What Is Development Tech Debt? 4. Development Technical Debt Taxonomy 5. Development Technical Debt Domains 6. Development Technical Debt Cycle 7. Managing Development Tech Debt 8. Development Tech Debt that effects your team 9. Development Tech Debt that damages business 10. Development Tech Debt that damages your business 11. Development Tech Debt that prevents business growth 12. What is Reckless Debt? 13. What Causes Development Tech Debt? 14. How to Reduce or Eliminate Development Technical Debt 15. 7 Sins of Managing Development Technical Debt 16. Management of Development Technical Debt 17. Other Tech Debt 18. Final Thoughts
- 7. 1. Presentation Objectives โข To understand what is Development technical debt โข How to manage Development technical debt
- 8. 2. Presentation Scope Overall IT Technical Debt Development Technical Debt Infrastructure Technical Debt =In scope of the current presentation Out of scope. This is covered the next Infrastructure Technical Debt presentation pack Complete Technical debt
- 9. 3. What Is Development Technical Debt? Development Technical debt is pretty much any code anyone wrote last week. Itโs all around us, binds us, and basically duct-tapes-and- glues the tech world together. Tech Debt is a part of life and, while we all want to ensure all our code is perfect and lasts the test of time, you will live with Tech Debt. Some Tech Debt needs to managed and reduced immediately, and some does not.
- 10. 4. Development Technical Debt Taxonomy Overall IT System Technical Debt Architecture Debt Document Debt Testing Debt Coding Debt Technological Gaps
- 11. 5. Development Technical Debt Domains Architecture Code Level Testing Documentation Technological Gap Business Goals and Objectives Use cases Diagram Processes Business Architecture (BA) Business Functions/Services Business Roles Business Data Model Functional Decomposition Business Data Model Data Management Process Model Data Interoperability Data Architecture (DA) Data Entity/Business Function Matrix Application Portfolio Catalogue Application/Organization Matrix Role/Application Matrix Application Architecture (AA) Application/Function Matrix Application Interaction Matrix Implementation Guidelines Implementation Specification Implementation Standards Interoperability requirements IT Service Management Requirements Technology Standards Catalogue Technology Platform and decomposition Environment and locations Technology Architecture (TA) Expected processing Load and Distribution Physical (network) communications Hardware and networks Specifications Application/Technology Matrix Technical Debt Domains Sub Types of Architectural Technical Debt (TD) Types TOGAF Deliverables Technical Debt (TD) Types`
- 12. 6. Development Technical Debt Cycle Which lead to โฆ Poor Practices โข Quality of Coding โข Design of application โข Infrastructure โข Poor practice (communication, review, documentation, handover) Frequent Incidents โข Application my break regular โข Time and tasks planned for projects instead spent on fixing incidents Touch & Go โข We donโt apply durable and robust solution as we are under pressure to fix and build more. โข Skills & training is limited โข Confidence is low โข Moving targets and priorities Which means we are increasingโฆ Low Recoveries โข High Levels of incidents / break/fix lead to high levels of BAU โข Meeting & email culture uses up a lot of time This will lead to โฆ More work required, hence additional work is required on incidentsโฆ
- 13. 7. Managing Development Technical Debt โข Define and understanding your business categories of development technical debt and how to linked to the business strategies. โข Development stack and tools should be mapped to long term IT road map, priorities id tools, languages, resources and software life-cycle is key. Its also important to consider managing Tech Debt e.g. what to address, what to ignore and for how long. โข While we donโt get everything right all the time, ensure that there is a deliverable product road map and keep a sustainable, pride worthy pace of innovation. As this could be a game-changing outcome of addressing the right tech debt at the right time that will drive and support business goals. โข Building features and addressing underlying platform/tools/quality needs are absolutely necessary requirements for any technical manager. But there is a lot more to see under the covers here. โข Construct a plan to Identifying, articulating and lobbying to remove these obstacles in time โข The results of development tech debt planning will clearly support the business growth and prompt confidence across the organization and, most importantly customer satisfaction.
- 14. 8. Development Technical Debt That Effects Teams Consider the following :- โข Does the team deliver on the roadmap on a good schedule? โข Are they all tired because they are all literally โworking all the timeโ? โข Do you have data to figure out why they are working all the time? โข Is it because the deadlines for new features are unreasonable? โข Or is it because the time/resource cost of supporting your existing service went up while you werenโt looking? โข These are the โsoftโ signs that this type of debt is at play and needs to be addressed before it graduates to the killing-your-business kind, they are: โข Incidents that had to be addressed in any given week โ this should be stable number โข Repeat incidents โ did the same thing happen last week? โข To manage technical debt it is important to gather hard data around the debt, diligently conduct retrospectives after every critical issue in production, identify what went wrong and break it down into bite-size chunks that you can address along with the rest of the sprint work. โข For some short period of time, you may have slower progress on the feature roadmap, but progress should not stop and the delay should still be within reasonable schedule variance. Addressing this type of tech debt will yield value immediately and will set up future success.
- 15. 9. Development Technical Debt That Effects Businesses โYour current solution could be great while the business was small but in the current climate the solution canโt handle the load or itโs just not isnโt fast enoughโ this is serious tech debt problem. โข New systems can benefit and grow businesses, also learn from mistakes and build tech that essentially stack. This is the easiest type of debt to prioritize, but usually the hardest to resolve. โข Something that has been around for years and if it was easy to address you would likely have addressed it already. Resolving this type of tech debt will require you to sacrifice significant portions of your product roadmap. So, while this one might be the easiest to build up, as a tech leader who wants to make money, you want to take steps in advance to avoid this kind of technical debt like the plague. โข As you build new features, you should not forget what is wrong with the older features you are carrying around. Pay attention to the things that are holding you down. As an example, for us at Conductor, our old Monolithic application was built in Java 6, and the intricate web of dependencies that evolved over time made it a drag for us to upgrade, address scale issues, improve performance, etc. We are explicitly applying the strangler pattern to all new development, with the ruling mantra of being able to independently build/deploy/test/scale anything new we build. Hard-earned learnings from the past will explicitly be part of our success in the future.
- 16. 10. Development Technical Debt That Damages Businesses โข Some tech debt can be a blocker for growth for your business. Your product may be working fine right now but the future needs of the business may qualify some portions of your solution as debt. This debt is only debt if you foresee it blocking your growth in the future. That future tech debt might be portions of features that were never implemented because no one got around to it for whatever reason. Over time, that not-yet-implemented functionality can became a sinkhole that many things might fall into. Some examples: โข A new feature got added many years ago for the domestic market, but there wasnโt high demand to make it available in the international market, so it never got added there. Over time, this gulf just grew to be so large that it started to affect business. In addition, the cost of addressing it became exponentially larger. โข An ETL pipeline that gets kicked off on a schedule works really well until you change the time zones and address customers who are awake when you are asleep or vice versa. Since the time zones were not something you had to think about before, going back and addressing this now can be costly or based on a new implementation. โข Hardcoded content and values โข Not all of this debt needs a technical solution, and it can be a discussion between multiple departments Do a lot of due diligence and ensure you absolutely have to have a technical solution. If you need it, build it into the roadmap.
- 17. 11. Development Technical Debt That Prevents Business Growth โข This type of debt is the hardest to make a great business case for. Itโs the type of debt that I believe tech leaders struggle with the most, and for good reason. This is the kind of debt that results from thinking, โif we just had a standard platform/api/pattern, we would be able to move so much faster.โ โข The technologist in all of us wants to build a platform that is sufficient and robust and scales for all the features that are built using it. This is an eternal struggle and the benefits of adding another layer of robustness to this platform is never a clean cut decision. It is always partly supported by empirical data and partly by extrapolation. This is the type of debt that is hardest to quantify because it isnโt really killing your business now, it isnโt killing your team, and it isnโt going to kill your business next year. As a leader, this is what you spend your political capital on. โข Calculate the opportunity cost and doing a SWOT analysis, the future benefit of addressing this debt now is greater than the future of adding another feature or fixing more bugs. โข Build a plan and start executing on addressing the issues. The lack of flexibility in this configuration will significantly limit our ability to innovate next year in feature areas that are already in early discussions in the Product team, with the industry leaders and with our expert users.
- 18. 12. What Is Reckless Debt? โReckless Debt is code that violates design principles and good practices.โ In short this means, that all code generated by us and our team is junk (not done on purpose of course). Moreover, Reckless Debt will lead to Technical Debt in the short/mid term and it is also a signal that your team needs more training, or you have too many inexperienced or junior developers.
- 19. 13. What Causes Development Technical Debt? โข Poor Conception: โข When developing an application, the speed at which the team or the company delivers the product can make a real difference, after all, an application or software is developed to answer a particular problem or to address a specific challenge in a timely manner. The rush in delivering faster often results in poorly designed software, not well thought out, and development is mainly focusing on developing the functionalities. โข Poor Scheduling: โข Underestimating during the software development estimation process often causes technical debt. A development team's focus is on the respect of time estimates and is accumulating lots of bad practices that they will ultimately have to pay. โข Bad Development Practices: โข It is crucial that the development team has a set of practices and conventions so that there is a little or no significant difference in design and implementation from feature to feature. A lack of development good practices and conventions will lead developers to implement their design, rebuild the same logic over and over, and format their code the way they want rather than the way it is commonly accepted in the particular software project. โข Outdated Technology: โข As technology evolves, software standards become higher every day. With each improvement, new technical debt can arise.
- 20. 14. How to Reduce or Eliminate Development Technical Debt โข The Quickest to Solve: โข Fixing debts that take little time to fix is an excellent way to eliminate technical debt gradually. Debts like code formatting can be solved in a little time, making up a template and apply these templates to all the codes that have been developed so far, then integrate these templates in the tools used by the developers. โข Priority: โข It is also important to address issues by priority. All issues that can lead to more significant issues should be addressed quickly and should be prioritized to avoid accumulation. โข Technology Update: โข When outdated technology leads to technical debt, it is important to update the software to the newest versions of the frameworks, application servers, databases etc. It is even important to include every stable evolution of a framework used for instance to always have the latest update and to bring small change without breaking the software. โข Refactoring: โข Reviewing the software architecture and refactoring codes often can be useful when we don't want to end up with duplicate code or codes that lack modularity.
- 21. 15. 7 Sins Of Developments Technical Debt (Donโt) Reinvent the wheel Unit Tests Acceptance Tests 7. Pride Software Metrics Documentation Not Using Version Control No Features Required Contributions To Open Source Projects 6. Envy Input Validation Duplications Code Standards 4. Sloth Lazy Coding Self-Development Configuration โOut-Of-The-Boxโ Over-engineering Refactoring โSpaghetti Codeโ 2. Gluttony Feature-rich Inefficiency Over-engineering Design Patterns Abstraction 1. Lust A vehement denial of the truth Documentation Coding Standards 5. Wrath Unit Tests Commit Messages Rushing To Production Computing across teams Donโt Reinvent the wheel Power Struggle 3. Greed
- 22. 16. Management Of Development Technical Debt Quality Management Plan Plan Quality Perform Quality Assurance Perform Quality Control Testing DebtCoding Debt Quality Management Plan Quality Metrics Quality Control Measurements Quality Check List Work Performance Information Deliverables Approved Changes Requests Changes Requests Controlling quality involves monitoring specific results to determine whether they comply with the planned quality standards, which include project processes and product goals, and controlling the results by taking actions to eliminate unsatisfactory performance
- 23. 17. Managing Other Technical Debt โข Everything else shouldnโt affect your roadmap commitments. That doesnโt mean you shouldnโt pick up small/medium things to pick up and address as they arise, but it shouldnโt affect your committed deliverables and product roadmap. If the debt is important enough, it will reveal itself in time. There is no magic formula to apply here. You have to let time be your guide and analyse all new pieces of information and apply intuition. โข Be critical and get comfortable with some debt: it will always be with you in some form. Every once in a while you will get a surprise present from an engineer because they just couldnโt take it anymore and fixed something that you didnโt ask for but is the right thing to do. โข Building software is an interesting and satisfying mix of art and science. Therefore, deciding which tech debt to address will have major impacts on any business. The above rules of thumb have been a huge contributing factor in building happy, productive, profitable tech teams for the past few decades.
- 24. 18. Final Thoughts Having technical debt at some point of the software development process is quite usual. However, managing technical debt is important to avoid their accumulation over time. This will require the business to accept a certain amount of technical debt, but ultimately there should be kept at an acceptable level at which they don't harm the performance and the overall experience of the software product users. Contrary to the estimation of development time, the estimation of technical debt is based on existing code that often evolves. It is then necessary to have a good approach to estimate the technical debt included in the software developed. Due to the ever-shifting nature of the code and the volume of codes to be evaluated, it is not possible to perform a manual estimation. It is then necessary to work with the right tools that allow an automatic computation of technical debt estimates. Although addressing technical debt can cost money, leaving technical debts in software will cost more money in the future.
- 25. - END OF DECK By Abdul Khan โ https://www.linkedin.com/in/abdul-khan-uk/