Often as developers we are stuck evaluating only the negative artifacts of technical debt. However, what if we looked at the debt metaphor from the point-of-view of our business executives. Would we reach the same conclusions?
In this presentation, I demonstrate that technical debt is not always something to be avoided. In fact, when debt is incurred responsibly, it can become a powerful tool that improves the communication between stakeholders and technologists.
As we inspect this concept, I offer rules and guidelines for evaluating when debt is good and when it is toxic. Once we have a firm understanding of this framework, I present strategies for prudently measuring, paying, and using debt. At the end of the presentation, both developers and business stakeholders will gain a new vocabulary for describing project decisions that will maximize the collaboration between both teams.
In this session, we will examine the notion of 'innovation' with the goal of enabling new ideas within your team. This starts by challenging the concept of what innovation means and where new ideas originate. Techniques will be offered for building a culture of innovation which include: how to curate ideas, inspire teams, build innovative mindsets, create better processes and deal with change.
By the end of the session, attendees will gain new strategies that foster an environment of empowerment, creativity and collaboration.
What is Technical Debt? It doesn't have to be negative, but it does have to be carefully managed. Here is a quick run-down of best practice to approaching Technical Debt management.
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.
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.
Technical Debt - The number one reason why technical projects get derailedAccesto
A couple of years ago we had a very successful product - a game hosting management panel. Over the years our client database grew and we introduced support for new games and new features.
That was our first product, and it became quite popular. At one point it was used by the majority of game hosting providers in Poland.
But then, here’s what happened: as our client database quickly grew and we extended the application’s functionality, we consciously started taking shortcuts. Sometimes because of time constraints, other times we just thought it was the smart thing to do.
With time it got harder and harder to fix the bugs and introduce new features. We had been adding fuel to the fire without noticing it. And then, one day, we just realized the product was not profitable anymore due to its technical debt. The expenses of maintaining the product outgrew the profits it had been bringing in.
Whether we know it or not, every time we deliver a feature we also deliver technical debt. This debt remains largely invisible, it isn't tracked, it isn't visible on our information radiators and we very seldom tell our clients about it. The closest we come to acknowledging technical debt is bugs, mainly because our users tell us there is a problem, so we can't ignore it. Technical debt shouldn't be invisible, it's as real as the features we deliver and we should start treating it so. In this talk I propose a technical debt model which can be used when identifying technical debt, furthermore I propose a low friction technique for integrating technical debt into your current SDLC process.
In this session, we will examine the notion of 'innovation' with the goal of enabling new ideas within your team. This starts by challenging the concept of what innovation means and where new ideas originate. Techniques will be offered for building a culture of innovation which include: how to curate ideas, inspire teams, build innovative mindsets, create better processes and deal with change.
By the end of the session, attendees will gain new strategies that foster an environment of empowerment, creativity and collaboration.
What is Technical Debt? It doesn't have to be negative, but it does have to be carefully managed. Here is a quick run-down of best practice to approaching Technical Debt management.
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.
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.
Technical Debt - The number one reason why technical projects get derailedAccesto
A couple of years ago we had a very successful product - a game hosting management panel. Over the years our client database grew and we introduced support for new games and new features.
That was our first product, and it became quite popular. At one point it was used by the majority of game hosting providers in Poland.
But then, here’s what happened: as our client database quickly grew and we extended the application’s functionality, we consciously started taking shortcuts. Sometimes because of time constraints, other times we just thought it was the smart thing to do.
With time it got harder and harder to fix the bugs and introduce new features. We had been adding fuel to the fire without noticing it. And then, one day, we just realized the product was not profitable anymore due to its technical debt. The expenses of maintaining the product outgrew the profits it had been bringing in.
Whether we know it or not, every time we deliver a feature we also deliver technical debt. This debt remains largely invisible, it isn't tracked, it isn't visible on our information radiators and we very seldom tell our clients about it. The closest we come to acknowledging technical debt is bugs, mainly because our users tell us there is a problem, so we can't ignore it. Technical debt shouldn't be invisible, it's as real as the features we deliver and we should start treating it so. In this talk I propose a technical debt model which can be used when identifying technical debt, furthermore I propose a low friction technique for integrating technical debt into your current SDLC process.
Technical debt is often characterized as design or code tradeoffs. In this talk I discuss how shortcuts in requirements analysis might lead to technical debt as well.
In this session we will discuss the use of Agile constructs within the domain of software architecture. This will include an exploration of how to balance emergent designs with intentional planning. Additional ancillary topics will also be addressed including: common architecture principles, guidelines for measuring good architecture, and an evaluation of agile techniques.
By the end of the session, attendees will have a new perspective on architecture that will empower them to create flexible software solutions.
Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code.
These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions.
What is technical debt?
What is not technical debt?
Why should we care?
What is the cost of misunderstanding?
An overview of the Agile Manifesto and why Agile SDLC is super important to excellent project management practices. Agile Software development is dominating the game these days. Whether you're going responsive, managing ecommerce, magento, or iphone apps Agile practices will help your efforts succeed.
Lean/Agile system architecture presentation. Goes through pros/cons of upfront work and the xp/agile approach. Defines important concepts, shows examples of how things could be done and goes through tools/things that can help along the way.
There are dozens of myths about Agile development. But before jumping into specific misconceptions, let’s have a look at some common business challenges:
For senior-level execs: do you value revenue growth or cost containment?
For project managers: do you value team efficiency or effectiveness?
For developers: do you value code quantity or quality?
In each scenario, you probably struggled to make a choice given that your two options were not mutually exclusive.
Posing the question this way creates a false dilemma since you likely value both options but to varying degrees. So the better question is, of the two options, which do you value more?
How to justify technical debt mitigations in Software EngineeringAndré Agostinho
In this presentation André Agostinho e Cassio Silva covers the importance in dealing with technical debt in software engineering showing the real impacts, daily approaches and best practices for mitigations
How to deal with tech debt: Lessons learned from the best engineering teamsAlexandre Omeyer
Tech debt can be really overwhelming. Often when you start to address it, you realize you’re only just scratching the tip of the iceberg. It doesn’t have to be an insurmountable problem, understanding how to prioritize the right issues will enable you to turn the boat around.
Join us in hosting Alexandre Omeyer, CEO & Co-founder at Stepsize. For the first time he will be walking us through his incredible research, which includes interviews with 200+ software engineers.
In this webinar you will learn:
- How to define and understand tech debt.
- The tactics for dealing with tech debt head on.
- Implementing processes and tools to use when dealing with small, medium, and large pieces of tech debt.
- How to think and approach tech debt depending on your company’s stage, size, business priorities, and culture.
Watch the webinar on YouTube: https://www.youtube.com/watch?v=QnizCRe-sV8
Technical debt is often characterized as design or code tradeoffs. In this talk I discuss how shortcuts in requirements analysis might lead to technical debt as well.
In this session we will discuss the use of Agile constructs within the domain of software architecture. This will include an exploration of how to balance emergent designs with intentional planning. Additional ancillary topics will also be addressed including: common architecture principles, guidelines for measuring good architecture, and an evaluation of agile techniques.
By the end of the session, attendees will have a new perspective on architecture that will empower them to create flexible software solutions.
Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code.
These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions.
What is technical debt?
What is not technical debt?
Why should we care?
What is the cost of misunderstanding?
An overview of the Agile Manifesto and why Agile SDLC is super important to excellent project management practices. Agile Software development is dominating the game these days. Whether you're going responsive, managing ecommerce, magento, or iphone apps Agile practices will help your efforts succeed.
Lean/Agile system architecture presentation. Goes through pros/cons of upfront work and the xp/agile approach. Defines important concepts, shows examples of how things could be done and goes through tools/things that can help along the way.
There are dozens of myths about Agile development. But before jumping into specific misconceptions, let’s have a look at some common business challenges:
For senior-level execs: do you value revenue growth or cost containment?
For project managers: do you value team efficiency or effectiveness?
For developers: do you value code quantity or quality?
In each scenario, you probably struggled to make a choice given that your two options were not mutually exclusive.
Posing the question this way creates a false dilemma since you likely value both options but to varying degrees. So the better question is, of the two options, which do you value more?
How to justify technical debt mitigations in Software EngineeringAndré Agostinho
In this presentation André Agostinho e Cassio Silva covers the importance in dealing with technical debt in software engineering showing the real impacts, daily approaches and best practices for mitigations
How to deal with tech debt: Lessons learned from the best engineering teamsAlexandre Omeyer
Tech debt can be really overwhelming. Often when you start to address it, you realize you’re only just scratching the tip of the iceberg. It doesn’t have to be an insurmountable problem, understanding how to prioritize the right issues will enable you to turn the boat around.
Join us in hosting Alexandre Omeyer, CEO & Co-founder at Stepsize. For the first time he will be walking us through his incredible research, which includes interviews with 200+ software engineers.
In this webinar you will learn:
- How to define and understand tech debt.
- The tactics for dealing with tech debt head on.
- Implementing processes and tools to use when dealing with small, medium, and large pieces of tech debt.
- How to think and approach tech debt depending on your company’s stage, size, business priorities, and culture.
Watch the webinar on YouTube: https://www.youtube.com/watch?v=QnizCRe-sV8
A collection of slides that illustrate how to go about effectively managing technical debt on a software project. I used these slides during a demonstration at an internal demonstration on technical debt at Fuzz Productions.
Agility is about being adaptive. CRM is about being efficient. How do you apply Agile's key values to make the most out of your CRM? How do you drive your CRM deployment in an Agile way?
The term ‘technical debt' and the challenges it can bring are becoming more widely understood and discussed by IT practitioners, vendor managers and business leaders. If you're looking at technical debt in your organization, or already thinking about measuring technical debt with your vendors, you will find this report useful.
How to Position Your Globus Data Portal for Success Ten Good PracticesGlobus
Science gateways allow science and engineering communities to access shared data, software, computing services, and instruments. Science gateways have gained a lot of traction in the last twenty years, as evidenced by projects such as the Science Gateways Community Institute (SGCI) and the Center of Excellence on Science Gateways (SGX3) in the US, The Australian Research Data Commons (ARDC) and its platforms in Australia, and the projects around Virtual Research Environments in Europe. A few mature frameworks have evolved with their different strengths and foci and have been taken up by a larger community such as the Globus Data Portal, Hubzero, Tapis, and Galaxy. However, even when gateways are built on successful frameworks, they continue to face the challenges of ongoing maintenance costs and how to meet the ever-expanding needs of the community they serve with enhanced features. It is not uncommon that gateways with compelling use cases are nonetheless unable to get past the prototype phase and become a full production service, or if they do, they don't survive more than a couple of years. While there is no guaranteed pathway to success, it seems likely that for any gateway there is a need for a strong community and/or solid funding streams to create and sustain its success. With over twenty years of examples to draw from, this presentation goes into detail for ten factors common to successful and enduring gateways that effectively serve as best practices for any new or developing gateway.
SOCRadar Research Team: Latest Activities of IntelBrokerSOCRadar
The European Union Agency for Law Enforcement Cooperation (Europol) has suffered an alleged data breach after a notorious threat actor claimed to have exfiltrated data from its systems. Infamous data leaker IntelBroker posted on the even more infamous BreachForums hacking forum, saying that Europol suffered a data breach this month.
The alleged breach affected Europol agencies CCSE, EC3, Europol Platform for Experts, Law Enforcement Forum, and SIRIUS. Infiltration of these entities can disrupt ongoing investigations and compromise sensitive intelligence shared among international law enforcement agencies.
However, this is neither the first nor the last activity of IntekBroker. We have compiled for you what happened in the last few days. To track such hacker activities on dark web sources like hacker forums, private Telegram channels, and other hidden platforms where cyber threats often originate, you can check SOCRadar’s Dark Web News.
Stay Informed on Threat Actors’ Activity on the Dark Web with SOCRadar!
Top Features to Include in Your Winzo Clone App for Business Growth (4).pptxrickgrimesss22
Discover the essential features to incorporate in your Winzo clone app to boost business growth, enhance user engagement, and drive revenue. Learn how to create a compelling gaming experience that stands out in the competitive market.
How Recreation Management Software Can Streamline Your Operations.pptxwottaspaceseo
Recreation management software streamlines operations by automating key tasks such as scheduling, registration, and payment processing, reducing manual workload and errors. It provides centralized management of facilities, classes, and events, ensuring efficient resource allocation and facility usage. The software offers user-friendly online portals for easy access to bookings and program information, enhancing customer experience. Real-time reporting and data analytics deliver insights into attendance and preferences, aiding in strategic decision-making. Additionally, effective communication tools keep participants and staff informed with timely updates. Overall, recreation management software enhances efficiency, improves service delivery, and boosts customer satisfaction.
AI Pilot Review: The World’s First Virtual Assistant Marketing SuiteGoogle
AI Pilot Review: The World’s First Virtual Assistant Marketing Suite
👉👉 Click Here To Get More Info 👇👇
https://sumonreview.com/ai-pilot-review/
AI Pilot Review: Key Features
✅Deploy AI expert bots in Any Niche With Just A Click
✅With one keyword, generate complete funnels, websites, landing pages, and more.
✅More than 85 AI features are included in the AI pilot.
✅No setup or configuration; use your voice (like Siri) to do whatever you want.
✅You Can Use AI Pilot To Create your version of AI Pilot And Charge People For It…
✅ZERO Manual Work With AI Pilot. Never write, Design, Or Code Again.
✅ZERO Limits On Features Or Usages
✅Use Our AI-powered Traffic To Get Hundreds Of Customers
✅No Complicated Setup: Get Up And Running In 2 Minutes
✅99.99% Up-Time Guaranteed
✅30 Days Money-Back Guarantee
✅ZERO Upfront Cost
See My Other Reviews Article:
(1) TubeTrivia AI Review: https://sumonreview.com/tubetrivia-ai-review
(2) SocioWave Review: https://sumonreview.com/sociowave-review
(3) AI Partner & Profit Review: https://sumonreview.com/ai-partner-profit-review
(4) AI Ebook Suite Review: https://sumonreview.com/ai-ebook-suite-review
Experience our free, in-depth three-part Tendenci Platform Corporate Membership Management workshop series! In Session 1 on May 14th, 2024, we began with an Introduction and Setup, mastering the configuration of your Corporate Membership Module settings to establish membership types, applications, and more. Then, on May 16th, 2024, in Session 2, we focused on binding individual members to a Corporate Membership and Corporate Reps, teaching you how to add individual members and assign Corporate Representatives to manage dues, renewals, and associated members. Finally, on May 28th, 2024, in Session 3, we covered questions and concerns, addressing any queries or issues you may have.
For more Tendenci AMS events, check out www.tendenci.com/events
OpenFOAM solver for Helmholtz equation, helmholtzFoam / helmholtzBubbleFoamtakuyayamamoto1800
In this slide, we show the simulation example and the way to compile this solver.
In this solver, the Helmholtz equation can be solved by helmholtzFoam. Also, the Helmholtz equation with uniformly dispersed bubbles can be simulated by helmholtzBubbleFoam.
Enhancing Project Management Efficiency_ Leveraging AI Tools like ChatGPT.pdfJay Das
With the advent of artificial intelligence or AI tools, project management processes are undergoing a transformative shift. By using tools like ChatGPT, and Bard organizations can empower their leaders and managers to plan, execute, and monitor projects more effectively.
Innovating Inference - Remote Triggering of Large Language Models on HPC Clus...Globus
Large Language Models (LLMs) are currently the center of attention in the tech world, particularly for their potential to advance research. In this presentation, we'll explore a straightforward and effective method for quickly initiating inference runs on supercomputers using the vLLM tool with Globus Compute, specifically on the Polaris system at ALCF. We'll begin by briefly discussing the popularity and applications of LLMs in various fields. Following this, we will introduce the vLLM tool, and explain how it integrates with Globus Compute to efficiently manage LLM operations on Polaris. Attendees will learn the practical aspects of setting up and remotely triggering LLMs from local machines, focusing on ease of use and efficiency. This talk is ideal for researchers and practitioners looking to leverage the power of LLMs in their work, offering a clear guide to harnessing supercomputing resources for quick and effective LLM inference.
Understanding Globus Data Transfers with NetSageGlobus
NetSage is an open privacy-aware network measurement, analysis, and visualization service designed to help end-users visualize and reason about large data transfers. NetSage traditionally has used a combination of passive measurements, including SNMP and flow data, as well as active measurements, mainly perfSONAR, to provide longitudinal network performance data visualization. It has been deployed by dozens of networks world wide, and is supported domestically by the Engagement and Performance Operations Center (EPOC), NSF #2328479. We have recently expanded the NetSage data sources to include logs for Globus data transfers, following the same privacy-preserving approach as for Flow data. Using the logs for the Texas Advanced Computing Center (TACC) as an example, this talk will walk through several different example use cases that NetSage can answer, including: Who is using Globus to share data with my institution, and what kind of performance are they able to achieve? How many transfers has Globus supported for us? Which sites are we sharing the most data with, and how is that changing over time? How is my site using Globus to move data internally, and what kind of performance do we see for those transfers? What percentage of data transfers at my institution used Globus, and how did the overall data transfer performance compare to the Globus users?
Large Language Models and the End of ProgrammingMatt Welsh
Talk by Matt Welsh at Craft Conference 2024 on the impact that Large Language Models will have on the future of software development. In this talk, I discuss the ways in which LLMs will impact the software industry, from replacing human software developers with AI, to replacing conventional software with models that perform reasoning, computation, and problem-solving.
Exploring Innovations in Data Repository Solutions - Insights from the U.S. G...Globus
The U.S. Geological Survey (USGS) has made substantial investments in meeting evolving scientific, technical, and policy driven demands on storing, managing, and delivering data. As these demands continue to grow in complexity and scale, the USGS must continue to explore innovative solutions to improve its management, curation, sharing, delivering, and preservation approaches for large-scale research data. Supporting these needs, the USGS has partnered with the University of Chicago-Globus to research and develop advanced repository components and workflows leveraging its current investment in Globus. The primary outcome of this partnership includes the development of a prototype enterprise repository, driven by USGS Data Release requirements, through exploration and implementation of the entire suite of the Globus platform offerings, including Globus Flow, Globus Auth, Globus Transfer, and Globus Search. This presentation will provide insights into this research partnership, introduce the unique requirements and challenges being addressed and provide relevant project progress.
Cyaniclab : Software Development Agency Portfolio.pdfCyanic lab
CyanicLab, an offshore custom software development company based in Sweden,India, Finland, is your go-to partner for startup development and innovative web design solutions. Our expert team specializes in crafting cutting-edge software tailored to meet the unique needs of startups and established enterprises alike. From conceptualization to execution, we offer comprehensive services including web and mobile app development, UI/UX design, and ongoing software maintenance. Ready to elevate your business? Contact CyanicLab today and let us propel your vision to success with our top-notch IT solutions.
We describe the deployment and use of Globus Compute for remote computation. This content is aimed at researchers who wish to compute on remote resources using a unified programming interface, as well as system administrators who will deploy and operate Globus Compute services on their research computing infrastructure.
Software Engineering, Software Consulting, Tech Lead.
Spring Boot, Spring Cloud, Spring Core, Spring JDBC, Spring Security,
Spring Transaction, Spring MVC,
Log4j, REST/SOAP WEB-SERVICES.
Navigating the Metaverse: A Journey into Virtual Evolution"Donna Lenk
Join us for an exploration of the Metaverse's evolution, where innovation meets imagination. Discover new dimensions of virtual events, engage with thought-provoking discussions, and witness the transformative power of digital realms."
Globus Compute wth IRI Workflows - GlobusWorld 2024Globus
As part of the DOE Integrated Research Infrastructure (IRI) program, NERSC at Lawrence Berkeley National Lab and ALCF at Argonne National Lab are working closely with General Atomics on accelerating the computing requirements of the DIII-D experiment. As part of the work the team is investigating ways to speedup the time to solution for many different parts of the DIII-D workflow including how they run jobs on HPC systems. One of these routes is looking at Globus Compute as a way to replace the current method for managing tasks and we describe a brief proof of concept showing how Globus Compute could help to schedule jobs and be a tool to connect compute at different facilities.
2. #craftingdigital
Who Is This Guy?
Steve P. Green
Steve currently serves as the Chief Executive
Officer for Blue Rivet, a collaborative digital agency
in Kansas City.
My professional experience
I consider code an art form, and have worked to master
the craft over the last 15 years at some of the finest
technology companies in Kansas City.
3. #craftingdigital
Understanding My Bias
Seth Godin
One of the most-loved marketing gurus on
the internet, generating 50 million views per
month.
I believe that building software is fun. More importantly, I
view it as something worthy of mastery.
“If it’s work, we try to do
less. If it’s art, we try to
do more.” – Seth Godin
5. #craftingdigital
A Quick History Lesson
Ward Cunningham
In 1992 at a developer conference, he was the
first to use the “Technical Debt” metaphor as a
way to explain software decisions.
“Shipping first time code is like going into
debt.
A little debt speeds development, so
long as it is paid back promptly with a
re-write.
Every minute spent on not-quite-right
code counts as interest on that debt.”
– Ward Cunningham, 1992
6. #craftingdigital
Towards a Definition
Bad Code is Often Invisible
Bad code is dangerous because it is often
invisible to the business. However,
expressing it as debt helps expose the
problem.
Stuff that is wrong with the
application, even though it will
pass functional requirements.
Technical debt is often like a Band-Aid. It will hold the
application together to get it through testing. However, it
is rarely a long term solution and eventually needs to be
replaced.
7. #craftingdigital
Consequences of Ignoring Debt
The code will become
uncontrollable
Developers will become
overly specialized
1
2
3 The solution will become
inflexible
Staff will become
demoralized and
unmotivated
4
Given that the software “works”, it can
be tempting to ignore the debt.
However, this can have fatal
consequences.
By actively engaging in debt
conversations, the business can ensure
technology is aligned with the overall
corporate strategy.
Why Should the
Business Care?
8. #craftingdigital
Consider This Kitchen
Technical debt builds quietly over time
until it becomes unmanageable
No one sets out to design software poorly; rather it happens slowly over time. Consider this
messy kitchen. The designer didn’t set out to create this disaster. Instead, it happened naturally
over time as the result of small bad decisions that incrementally destroyed this space.
9. #craftingdigital
An Example in Code
This is a massive SQL query
from the Daily WTF called the
“Query of Despair”.
However, even though it is
hard for us humans to
understand, the computer has
no problem.
The “Query of Despair”
11. #craftingdigital
Common Indications of Debt
A developer’s primary
responsibility is to solve “how”.
If they don’t know “how”,
they’ll try to work through it
instead of looking for help.
In order to combat this, we
have to look for common
indicators that problems exist.
This allows us to begin
identifying debt.
Coders Hate Asking
for Help
Velocity: large decrease in the
number of tasks completed per sprint
1
Stress: development team is routinely
stressed during deployments
3
Production: on-going issues keep
coming up even after fixes
4
Quality: number of bugs per
release increase rapidly
2
12. #craftingdigital
Start Training Your Spidey Sense Look for common “smells” that indicate possible problems.
“Don’t worry about the documentation for now.”
“The only one who can change this code is Bob.”
“ToDo/FixMe: this should be fixed before the prod roll”
“Does anyone know where we store the database password?”
“I know if I touch that code everything else breaks.”
“Let’s just use our QA time to finish that feature.”
“The client doesn’t care, just get it done!”
13. #craftingdigital
Finding Debt In Existing Codebases
Automated Toolsets
Robust development such as Visual
Studio provide toolsets to evaluate code
metrics.
Use Code Metrics
When evaluating existing projects, the following code
metrics can become key indicators that debt exists.
Cyclomatic Complexity
Measures the number of logical branches in the code.
The higher this number, the greater chance of debt.
Code Coupling
Measures the inter-connectedness of components
within the solution. The more connected, the higher
probability of debt.
Test Coverage
The amount of code exercised by automated tests. The
lower the coverage, the higher likelihood of debt.
Code Commits
Frequent code commits to the same area of an
application can be a sign of technical debt in that area.
14. #craftingdigital
When is Debt Most Likely to Occur?
SCOPE
TIME
Planned
Velocity
Actual
Velocity
Business
Pressure
Planned Release Full Quality Release
Technical
Debt
Understanding when debt commonly occurs makes it easier to track.
15. #craftingdigital
Debt Happens Naturally
Software Rusts
Like most technology, software can become
old and rusty.
Once software is released to production it can be easy to
forget that it may be incurring debt naturally. As
vendors update their toolsets, it is highly possible that
we will gain unintentional debt.
Applications that
reference legacy or
antiquated libraries are
probably debt.
16. #craftingdigital
The causes of technical debt can be categorized into four distinct types.How to Categorize Debt
Reckless Prudent
DeliberateInadvertent
“We don’t have
time for design.”
“What’s the
single
responsibility
principle?”
“We’re just going
to have to launch
and make a plan.”
“Next time I’ll use
a new responsive
design.”
17. #craftingdigital
Always Avoid Reckless Debt
Reckless and Inadvertent Reckless and Deliberate
Real-World Examples
These real-world examples make it easier to understand how reckless debt can
occur.
19. #craftingdigital
Why Should The Business Manage Debt?
The business is not motivated by…
The business is only motivated by outcomes, not technical details. If a piece of debt has a negative impact, discuss that
with the business in non-technical, monetary terms.
“The Code
Is Crufty”
20. #craftingdigital
How To Talk About Debt
In order to fully engage with the business,
we must always express technical debt in
monetary terms.
A good strategy is to use the application’s
maintenance budget as a gauge for the
impact of technical debt.
Talk About Debt In Terms of
Money
This often requires the development team to immediately estimate the time to resolve
debt as it is incurred.
21. #craftingdigital
How To Payoff Debt
It’s a Business Decision
No matter how much we wish it wasn’t, remember
that the decision to substantially refactor is always a
business decision.
There Are 3 Options:
There are three different strategies that you can employ
when evaluating how to pay down your debt.
Debt Repayment – refactor the entire “not-
quite-right code” into something better.
Debt Conversion – replace the problem code
with a “good, but not perfect” solution.
Interest Only – choose to live with the costs of
the debt.
1
2
3
22. #craftingdigital
Consider This Example
Most of us would probably say “it depends”. Is it
raining? How far do you have to go?
There are a bunch of variables that would
determine if the solution, though not ideal, is
adequate.
Is This a Good Solution?
23. #craftingdigital
Consider This Example
What would a debt repayment look
like? Well, the best solution given
our limited space might be to simply
unpack the box and load the smaller
contents into the car individually.
Debt Repayment
24. #craftingdigital
Consider This Example
What might debt conversion
look like? We could try to make
the current situation a little
better by providing padding on
the arm rest and securing the
box with the sunroof.
Debt Conversion
25. #craftingdigital
Consider This Example
What would an interest only
solution look like? Well, we
would just choose to deal with
the current situation without
making any changes. We just
deal with the fact it’s not the best
solution.
Interest Only
26. #craftingdigital
Segregate Debt User Stories
Use a separate debt backlog
Creating a backlog for debt items that is
separate from features provides an easy way to
catalog your technical debt.
Use a Kanban Board
A Kanban or task board can be a great way to visualize and
track the technical debt you build during an iteration.
Centralized place for developers to
log debt
Provides a clean separation between
debt and features
Makes the debt accumulation
completely transparent and visible
Provides helpful insights when
compared to the feature backlog
27. #craftingdigital
Don’t Ignore the Debt
You’re Still a Professional
If you’re not active in managing your debt, your
solution will begin to look like this.
Actively look for ways to pay debt
Ignoring the debt will eventually create a huge mess.
Instead, provide developers easy ways to pay down
debt.
Allocate a Buffer Task
This is a shared task or user story provided for
each iteration where developers can log their
effort for small refactorings or improvements.
Use Clean-up Releases
A purely technical release can be used to cleanse
the codebase. These are most helpful
immediately following an aggressive or hectic
development period.
28. #craftingdigital
Enforce a Definition of Done
What does “done” really mean?
“Done” can mean different things across all project
constituents. Is it “code complete”? Has it been
tested? Has it been reviewed? What about UAT?
What is a “definition of done”?
A definition of done is a list of tasks distributed to the
entire team that clearly states when something is
“done”. It should include:
Completeness
Unit Tests
Code Review
Integration Tests
Documented
Approved
29. #craftingdigital
Build a Healthy Debt Culture
The Most Important Question: “Why”
Remember that the goal of the code review is to
learn and teach. We want to encourage
intentional coding.
Always in person with the whole team, usually at the
end of the sprint.
Only review the commits in that sprint, but everyone
comes prepared to discuss.
Author start with something their “proud” of and
something their “ashamed” of.
Avoid the mundane items that can be caught by
static code analysis or tests.
Encourage an atmosphere that celebrates code.
Mob Code Reviews: It’s Not About Quality
Code reviews are the most under utilized tool an architect
can use to foster team building and learning.
30. #craftingdigital
Refactoring Your Debt
Refactoring is a natural part of the
development process and should be
encouraged.
Refactoring Is Not a Dirty
Word
1 Current Context:
Are you currently
working with the
code?
2 Comprehension:
Can you easily
understand or
change the code?
3 Test Coverage: Do
you have sufficient
test coverage to
support the change?
31. #craftingdigital
Great Coders Love to Refactor
Watch Out for This Guy
While refactoring is natural, we must be
aware that some coders just want to re-
write everything.
Understanding that building software is like
writing a book shows us that technical debt is a
natural part of the process.
Developers are often self editing to remove
small amount of debt, even if they are doing it
without realizing it.
Refactoring is an
expected part of
coding.
32. #craftingdigital
Refactoring Goals
Improve the Overall Design
Improve Readability
Reveal Or Isolate Defects
Improve Efficiency and Organization
Why Should You Refactor?
When refactoring, it is important to keep these primary
objectives in mind:
Refactoring Should Be Incremental
To prevent refactoring from becoming
dangerous, it should always be systematic and
incremental.
Pain Driven Development
34. #craftingdigital
Maximize Signal-To-Noise Ratio
What is “Signal”?
Signal is anything in your code that has meaning
or value. If it doesn’t provide value, then it’s just
noise.
Use the TED Rule
Signal is any logic that follows the TED rule.
Terse: code should not be overly wordy.
Expressive: it should be clear what the code is
trying to do.
Do One Thing: code should have a clear
responsibility, and it should do it well.
35. #craftingdigital
Identifying Noise
Noise is in competition with signal.
Below are some examples of common noise patterns in code.
Huge Classes
Long Methods
Repetition
No Whitespaces
High Cyclomatic Complexity
Excessive indentation
Overly Verbose
Names Matter
Name selection has a huge impact on
readability. Remember, it’s about
conveying intent.
37. #craftingdigital
Refactoring Techniques
Composing Methods: The refactoring techniques in this group streamline methods, remove
code duplication, and pave the way for future improvements.
Moving Features: These refactoring techniques focus on safely moving functionality between
classes, create new classes, and hide implementation details from public access.
Organizing Data: These refactoring techniques help with data handling, replacing primitives
with rich class functionality. Another important result is untangling of class associations, which
makes classes more portable and reusable.
Simplify Conditionals: Conditionals tend to get more and more complicated in their logic over
time, and there are yet more techniques to combat this as well.
Simplify Method Calls: These techniques make method calls simpler and easier to understand.
This, in turn, simplifies the interfaces for interaction between classes.
Dealing with Generalization: Abstraction has its own group of refactoring techniques, primarily
associated with moving functionality along the class inheritance hierarchy, creating new classes
and interfaces, and replacing inheritance with delegation and vice versa.
See: https://sourcemaking.com/refactoring
38. #craftingdigital
Be Part of the Solution
“Always leave the code you’re
editing a little better than you
found it.” – Bob Martin
The Boy Scout Rule
When teams accept the responsibility for the design, the system as a whole improves over time.
As the software evolves, developers take an active approach to enhancing the system. Much like
picking up trash on the side of the road, if everyone does just a little bit, the highway remains
clean for everyone.
41. #craftingdigital
What’s Up?
Huh?
Technical Debt is Good…
Technical Debt is a phrase frequently
used to describe negative artifacts that
occur during the completion of a
development cycle.
Debt is: Bad Stuff in Our Code
Technical Debt is a metaphor used to
explain what happens during a project
that non-technologists can easily
understand.
It is Also: A Way to Communicate
The technical debt concept is really two related, but separate ideas.
42. #craftingdigital
The Power of a Metaphor
Finding Common Ground
It is often easier to explain complex ideas using
analogies, especially when communicating across
professional disciplines.
Perspective Matters
Technologists and business stakeholders have
fundamentally different perspectives. Using a common
metaphor can improve communication between them.
Technology thinks in terms of black/white
Technologists view the world in binary. Things are
either right or wrong, red or green, on or off, 0 or 1. It
either works or it doesn’t.
Business operates in infinite shades of gray
Stakeholders view the world as a series of options.
Delivery can be a varied mix of perfect and
adequate solutions.
43. #craftingdigital
Using Debt As a Tool
Remember, It’s About Value
Accruing responsible debt is perfectly
acceptable as long as your getting adequate
business value
When can debt be good?
When actively managed, introducing strategic technical
debt into a project can become a powerful tool to achieve
business objectives.
Decrease time to market
Introducing debt can shorten the amount of time it
takes to release a solution.
Maximize operating capital
Strategically accruing debt can allow the business to
prioritize tasks according to value.
Delay development expenses
It is sometimes necessary to defer high development
costs until a later date.
44. #craftingdigital
Employ Strategic Design
All parts of a system can’t have the
same high level of quality.
Therefore, the team can actively
decide which parts of the system
can accept lower quality.
Do all parts of a system
have the same quality?
46. #craftingdigital
Perfection Is the Enemy of Innovation
What is Innovation?
Innovation is one of the most over used words
in our industry. For me, innovation is the ability
to use technology in unexpected ways.
Stop Perfecting, Start Innovating
In order to innovate, you have to be willing to make
mistakes. If you spend too much time perfecting, you are
likely missing more important opportunities.
What the business thinks is innovative seems
simple to a technologist.
Furthermore, what is innovative to a
technologist is often meaningless to the
business.
47. #craftingdigital
Prove You’re a Good Coder
The Power of Perfection
A king once asked a painter, “prove you’re a good artist”. After
contemplating, he stood quietly over a piece of paper and
drew a perfect circle.
What Is the Most Innovative Thing You’ve Built?
In a job interview, I was once asked what was the most
impressive thing I’ve ever made. I love data structures,
so I answered: a non-recursive red-black tree.
49. #craftingdigital
Session Takeaways
The technical debt metaphor is a
powerful tool that can close
communication gaps. The ensures
that both technology and the
business are fully engaged in the
discussion.
Debt Is a Tool
The simple truth is that no one
is perfect. Technical debt is
going to happen, it’s
unavoidable. However, if
we’re smart about how we use
this knowledge, we can make it
work for us.
No One Is Perfect
The solution isn’t just the
responsibility of the technical
staff, but also the business.
Allowing them to engage during
the full lifecycle ensures joint
ownership of project decisions.
It’s Everyone’s
Responsibility
50. #craftingdigital
Next Steps
Remember that a little
knowledge can be dangerous.
To be a great developer, I highly
recommend these resources to
guide you towards deeper
understanding.
“If it’s work, we try
to do less. If it’s
art we try to do
more.”
– Seth Godin
51. BE BOLD +
DO GREAT WORK
steve.green@bluerivet.com
@stevepgreenkc
/stevepgreen