The technical debt metaphor is useful in capturing the long-term impacts of
tradeoffs taken during software maintenance between productivity (getting
something done sooner) and maintainability (degradation of the code's
quality over time). This webinar on Technical Debt will present
techniques and insights that help software engineers to identify and track
technical debt in their projects. We will outline how business and product
quality goals should affect the choice of approaches (and combinations of
approaches) for managing technical debt. More specifically, we will discuss
a set of automated approaches based on static code analysis that are likely
to spot problems in source code that have real impact on productivity and
defect proneness. Based on previous empirical studies, we will give further
advice on which types of debt can be found by these tools, and which types
are not yet detectable.
Introduction to Enterprise architecture and the steps to perform an Enterpris...Prashanth Panduranga
This presentation was used to introduce Enterprise Architecture, Introduction to how to perform an Enterprise Architecture Assessment followed by TechSharp introduction.
Deliverables in the presentation is not clear, the slides represent what was shown as part of the demo.
List of deliverables:
Application Rationalization framework
Portfolio Analysis framework
Road Map
Current state analysis
Target State establishing process
System Context
System Landscape
The TOGAF® Architecture Development Method recommends that "an architecture description be encoded in a standard language". As the Open Group standard for enterprise modeling, Archimate is a strong candidate for this role. This presentation will explore how a diversified financial services company selected and is using Archimate for its TOGAF® implementation. The speaker will compare available enterprise modeling languages and explain why Archimate was selected, and will explain how his organization developed an enabling metamodel and diagram templates using a leading enterprise modeling tool. Methodology transition will also be covered, including how existing diagram types were mapped to TOGAF®, and how TOGAF® diagram content was mapped to Archimate.
Delivered at February 2011 Open Group San Diego Conference
Presentation given by Fadi Stephan from Kaizenko at AgileDC2018 on 10/15/2018 in Washington DC. Also see blog series on Managing Technical Debt at https://www.kaizenko.com/managing-technical-debt/
Is your team constantly missing delivery dates? Is the velocity decreasing from sprint to sprint while the development costs are rising? Are customers complaining about the increasing number of bugs and the long time it takes to add new features? These are all signs that you are mired in technical debt and probably on your way to bankruptcy or a complete system rewrite. Technical debt is inevitable, whether intentional or unintentional. However, not managing technical debt can paralyze your organization. Fadi Stephan expands on the technical debt metaphor and introduces a technical debt management plan that enables executives and teams to make prudent decisions on code quality and technical debt. Come learn how to measure the quality of your code base and determine the amount of your debt.
It is well known that an effective PMO is key to successful and efficient program and project execution. In other words, doing things “right”. Enterprise Architecture is the discipline that plans and monitors enterprise transformation and aligns the business strategy with information technology capabilities. In other words, doing the “right things” to support the business.
Why is it organizations despite having both of these disciplines still struggle with effective enterprise transformation? What can we done to use these disciplines more effectively to effect better business outcomes? What are the roles of each discipline and how do they work together to create business value?
In this presentation, Riaz will address these questions and will provide real life examples that can help build a strong relationship between the PMO and Enterprise Architecture.
Learning Objectives:
• How to build a strong relationship between the PMO and Enterprise Architecture (EA) to deliver positive outcomes for your organization
• Identify the different roles and functions of the PMO and EA as well as their similarities
Defining the business value proposition of EA and PPM
Eliminating project risks
Accelerating project execution
Managing project and architecture inter-dependencies
Delivering realized value
Improving collaboration of Architecture and PMO
Introduction to Enterprise architecture and the steps to perform an Enterpris...Prashanth Panduranga
This presentation was used to introduce Enterprise Architecture, Introduction to how to perform an Enterprise Architecture Assessment followed by TechSharp introduction.
Deliverables in the presentation is not clear, the slides represent what was shown as part of the demo.
List of deliverables:
Application Rationalization framework
Portfolio Analysis framework
Road Map
Current state analysis
Target State establishing process
System Context
System Landscape
The TOGAF® Architecture Development Method recommends that "an architecture description be encoded in a standard language". As the Open Group standard for enterprise modeling, Archimate is a strong candidate for this role. This presentation will explore how a diversified financial services company selected and is using Archimate for its TOGAF® implementation. The speaker will compare available enterprise modeling languages and explain why Archimate was selected, and will explain how his organization developed an enabling metamodel and diagram templates using a leading enterprise modeling tool. Methodology transition will also be covered, including how existing diagram types were mapped to TOGAF®, and how TOGAF® diagram content was mapped to Archimate.
Delivered at February 2011 Open Group San Diego Conference
Presentation given by Fadi Stephan from Kaizenko at AgileDC2018 on 10/15/2018 in Washington DC. Also see blog series on Managing Technical Debt at https://www.kaizenko.com/managing-technical-debt/
Is your team constantly missing delivery dates? Is the velocity decreasing from sprint to sprint while the development costs are rising? Are customers complaining about the increasing number of bugs and the long time it takes to add new features? These are all signs that you are mired in technical debt and probably on your way to bankruptcy or a complete system rewrite. Technical debt is inevitable, whether intentional or unintentional. However, not managing technical debt can paralyze your organization. Fadi Stephan expands on the technical debt metaphor and introduces a technical debt management plan that enables executives and teams to make prudent decisions on code quality and technical debt. Come learn how to measure the quality of your code base and determine the amount of your debt.
It is well known that an effective PMO is key to successful and efficient program and project execution. In other words, doing things “right”. Enterprise Architecture is the discipline that plans and monitors enterprise transformation and aligns the business strategy with information technology capabilities. In other words, doing the “right things” to support the business.
Why is it organizations despite having both of these disciplines still struggle with effective enterprise transformation? What can we done to use these disciplines more effectively to effect better business outcomes? What are the roles of each discipline and how do they work together to create business value?
In this presentation, Riaz will address these questions and will provide real life examples that can help build a strong relationship between the PMO and Enterprise Architecture.
Learning Objectives:
• How to build a strong relationship between the PMO and Enterprise Architecture (EA) to deliver positive outcomes for your organization
• Identify the different roles and functions of the PMO and EA as well as their similarities
Defining the business value proposition of EA and PPM
Eliminating project risks
Accelerating project execution
Managing project and architecture inter-dependencies
Delivering realized value
Improving collaboration of Architecture and PMO
Next Generation IT Delivery - What it means to deliver atthe speed of the Dig...Mirco Hering
We live in the Digital Age and IT delivery needs to get faster and faster...I presented this point of view at the Accenture Test Symposium in Australia in 2015.
IT Architecture’s Role In Solving Technical Debt.pdfAlan McSweeney
Technical debt is an overworked term without an effective and common agreed understanding of what exactly it is, what causes it, what are its consequences, how to assess it and what to do about it.
Technical debt is the sum of additional direct and indirect implementation and operational costs incurred and risks and vulnerabilities created because of sub-optimal solution design and delivery decisions.
Technical debt is the sum of all the consequences of all the circumventions, budget reduction, time pressure, lack of knowledge, manual workarounds, short-cuts, avoidance, poor design and delivery quality and decisions to remove elements from solution scope and failure to provide foundational and backbone solution infrastructure.
Technical debt leads to a negative feedback cycle with short solution lifespan, earlier solution replacement and short-term tactical remedial actions.
All the disciplines within IT architecture have a role to play in promoting an understanding of and in the identification of how to resolve technical debt. IT architecture can provide the leadership in both remediating existing technical debt and preventing future debt.
Failing to take a complete view of the technical debt within the organisation means problems and risks remained unrecognised and unaddressed. The real scope of the problem is substantially underestimated. Technical debt is always much more than poorly written software.
Technical debt can introduce security risks and vulnerabilities into the organisation’s solution landscape. Failure to address technical debt leaves exploitable security risks and vulnerabilities in place.
Shadow IT or ghost IT is a largely unrecognised source of technical debt including security risks and vulnerabilities. Shadow IT is the consequence of a set of reactions by business functions to an actual or perceived inability or unwillingness of the IT function to respond to business needs for IT solutions. Shadow IT is frequently needed to make up for gaps in core business solutions, supplementing incomplete solutions and providing omitted functionality.
Value analysis with Value Stream and Capability modelingCOMPETENSIS
The new Archimate 3.1 has improved the strategy layer with major modeling objects related to value analysis: value stream and capability.
These objects are linked and answer major questions :
- [VALUE STREAM] What value do we deliver to customers ? What value do we want to deliver to customers ? This is the enterprise business model.
- [CAPABILITY] What operational model do we need to deliver value ? The capability model describes the operational model required to deliver value to customers.
You cannot succeed to transform a business model, enterprise activities without considering Value Stream & Capability analysis. Technology considerations are necessary but not sufficient.
Feel free to contact if you wish to get more support with your transformation projet.
Copy and paste to access the full recording: http://www.castsoftware.com/news-events/event/gartner-technical-debt?gad=ss
-------------------------------------------------------
In this webinar David Norton of Gartner Research discusses recent findings on Technical Debt that estimates industry IT debt is at $500 billion—and on target to reach $1 trillion by 2015. He also talks about the importance of Software Analysis & Measurement to manage Technical Debt, how to measure debt continuously to control TCO of the application lifecycle and include debt measurement in project management and prioritization.
Meetup #1 low-code, Pourquoi ? Pour qui ? Comment ? Rencontrons-nous !Simplicité Software
Diaporama de présentation du premier Meetup Low-code Paris.
Vous avez envie de discuter du low-code ? Vous avez des idées ? Des questions sans réponses ? Votre curiosité vous anime ?
Découvrez le panorama des plateformes low-code, les différentes utilisations possibles, des exemples concrets d'applications et le témoignage d'un client DSI.
Managing the the Technical Debt lifecycle. In this presentation we explore the evolution of the metaphor, the value it brings to organizations and challenges to successful adoption.
The full audio and video can be viewed at http://blog.acrowire.com/td-webinar.
MSP Best Practice | Using Strategic IT Roadmaps to Get More ContractsDavid Castro
MSP best practices. How to use strategic IT roadmaps to win more business and get larger managed services contracts. Presented by Kaseya and Ant Farm. May 2012.
“TODAY, COMPANIES ACROSS ALL INDUSTRIES ARE BECOMING SOFTWARE COMPANIES.”
The familiar refrain is certainly true of the new-school, born-in-the-cloud set. But it can also apply to traditional enterprises that are reinventing themselves by coupling DevOps excellence with intelligent DataOps.
Smooth your path to successful IT budgeting with Absoft's Technical Roadmap Service. http://www.absoft.co.uk/content/roadmap-for-successful-it-budgeting
Keynote: Testing and Quality in the Scaled Agile Framework for Lean Enterpris...Derk-Jan de Grood
Scaled Agile Framework for Lean Enterprises (SAFe) is the most popular framework used by large programs and companies to achieve business agility. It challenges how testers, Q&A and test managers, and test specialists work together with the entire organisation. Derk-Jan de Grood and Mette Bruhn-Pedersen explain how test professionals can contribute with their knowledge and expertise in a SAFe organisation.
Scaled Agile Framework for Lean Enterprises (SAFe) is becoming the most popular framework used to help large programs and entire companies achieve business agility. It builds on well-known agile-lean principles and methodologies, and puts them together to address challenges not only on team level, but also on program, large solution and portfolio level. Although the framework is described in more details than other comparable frameworks it is not very elaborate on how testing and quality practices fit in. This raises new challenges for testers, Q&A and test managers, test architects, test specialists and people in similar roles together with the entire organisation. Derk-Jan de Grood and Mette Bruhn-Pedersen describe what guidance SAFe actually provides and suggest additional ways test and QA professionals can contribute with their special knowledge and expertise.
The presentation is based on the authors’ experience and an expert session at the 22nd Testing Retreat (2017, Hereford UK). The Testing Retreat is a peer-conference where leaders in the testing and quality profession share their experiences and insights. The participants discussed quality measures and actions that test professionals can take to ensure quality when using SAFe throughout the Software Development Lifecycle (SDLC). We thank all for their valuable contributions.
Incorporating A DesignOps Approach Into Solution ArchitectureAlan McSweeney
Solution architecture and design is concerned with designing new (IT) solutions to resolve problems or address opportunities . In order to solve a problem, you need sufficient information to understand the problem. If you do not understand the scope of the required solution you cannot understand the risks associated with the implementation approach.
Getting the solution wrong can be very expensive. The DesignOps approach is a unified end-to-end view of solution delivery from initial concept to steady state operations. It is a design-to-operations approach identifying all the solution design elements needed to ensure the delivery of a complete solution.
Solution architecture and design teams are becoming larger so more co-ordination, standardisation and management is required. The increasing focus on digital transformation increases the need for improved design as business applications are exposed outside the organisation. Solution complexity is increasing. The aim of the DesignOps approach is to improve solution design outcomes.
Brief, but descriptive tutorial of the Scaled Agile Framework (SAFe) 4.5. Starts with impetus for agility, overview of lean and agile thinking, definition of portfolio management, explanation of SAFe and its values and principles, etc. Then, provides a level-by-level overview of SAFe, including case studies, metrics, business case, adoption statistics, roles, responsibilities, and other considerations. Closes with a nice summary of key SAFe implementation principles ...
Structured Approach to Solution ArchitectureAlan McSweeney
The role of solution architecture is to identify answer to a business problem and set of solution options and their components. There will be many potential solutions to a problem with varying degrees of suitability to the underlying business need. Solution options are derived from a combination of Solution Architecture Dimensions/Views which describe characteristics, features, qualities, requirements and Solution Design Factors, Limitations And Boundaries which delineate limitations. Use of structured approach can assist with solution design to create consistency. The TOGAF approach to enterprise architecture can be adapted to perform some of the analysis and design for elements of Solution Architecture Dimensions/Views.
Next Generation IT Delivery - What it means to deliver atthe speed of the Dig...Mirco Hering
We live in the Digital Age and IT delivery needs to get faster and faster...I presented this point of view at the Accenture Test Symposium in Australia in 2015.
IT Architecture’s Role In Solving Technical Debt.pdfAlan McSweeney
Technical debt is an overworked term without an effective and common agreed understanding of what exactly it is, what causes it, what are its consequences, how to assess it and what to do about it.
Technical debt is the sum of additional direct and indirect implementation and operational costs incurred and risks and vulnerabilities created because of sub-optimal solution design and delivery decisions.
Technical debt is the sum of all the consequences of all the circumventions, budget reduction, time pressure, lack of knowledge, manual workarounds, short-cuts, avoidance, poor design and delivery quality and decisions to remove elements from solution scope and failure to provide foundational and backbone solution infrastructure.
Technical debt leads to a negative feedback cycle with short solution lifespan, earlier solution replacement and short-term tactical remedial actions.
All the disciplines within IT architecture have a role to play in promoting an understanding of and in the identification of how to resolve technical debt. IT architecture can provide the leadership in both remediating existing technical debt and preventing future debt.
Failing to take a complete view of the technical debt within the organisation means problems and risks remained unrecognised and unaddressed. The real scope of the problem is substantially underestimated. Technical debt is always much more than poorly written software.
Technical debt can introduce security risks and vulnerabilities into the organisation’s solution landscape. Failure to address technical debt leaves exploitable security risks and vulnerabilities in place.
Shadow IT or ghost IT is a largely unrecognised source of technical debt including security risks and vulnerabilities. Shadow IT is the consequence of a set of reactions by business functions to an actual or perceived inability or unwillingness of the IT function to respond to business needs for IT solutions. Shadow IT is frequently needed to make up for gaps in core business solutions, supplementing incomplete solutions and providing omitted functionality.
Value analysis with Value Stream and Capability modelingCOMPETENSIS
The new Archimate 3.1 has improved the strategy layer with major modeling objects related to value analysis: value stream and capability.
These objects are linked and answer major questions :
- [VALUE STREAM] What value do we deliver to customers ? What value do we want to deliver to customers ? This is the enterprise business model.
- [CAPABILITY] What operational model do we need to deliver value ? The capability model describes the operational model required to deliver value to customers.
You cannot succeed to transform a business model, enterprise activities without considering Value Stream & Capability analysis. Technology considerations are necessary but not sufficient.
Feel free to contact if you wish to get more support with your transformation projet.
Copy and paste to access the full recording: http://www.castsoftware.com/news-events/event/gartner-technical-debt?gad=ss
-------------------------------------------------------
In this webinar David Norton of Gartner Research discusses recent findings on Technical Debt that estimates industry IT debt is at $500 billion—and on target to reach $1 trillion by 2015. He also talks about the importance of Software Analysis & Measurement to manage Technical Debt, how to measure debt continuously to control TCO of the application lifecycle and include debt measurement in project management and prioritization.
Meetup #1 low-code, Pourquoi ? Pour qui ? Comment ? Rencontrons-nous !Simplicité Software
Diaporama de présentation du premier Meetup Low-code Paris.
Vous avez envie de discuter du low-code ? Vous avez des idées ? Des questions sans réponses ? Votre curiosité vous anime ?
Découvrez le panorama des plateformes low-code, les différentes utilisations possibles, des exemples concrets d'applications et le témoignage d'un client DSI.
Managing the the Technical Debt lifecycle. In this presentation we explore the evolution of the metaphor, the value it brings to organizations and challenges to successful adoption.
The full audio and video can be viewed at http://blog.acrowire.com/td-webinar.
MSP Best Practice | Using Strategic IT Roadmaps to Get More ContractsDavid Castro
MSP best practices. How to use strategic IT roadmaps to win more business and get larger managed services contracts. Presented by Kaseya and Ant Farm. May 2012.
“TODAY, COMPANIES ACROSS ALL INDUSTRIES ARE BECOMING SOFTWARE COMPANIES.”
The familiar refrain is certainly true of the new-school, born-in-the-cloud set. But it can also apply to traditional enterprises that are reinventing themselves by coupling DevOps excellence with intelligent DataOps.
Smooth your path to successful IT budgeting with Absoft's Technical Roadmap Service. http://www.absoft.co.uk/content/roadmap-for-successful-it-budgeting
Keynote: Testing and Quality in the Scaled Agile Framework for Lean Enterpris...Derk-Jan de Grood
Scaled Agile Framework for Lean Enterprises (SAFe) is the most popular framework used by large programs and companies to achieve business agility. It challenges how testers, Q&A and test managers, and test specialists work together with the entire organisation. Derk-Jan de Grood and Mette Bruhn-Pedersen explain how test professionals can contribute with their knowledge and expertise in a SAFe organisation.
Scaled Agile Framework for Lean Enterprises (SAFe) is becoming the most popular framework used to help large programs and entire companies achieve business agility. It builds on well-known agile-lean principles and methodologies, and puts them together to address challenges not only on team level, but also on program, large solution and portfolio level. Although the framework is described in more details than other comparable frameworks it is not very elaborate on how testing and quality practices fit in. This raises new challenges for testers, Q&A and test managers, test architects, test specialists and people in similar roles together with the entire organisation. Derk-Jan de Grood and Mette Bruhn-Pedersen describe what guidance SAFe actually provides and suggest additional ways test and QA professionals can contribute with their special knowledge and expertise.
The presentation is based on the authors’ experience and an expert session at the 22nd Testing Retreat (2017, Hereford UK). The Testing Retreat is a peer-conference where leaders in the testing and quality profession share their experiences and insights. The participants discussed quality measures and actions that test professionals can take to ensure quality when using SAFe throughout the Software Development Lifecycle (SDLC). We thank all for their valuable contributions.
Incorporating A DesignOps Approach Into Solution ArchitectureAlan McSweeney
Solution architecture and design is concerned with designing new (IT) solutions to resolve problems or address opportunities . In order to solve a problem, you need sufficient information to understand the problem. If you do not understand the scope of the required solution you cannot understand the risks associated with the implementation approach.
Getting the solution wrong can be very expensive. The DesignOps approach is a unified end-to-end view of solution delivery from initial concept to steady state operations. It is a design-to-operations approach identifying all the solution design elements needed to ensure the delivery of a complete solution.
Solution architecture and design teams are becoming larger so more co-ordination, standardisation and management is required. The increasing focus on digital transformation increases the need for improved design as business applications are exposed outside the organisation. Solution complexity is increasing. The aim of the DesignOps approach is to improve solution design outcomes.
Brief, but descriptive tutorial of the Scaled Agile Framework (SAFe) 4.5. Starts with impetus for agility, overview of lean and agile thinking, definition of portfolio management, explanation of SAFe and its values and principles, etc. Then, provides a level-by-level overview of SAFe, including case studies, metrics, business case, adoption statistics, roles, responsibilities, and other considerations. Closes with a nice summary of key SAFe implementation principles ...
Structured Approach to Solution ArchitectureAlan McSweeney
The role of solution architecture is to identify answer to a business problem and set of solution options and their components. There will be many potential solutions to a problem with varying degrees of suitability to the underlying business need. Solution options are derived from a combination of Solution Architecture Dimensions/Views which describe characteristics, features, qualities, requirements and Solution Design Factors, Limitations And Boundaries which delineate limitations. Use of structured approach can assist with solution design to create consistency. The TOGAF approach to enterprise architecture can be adapted to perform some of the analysis and design for elements of Solution Architecture Dimensions/Views.
How Software Developers Destroy Business Value.pptxAaron Stannard
Software developers are intended to be massive, highly leverageable value creators for their companies and teams - using their creative and technical talent to build products themselves or mission-critical systems that facilitate the delivery of value inside the business. The blunt truth, however, is that many software developers would screw up tying their own shoes when left to their own devices. There's an abundant corpus of work out there on how managers routinely let down their software developers through insufficient planning, communication, listening, and support. In this talk we're going to explore the inverse - how individual software developers contributing to a project unintentionally sabotage their teams, their companies, their projects, and themselves through: * Immutable technical preferences + biases; * Bad attitudes; * Poor listening; * Inflexible and unproductive learning styles; * Risk aversion; * Incuriosity; * And more! Most importantly, in this talk we're going to try to address how we can help shift developers who want to learn and improve, but are have trouble executing, become the high value contributors they'd like to be.
DEVOPS & THE DEATH AND REBIRTH OF CHILDHOOD INNOCENCEDrupalCamp Kyiv
Remember when the internet was pure and unspoiled? In our innocence we saw the promise of renewal of the world through connecting, sharing, and creating online. We became developers and hackers because we wanted to understand how things work, to take them apart, and build quirky (and sometimes useful) things just for the pleasure of it.
In the earliest decades of the Internet Epoch the Internet was a playground. We happily coded directly on production systems. And it was fine, as many Great Things were created. But the Internet has matured, and has now become Big Business. Developers have matured too, and good thing they did! So many people now rely on what we’ve built, for security, for privacy, for the paycheck at the end of the month. We matter.
Maturity has come at a price though, and deploying well tested code into complex applications with polyglot teams working with heterogeneous stacks, all while maintaining compliance with GDPR, HIPAA, PCI, etc. has taken all of the childhood innocence out of the web. Now even the simplest website seems like Hard Work.
In this talk I will show how we can, and should, regain our joyful demeanor, how we can use the maturity of the most innovative tools around us to start hacking like crazy again. Without regressing on agility, testing, compliance, scalability or robustness. I use the metaphor of childhood innocence to explain how the complexity of modern cloud computing, in combination with increasing quality expectations and compliancy, has curtailed the creative freedom of developers, and as a whole, organisational motivation.
Together with a lack of resources and idea time, this leads to lower and slower product innovation. We are, however, at the brink of a paradigm shift in cloud computing that will give developers and hackers their mojo again. This talk will zoom into the key elements of this paradigm shift, and provide an overview of the basic concepts and operational practices of the new age of developer innocence.
https://drupalcampkyiv.org/node/81
Recent widely covered database crashes in the retail industry, struck a damaging blow to the reputation of a number of major chain stores and online retailers.
This talk, given at the VA Smalltalk Forum Europe 2010 in Stuttgart, gives an overview of techniques and tools to get existing Smalltalk projects back to speed and productivity.
The talk included some demos of tools we created for some of our customers to make their project life much easier.
Technical Debt is usually referred to as something Bad. Most articles and books on the subject are about how to get rid of technical debt. But is debt always bad? When can it be good?
In this session we will see how to use technical debt as tool, and distinguish between good and bad debt. We will discuss about several types of technical debt we can have in our code, what are the acceptable levels of debt and ways to handle it effectively without having to pay a lot of interest.
business model, business model canvas, mission model, mission model canvas, customer development, hacking for defense, H4D, lean launchpad, lean startup, stanford, startup, steve blank, pete newell, bmnt, entrepreneurship, I-Corps, Security, NSIN, NSA, cybersecurity, Joe Felter
Similar to Identifying and Managing Technical Debt (20)
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
1. Identifying and Managing
Technical Debt
Dr. Nico Zazworka
Fraunhofer Center for
Experimental Software Engineering
Dr. Carolyn Seaman
University of Maryland
Baltimore County
http://www.technicaldebt.umbc.edu/
2. Outline
• Introduction to the Technical Debt metaphor
• Definition and examples of everyday debt
• Benefits of explicitly managing Technical Debt
• Technical Debt Framework
• Technical Debt properties: principal vs. interest
• Recording and communicating Technical Debt
• Identifying important Technical Debt
• Design debt: Code smells, Grime, ASA issues, Modularity
violations
• Other types of Technical Debt
• Management strategies to pay down Technical Debt 2
• Outlook
3. Software Maintenance
• Large inventory of operational systems that need to be
maintained
• Fixed
• Enhanced
• Adapted
• Such systems need constant modification in order to
remain useful
• Most such systems are too expensive to replace, so
considerable resources go into their maintenance
• However, maintenance, even more than development, is
characterized by tight budget and time constraints 3
5. Technical Debt
• Technical Debt is the gap between:
• Making a change perfectly
• Preserving architectural design
• Employing good programming practices
and standards
• Updating the documentation
• Testing thoroughly
5
6. Technical Debt
• Technical Debt is the gap between:
• And making the change work
• As quickly as possible
• With as few resources as possible
6
9. Everyday Indicators of Technical Debt
“Don’t worry about the documentation for now.”
“The only one who can change this code is Carl”
9
10. Everyday Indicators of Technical Debt
“Don’t worry about the documentation for now.”
“The only one who can change this code is Carl”
“It’s ok for now but we’ll refactor it later!”
10
11. Everyday Indicators of Technical Debt
“Don’t worry about the documentation for now.”
“The only one who can change this code is Carl”
“It’s ok for now but we’ll refactor it later!”
“ToDo/FixMe: this should be fixed before release”
11
12. Everyday Indicators of Technical Debt
“Don’t worry about the documentation for now.”
“The only one who can change this code is Carl”
“It’s ok for now but we’ll refactor it later!”
“ToDo/FixMe: this should be fixed before release”
“Let’s just copy and paste this part.”
12
13. Everyday Indicators of Technical Debt
“Don’t worry about the documentation for now.”
“The only one who can change this code is Carl”
“It’s ok for now but we’ll refactor it later!”
“ToDo/FixMe: this should be fixed before release”
“Let’s just copy and paste this part.”
“Does anybody know where we store the database access password?”
13
14. Everyday Indicators of Technical Debt
“Don’t worry about the documentation for now.”
“The only one who can change this code is Carl”
“It’s ok for now but we’ll refactor it later!”
“ToDo/FixMe: this should be fixed before release”
“Let’s just copy and paste this part.”
“Does anybody know where we store the database access password?”
“I know if I touch that code everything else breaks!”
14
15. Everyday Indicators of Technical Debt
“Don’t worry about the documentation for now.”
“The only one who can change this code is Carl”
“It’s ok for now but we’ll refactor it later!”
“ToDo/FixMe: this should be fixed before release”
“Let’s just copy and paste this part.”
“Does anybody know where we store the database access password?”
“I know if I touch that code everything else breaks!”
“Let’s finish the testing in the next release.” 15
16. Everyday Indicators of Technical Debt
“Don’t worry about the documentation for now.”
“The only one who can change this code is Carl”
“It’s ok for now but we’ll refactor it later!”
“ToDo/FixMe: this should be fixed before release”
“Let’s just copy and paste this part.”
“Does anybody know where we store the database access password?”
“I know if I touch that code everything else breaks!”
“Let’s finish the testing in the next release.” 16
“The release is coming up, so just get it done!”
18. Technical Debt Metaphor
• Definition
• Incomplete, immature, or inadequate artifact
in the software development lifecycle
(Cunningham, 1992)
• Aspects of the software we know are wrong,
but don’t have time to fix now
• Tasks that were left undone, but that run a risk
of causing future problems if not completed
18
19. Technical Debt Metaphor
• Benefits
• Higher software productivity in the current release
• Lower cost of current release
19
20. Technical Debt Metaphor
• Benefits
• Higher software productivity in the current release
• Lower cost of current release
• Costs
• “Interest” – increased maintenance costs
• Risk that the debt gets out of control
20
21. Technical Debt Metaphor
• Benefits
• Higher software productivity in the current release
• Lower cost of current release
• Costs
• “Interest” – increased maintenance costs
• Risk that the debt gets out of control
• Little scientific research, but
• Discussions in blogs, forums, etc.
• Strongly related to Risk Management
21
22. How Technical Debt is Managed (implicitly)
Wow, this module
is really bad. It’s
going to be very
hard to make any
changes to it.
David Miriam 22
Developer Manager
23. How Technical Debt is Managed (implicitly)
Hey, Miriam, I think we
should take some time to
refactor this module in the
next release.
David Miriam 23
Developer Manager
24. How Technical Debt is Managed (implicitly)
Why would we do that?
That would take a lot of
time and effort.
David Miriam 24
Developer Manager
25. How Technical Debt is Managed (implicitly)
But if we don’t refactor it
soon, I have a gut feeling it’s
going to cause major
problems later.
David Miriam 25
Developer Manager
26. How Technical Debt is Managed (implicitly)
David is pretty
smart, and he’s
usually right
about these kinds
of things.
David Miriam 26
Developer Manager
27. How Technical Debt is Managed (implicitly)
David Miriam 27
Developer OK, I’ll put in the plan for Manager
the next release.
29. How Technical Debt is Managed (implicitly)
Wow, this module
is really bad. It’s
going to be very Hey, Miriam, I think we
hard to make any should take some time to
changes to it. refactor this module in
the next release.
David Miriam 29
Developer Manager
30. How Technical Debt is Managed (implicitly)
Those developers
always try to make
their code perfect. I
need some
evidence that this is
worth it.
David Miriam 30
Developer Manager
31. How Technical Debt is Managed (implicitly)
What is the ROI of this
refactoring?
David Miriam 31
Developer Manager
32. How Technical Debt is Managed (implicitly)
RO…WHAT?!?
David Miriam 32
Developer Manager
33. How Technical Debt is Managed (implicitly)
David Miriam 33
Developer Let’s stick with Manager
implementing important
features.
34. Potential Payoffs of Explicitly
Managing TD
• Lowered maintenance costs
• Avoiding “interest payments”
• Avoiding unnecessary “perfecting” work
• Increased maintenance productivity
• Better prioritization of tasks in each release
• Maintenance always performed on code that is easier to work
with
• Avoiding surprises
• Fewer components that fail without warning
• Fewer unexpectedly large over-budget maintenance tasks
• Better estimation of the costs and risks of postponing
maintenance tasks 34
35. A Framework for Managing
Technical Debt
TD
Estimation
TD Decision
Identification Making
TD
List 35
36. Technical Debt List
A list of TD Items
Tasks that were left undone, but that run a risk of causing future
problems if not completed.
Examples: Components/modules/classes that need refactoring, testing
that needs to be done, etc.
Content of TD Item
Description – what, where, why?
Principal – how much will it cost to do the work?
Interest – what happens if we don’t do this work?
Amount – amount of extra work if this causes problems later
Probability – probability that this will cause future problems
TD List Update Policy
36
The TD list should be reviewed after each release, when items
should be added as well as removed.
37. TD Item Example
ID 37
Date 3/31/2008 (Release 3.2)
Responsible Joe Developer
Type Design
Location Method calculateStateTax in Module TaxCalc
Description In the last release, Joe added method
calculateStateTax quickly and method is overly
complex and not documented.
Estimated principal Medium (medium level of effort to refactor and
clean code)
Estimated interest amount: High (it will be costly to make changes to the
method in future, especially by other developers)
37
Estimated interest probability High (it is very likely that this methods needs to be
changed with each future release)
38. Some definitions
• Principal
• The cost of eliminating a Technical Debt instance RIGHT NOW
• Interest
• The cost, over some period of time, of NOT eliminating a
Technical Debt instance
• Interest is where the risk lies
• Interest probability
• The probability, over a given period of time, that a TD instance will
increase the cost of some future activity
• Interest amount
• Assuming that a TD instance does in fact increase the cost of some
activity, the amount of the increase
• NOTE: Unlike financial debt, Technical Debt interest will change
over time 38
39. Be careful when using
approaches that quantify
principal only
39
40. Be careful when using
approaches that quantify
principal only
A statement such as:
“Your project has $1,000,000
Technical Debt.”
40
is only one side of the coin.
41. So….
The goal of managing TD is…
Eliminating all Technical Debt
41
42. So….
The goal of managing TD is…
Eliminating all Technical Debt
NOT
42
43. So….
The goal of managing TD is…
To determine when
• The amount of interestavoided justifies
• The cost to pay off the principal
43
44. Example Scenario
• Technical Debt: One of your code modules is in need of
refactoring
• TD Principal: Refactoring the entire module will cost $10,000
• From past data you have established that:
• This module is modified in 75% of all releases
• The cost of changing this module has gone up 10% each time it’s
been changed over its last 5 changes:
• 5 changes ago cost $10,000
• Last change cost almost $15,000
44
45. Example Scenario (cont.)
• Technical Debt Computation
• For the next release
• Principal for paying off debt: refactoring the module costs $10,000
• Interest:
• Cost of the next change to the module
• If refactored first: $10,000
• If not refactored first: $16,000
• Extra cost if not refactored: about $6000
• Interest avoided = interest amount * interest probability
• $6,000 * .75 = $4500
Principal Interest Decision:
$10,000 > $4500 Ignore
45
47. Technical Debt Framework
TD
TD
Estimation
Estimation
TD
TD Decision
Decision
Identification
Identification Making
Making
TD
List 47
48. What are your goals for
managing Technical Debt?
• What are your pain points?
• Avoiding defects
• Better predictability
• Higher maintenance productivity
• Avoiding surprises
• Making developers happy
• Security, Portability, Efficiency ?
• Motivations are driven by:
• Business domain and market
• Past mistakes
48
49. Types of Technical Debt
• Design/code debt – can be identified by examining source
code and/or related documentation
• Happier developers and higher productivity
• Fewer defects
• Testing debt – planned tests that were not run, or known
deficiencies in the test suite (e.g. low code coverage)
• Fewer surprises and better predictability
• Documentation debt – missing or inadequate documentation
of any type
• Higher productivity
• Defect debt – known defects that are not fixed
• Happier developers and higher productivity 49
50. The Technical Debt Landscape
(under construction)
Pain Points Types of Debt Tools
Defect Code
Reliability
Debt Smells
Maintain- Design
ASA Tools
ability Debt
Documentation Modularity
Portability Debt Violations
Testing Manual
Security
Debt Inspection
… … …
50
Understanding your pain points will help to focus on the right types of Technical Debt.
52. ASA Issues
• ASA: Automatic Static (Code) Analysis
• Identify problems on line level:
1 Person person = aMap.get("bob");
2 if (person != null) {
3 person.updateAccessTime(); Potential Null
4 } Pointer Exception
5 String name = person.getName();
• Inexpensive
• Point to the problem, suggest solution
• Gaining significant traction in practice:
• Used by Google to identify problems
• Google Fixit Event
52
Links: http://findbugs.sourceforge.net/
53. ASA Issue Types
Many (thousands) issues
identified:
Many are false positives:
• False warnings
• Violation, but interest is
negligible
53
54. ASA Issue Types
Configure tools towards your pain points.
Start with the Technical Debt that is linked to the high priority goals.
Many (thousands) issues
identified:
Many are false positives:
• False warnings
• Violation, but interest is
negligible
54
55. ASA Tools: Our Recommendation
Project
• Turn OFF all issue types in the ASA tool. Quality
Business
• Activate types “interest-driven”: Goals
• Decide what your quality and business
goals are.
• Prioritize them based on:
• Past experience (user stories)
• Measurable impact
• Research Results:
• Multithread correctness and Correctness
issues are located in classes with higher
defect-proneness
55
56. Code Smells
• Methods and classes that violate
the principles of good object
oriented design, e.g.:
• Clearly defined
single responsibility
• Encapsulation
• Information hiding
• Few and clear interfaces
• Proper use of inheritance
• Code Smells point to potential
problems:
• require investigation and final judgment by
developer 56
• Set of 20 more or less formally
defined Code Smells available
57. Code Smells Explained
• Automatic approaches have been proposed and implemented
to automatically detect Code Smells in object oriented code
• Based on Radu Marinescu’s Detection Strategies
• For Java: CodeVizard and Marple
• For C#: ReSharper, CodeRush, Gendarme, FxCop
• Two code smells important for TD:
• god class
• dispersed coupling
57
Further reading: http://www.codevizard.com
58. Code Smells: Our
Recommendation
• If avoiding defects and increasing maintenance productivity
are issues of concern, then…
• Start by detecting and examining God Classes and Dispersed
Coupling code smells
• Prioritize modules with these smells for refactoring efforts
• Research focus: God Classes (concept is easy to understand)
• God Classes are 5-7 times more change prone
• God Classes are 4-17 times more defect prone
• Baseline from our experience: most systems have 2%-8% God
Classes
• Dispersed Coupling code smell points to defect and 58
maintenance prone classes
59. Design Patterns and Grime
• Design patterns promise code to be more maintainable
and less defect prone
• Describe how multiple classes work together
• Design patterns can decay over time as systems evolve
• Grime: accumulation of non-pattern code in classes
following a design pattern
• Rot: changes that break the integrity of a design
pattern
• Early results show that grime has a noticeable effect on
testability
• As grime builds up, more test cases break
• In turn affects productivity during the testing phase 59
• Leads to testing debt
60. Modularity Violations
• Organization of software systems: inter-dependent modules
• Proper architecture leading to a clear structure of relationships
promotes reuse of modules and smaller ripple effects.
• Dependencies indicate how modules should change together:
• Example:
If the Model is changed, Controller A
Model
and Controller B might require
changes.
Controller Controller
• Modularity Violations: recurring A B
changes on classes within modules
that are not depending on each other: View 1 View 3
• Example: Classes in View 1 and View 3
changing together 60
View 2
61. Modularity Violations Research
• Studies have shown that modularity violations are an excellent
indicator of defect prone classes and change prone classes.
• Tool: CLIO (Drexel University)
• When applied, with other TD detection approaches, to an
open source system, the results for predicting defects were:
• Also, modularity violations were highly correlated with 61
modules that developers later chose to refactor
Further reading: http://www.slideshare.net/miryung/icse-2011-research-paper-on-modularity-violations
62. Technical Debt Framework
TD
TD
Estimation
Estimation
TD
TD Decision
Decision
Identification
Identification Making
Making
TD
List 62
63. Testing Debt
“There's no tests for buttons other
• Tests that were planned but: than <input type="submit"> yet. I'm
• not implemented pretty sure also <input
type="button"> works if other
• not executed <input>s work, but <button
disabled="disabled">Text</button>
• or they got lost should be tested separately.”
http://code.google.com/p/robotframework-seleniumlibrary/issues/detail?id=163
• Inadequate tests
• Test cases not updated for “While updating the package of
html5lib to 0.90 in Debian I
new/changed functionality realized that the unit tests are
gone. To ensure the keep the
• Low coverage package in a good working shape
while it transitions trough new
• Can be detected by: Python versions and new versions of
the modules it depends on, it would
• Comparing test results with test be *very* appreciated if the unit
plans tests would be shipped in the
zipfile again.”
• Code coverage tools http://code.google.com/p/html5lib/issues/detail?id=134&colspec=ID%2
0Type%20Status%20Priority%20Milestone%20Owner%20Summary%20P
• Comparing requirements ort
63
changes with test suite changes
64. Documentation Debt
• Documentation that is not “Except there is no such class or
field in the SDK. It is outdated
kept up-to-date, e.g. documentation that definitely needs
to be updated.”
• Installations and run http://code.google.com/p/android/issues/detail?id=8483
instructions
• Architecture “There is not much documentation
documentation available regarding the format
of .xclangspec files. As a starting
• Requirements and use case point, see for instance the
outdated documentation at:
documentation http://maxao.free.fr/xcode-plugin-
• API documentation interface/specifications.html”
http://code.google.com/p/go/source/browse/misc/xcode/go.xclangspec
?r=30b0c392132645259e053a2ba8904383a55bab03
• Can be detected by:
• Comparing code changes “This was apparently the old
behavior and it's changed
with documentation now, but the documentation
changes doesn't so say.”
• Comment density metrics
http://code.google.com/p/redis/issues/detail?id=514
64
65. Defect Debt
“There are a couple of latent
• Known defects that are not bugs in the linux TLS
implementation. I'm filing a
yet fixed single issue because they are
so small and easy to fix.”
• Low priority defects http://code.google.com/p/dynamorio/issues/detail?id=358
• Low severity defects
• Manifest rarely
• Workarounds present
• Can be detected by:
• Examining defect
repositories
• Test results
65
66. Bottom line
• Different techniques detect different instances and types of
technical debt
• No one approach is sufficient by itself
• No one approach is the right one for everyone
• The solution is a strategy based on
• Business and development goals
• Most painful types of debt
• A combination of approaches that focus on the most pain
• Don’t try to automate it all
• Some kinds of technical debt can only be detected by humans
• Most kinds of technical debt can only be interpreted by humans
• No substitute for talking about it 66
69. TD Attributes
Three attributes of a TD item
Principal
Interest probability
Interest amount
Start with a rough estimate of the attribute values
High, Medium, Low
Defer more precise estimation until data is available
Fault detection ability and defect density => testing debt
Cost of fixing a defect pre-release & post-release => defect debt
Time and effort for updating documentation => documentation debt
69
70. TD Attribute Estimation
• Principal => historical effort data
• Interest Probability => historical usage, change, and defect data
• Example questions
• How likely is it that a defect will occur in the untested part?
• How likely is it that code containing a known error will be exercised?
• A time element
• Interest amount
• Assume that the item has an effect on future work
• Example questions
• How much more it will cost to deal with defects later in the system’s lifetime than in
testing?
• These are all hard to estimate with any certainty
• Historical data will help
• Any estimation is better than the current method – “gut feeling”
70
71. Decision Making Scenario
• Question
• When and which technical debt items should be paid?
• Example
• Significant work is planned for component X in the next release, should
we pay down some debt on component X at the same time?
• Assumptions
• There is an up-to-date TD list that is sorted by component and has
high, medium, and low values for principal and interest estimates for
each item.
• Process
Select Re-evaluate Estimate Compare Add up 71
72. Other Decision Models
• The proposed TD management strategy is based on a simple
cost/benefit analysis
• But TD occurs in complicated development and business
scenarios
• TD items are inter-related
• Business factors are important, too
• Prediction is hard
• Other strategies for making decisions might be appropriate
• Portfolio model
• Options
• AHP
72
75. “Avoid being a perfectionist in a
world of finite resources.”
Forrest Shull
Instead…
Manage Technical Debt to make the imperfections
• documented
• explicit
• not so scary
75
76. Summary
• Technical Debt is a metaphor that describes a very real
phenomenon
• Provides a way to talk and reason about the difficulties of
software maintenance
• Technical Debt comes in a variety of forms, all of which can be
detected in different ways
• Technical Debt can be documented and tracked in a TD list
• Management of Technical Debt must involve consideration of
interest, not just principal
• The types of Technical Debt that are relevant for a particular
situation depends on past experience, organizational culture,
and business environment.
• While the research is still early, it does provide some guidance 76
as to Technical Debt identification strategy.
77. What’s next…
• Identify your pain points
• Decide what types of Technical Debt are relevant for you
• Choose a small set of tools and indicators
• Start a TD list – can use our template - probably some
developers already have one
• Track the history of the TD items revealed by the tools to see if
they are detecting “real” debt
• Refine release planning process to incorporate TD
• Track your success in reducing the “pain”
• Add new detection strategies to fill the gaps
• Call us if you need help 77
• Tell us how it’s going!
81. References
Ayewah, N. et al. (2007). Evaluating static analysis defect warnings on production software. In Proceedings of
the 7th ACM SIGPLAN-SIGSOFT workshop on Program analysis for software tools and engineering - PASTE
’07. New York, New York, USA: ACM Press, pp. 1-8. Available at:
http://dl.acm.org/citation.cfm?id=1251535.1251536 .
Baldwin C. and Clark K. (2000). Design Rules, Vol. 1: The Power of Modularity. MIT Press.
Brown N., Cai Y., Guo Y., Kazman R., Kim M., Kruchten P., Lim E., MacCormack A., Nord R., Ozkaya I., Sangwan
R., Seaman C., Sullivan K., and Zazworka N. (2010). Managing technical debt in software-reliant systems.
FoSER 2010: 47-52.
Cunningham W. (1992). The WyCash Portfolio Management System. Addendum to the proceedings on
Object-oriented programming systems, languages, and applications, pp. 29-30, 1992.
Fowler M. (2003). Technical Debt. Available: http://www.martinfowler.com/bliki/TechnicalDebt.html
Guéhéneuc Y.G., and Albin-Amiot H. (2001). Using Design Patterns and Constraints to Automate the Detection
and Correction of Inter-Class Design Defects. Proc 39th International Conference and Exhibition
Technology of Object Oriented Languages and Systems, pp. 296-305, 2001.
Guo Y., Seaman C., Zazworka N., and Shull F. (2010). Domain-specific tailoring of code smells: an empirical
study. International Conference on Software Engineering, ERA Track Cape Town, South Africa, May.
Guo Y., and Seaman C. (2011). A Portfolio Approach to Technical Debt Management. Workshop on Managing
Technical Debt. Hawaii, USA, May.
81
82. References
Guo Y., Seaman, C., Gomes R., Cavalcanti A., Tonin G, Da Silva F.Q.B., Santos A.L.M., Siebra C. (2011). Tracking
Technical Debt – an exploratory case study. International Conference on Software Maintenance,
Williamsburg, VA, September.
Izurieta C., and Bieman J.M. (2008). Testing Consequences of Grime Buildup in Object Oriented Design
Patterns. 1st ACM-IEEE International Conference on Software Testing, Verification and Validation, ICST ’08,
Lillehamer, Norway, April 2008.
Kim S. and Ernst M. (2007). Prioritizing Warning Categories by Analyzing Software History. In Fourth
International Workshop on Mining Software Repositories (MSR’07:ICSE Workshops 2007). IEEE, pp. 27-27.
Available at: http://dl.acm.org/citation.cfm?id=1268983.1269041.
Marinescu R. (2004). Detection strategies: Metrics-based rules for detecting design flaws. IEEE International
Conference on Software Maintenance. Pp. 350–359.
Markowitz H. (1952). Portfolio Selection. the Journal of Finance. Vol. 7, No. 1, pp. 77-91.
Rothman J. (2006). An Incremental Technique to Pay Off Testing Technical Debt. Available:
http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=11011&tth=DYN
&tt=siteemail&iDyn=2
Saaty T. L. (1982). Decision making for leaders: The analytical hierarchy process for decision in a complex
world. Belmot, California: Lifetime Learning Publications.
Schanz T., and Izurieta C. (2010). Object Oriented Design Pattern Decay: A Taxonomy. 4th ACM-IEEE
International Symposium on Empirical Software Engineering and Measurement, ESEM ’10, Bolzano-Bozen, 82
Italy, September 2010.
83. References
Seaman C., and Guo Y. (2011). Measuring and Monitoring Technical Debt.
ADVANCES IN COMPUTERS. Vol. 82, pp. 25–46.
Sortino F. A., and Price L. N. (1994). Performance Measurement in a Downside Risk
Framework. the Journal of Investing. Vol. 3, No. 3, pp. 59-64.
Sullivan K., Chalasani P., Jha S and Sazawal V. (1999). Software Design as an
Investment Activity: A Real Options Perspective in Real Options and Business
Strategy: Applications to Decision Making. Risk Books, November.
Vetró A., Torchiano M., and Morisio, M. (2010). Assessing the precision of FindBugs
by mining Java projects developed at a university. In Mining Software
Repositories (MSR), 7th IEEE Working Conference on. pp. 110-113.
Vetró A., Morisio M, Torchiano, M. (2011). An Empirical Validation of FindBugs
Issues Related to Defects. Evaluation and Assessment in Software Engineering
2011 (EASE 2011). Durham City, UK.
Wong S., Cai Y., Kim M., and Dalton M. (2011). Detecting software modularity
violations. Proc. 33th International Conference on Software Engineering. May
2011, pp. 411–420.
Zazworka N., Shaw M., Shull F., Seaman C. (2011). Investigating the Impact of
Design Debt on Software Quality. Workshop on Managing Technical
Debt, Hawaii, USA, May. 83
85. Further Reading and Survey
• Further Reading:
• Our Research Group’s website:
http://www.technicaldebt.umbc.edu/
• OnTechnicalDebt
http://www.ontechnicaldebt.com/
• 5 minute online survey about common beliefs on TD
http://tinyurl.com/TechnicalDebt 85