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.
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.
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 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?
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.
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.
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 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?
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.
Presented by David Croley at ALN Houston.
Learn about technical debt (the good and bad kind), its impact on your ability to ship working product via game format.
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.
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.
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.
Technical debt is something that most project teams or independent developers have to deal with – we take shortcuts to push out releases, deadlines need to be met, quick fixes slowly become the standard. In this talk, we will discuss what technical debt is, when it is acceptable and when it isn’t, and strategies for effectively managing it, both on an independent and team level.
Technical debt in a software system not only impacts the productivity of the team but also compromises the external product quality. Technical debt needs to be managed pragmatically to ensure discipline, value, and quality.
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.
1 in 20 IT projects deliver on time and satisfy business management.
That means 95% of IT projects are partial or total failures.
This presentation explores the causes, and potential strategies for delivering a project in the 5% bracket.
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? What do we do about it? Doc discusses the origins of the metaphor, what it means today, and how we properly identify and manage technical debt.
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.
Presented by David Croley at ALN Houston.
Learn about technical debt (the good and bad kind), its impact on your ability to ship working product via game format.
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.
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.
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.
Technical debt is something that most project teams or independent developers have to deal with – we take shortcuts to push out releases, deadlines need to be met, quick fixes slowly become the standard. In this talk, we will discuss what technical debt is, when it is acceptable and when it isn’t, and strategies for effectively managing it, both on an independent and team level.
Technical debt in a software system not only impacts the productivity of the team but also compromises the external product quality. Technical debt needs to be managed pragmatically to ensure discipline, value, and quality.
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.
1 in 20 IT projects deliver on time and satisfy business management.
That means 95% of IT projects are partial or total failures.
This presentation explores the causes, and potential strategies for delivering a project in the 5% bracket.
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? What do we do about it? Doc discusses the origins of the metaphor, what it means today, and how we properly identify and manage technical debt.
The Technical Debt Trap - Michael "Doc" NortonLeanDog
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?
What do we do about it?
Startupfest 2012 - Coefficients of frictionStartupfest
It must have been amazing to live when the steam engine was invented. For millennia, human enterprise has tried to do one thing: overcome the friction of the physical world. From the first wheel and the earliest lever, to the structure of representative government and the design of broadcast TV, we’ve been fighting friction since we crawled out of the primordial ooze. That steam engine promised spare muscle, a beast of burden than never complained. Machinery would set us free. As it turned out, we were wrong. The answer wasn’t a better way to overcome friction—it was a move to the near-frictionless world of electrons. Today, every edifice we’ve erected to fight friction is crumbling in the face of a frictionless future. Join Alistair Croll for a wild romp through the economics of abundance, augmented humanity, home manufacturing, firing before aiming, coal supplies, education, and more, and see why there is simply no better time in human history to be a disruptor.
This is a version of the talk given at Dev Bootcamp in Chicago.
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? What do we do about it? Doc discusses the origins of the metaphor, what it means today, and how we properly identify and manage technical debt.
PowerPoint Arrows Diagram Slide
Professional and Clean PowerPoint slides. Fully editable, perfect to impress your audience on your next presentation.
1. FULL HD Aspect Ratio: 16:9 (1900×1080)
2. Fully animated
3. Quickly, Easy and Fully Editable in PowerPoint (All Graphic Resizable and Editable)
4. Drag and Drop Images
5. Print Version Included (A4 Handouts Ready)
6. Retina Ready
7. Data charts (Editable via Excel)
8. Sync in SharePoint
9. Based on Master Slide
10. Pictures Placeholder Ready
11. PPTX and PPT Files
12. Vector icons as Shape
Note: Not need Photoshop – All Photos not included
QCT fantastici e dove trovarli - Crafted SoftwareThomas Rossetto
Vuoi navigare in internet? C'è il browser! Vuoi un ambiente dove poter programmare? C'è l'IDE! Vuoi parlare con il tuo team remoto sparso per il mondo? C'è Slack! Vuoi sapere se il tuo codice è di qualità? C'è... ehm... che c'è?
In questo talk Thomas ci farà un tour sulla qualità del codice, e ci racconterà la sua esperienza con dei fantastici Quality Check Tools che ha usato per non vergognarsi troppo del codice che scrive e di quale toolchain scelta lo aiuti in questa direzione.
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
JsDay - It's not you, It's me (or how to avoid being coupled with a Javascrip...Marco Cedaro
General purpose Javascript frameworks are the ones that made the language popular in the past, but right now it is a risk to think about our application development and architecture just in relation to our favorite framework.
This talk highlights risks and suggest some techniques (from design patterns to snippet of code) to avoid being coupled to a specific framework
We are in the midst of a revolution. The ways in which software and value is delivered to users and the role that very frequent user feedback plays in the development lifecycle is radically different from legacy models that had software delivered on yearly cycles. The IT processes in place today cannot meet the new demands for weekly or daily releases, so we must change them. But these existing processes are serving a purpose, ensuring the quality, robustness, security and compliance of the software.
Today’s processes are centered on the client-server architectures that have reigned since the 1990s, and as a result the steps in the software development lifecycle (SDLC) predominantly involve performing operations on servers (and storage and networks). Further, IT job functions have been established to execute those processes.
In this talk we look at key existing requirements such as security and compliance, as well as some new ones such as rapid experimentation. We will rethink processes to satisfy these requirements and propose new organizational structures to execute them (spoiler alert, it is not a plan/build/run structure). Finally, we will detail some of the requirements on the IT system architectures that will allow these marked process changes. Session participants will leave with a concrete framework for transforming current IT practices, roles and responsibilities, and a clear understanding of the key technology enablers thereof.
Case Study: VF Corporation Takes a Practical Approach to Improving its MOJO w...CA Technologies
VF Corporation, one of the largest apparel companies in the world, manages a portfolio of powerful brands including The North Face, Vans, Timberland, Jansport, Lee, Wrangler and many others. Addictive customer experience is one of the goals of VF’s Imagewear division and having systems that are available and performing well is key to building that experience. VF has been able to improve performance and minimize downtime for its ecommerce system called MOJO with minimal effort. Simple customizations, along with off-the-shelf functionality of CA Application Performance Management, have provided useful performance data to the application team to take action and deliver impressive results.
For more information, please visit http://cainc.to/Nv2VOe
Feeling bludgeoned by bullhorn messaging suggesting your monolithic behemoth should be put down (or sliced up) to make way for microservices? Without question, 'unicorn-style' microservices are the super-nova-hot flavor of the day, but what if teaching your tried and true monolith to be a nimble, fast-dancing elephant meant you could deploy every week versus every 6 to 9 months?
For most enterprises, weekly deployments (or something close) would fundamentally transform not only operations and business results, but also the inherent value of developers willing to step up to lead the dance lessons.
See beyond the hype to understand the deployment model your business case actually demands, and if weekly deployments courtesy of a dancing (or flying!) elephant fit the bill, love the one you're
We now acknowledge that complete upfront requirements is an impossible mission. Agile approaches have emerged as a way to manage the creation of systems that can never be completely defined and are certain to change.
But what about architecture and design for these systems? How much is the right amount? How do you plan for emergent design? What is the architect's role on an agile project?
Topics include:
- Role of the agile architect
- Agile design
- Keeping change easy
- Reducing technical risks
- Capturing non-functional and technical requirements and constraints
- Dealing with technical debt
- Addressing architectural concerns within the Scrum framework
- Tests – They're not just for finding bugs
- Architecture anti-patterns
https://getnobullshit.com/
Nous savons tous développer une API mais avons-nous bien intégré toutes les problématiques?
Son aspect organisationnel et humain, sa gouvernance, ses contraintes business et d'opérabilité (SLA, SLO, SLI), son release management, ses méthodes de requêtage, sa sécurité (ses performances, sa mise à l'échelle), ses différents types de test, sa documentation, son versioning (compatibilité, changelog), son monitoring — et bien plus encore — de cette API une fois en production ?
Durant ce talk, c'est plus de 30 points d'attentions rarement évoqué que je vous propose d'aborder, à la lumière de retours d'expériences provenant de tech-leader comme Uber, Stripe, Facebook et Google mais aussi d'entreprise française de la petite startup à la PME.
Similar to Agile and Beyond :: The Technical Debt Trap (20)
Agile and Beyond 2017 Presentation on Tuckman's Theory of Team Development. This theory was based on non-scientifically gathered surveys and has never been empirically proven despite dozens of scientific attempts. This talk covers why stable teams may have been a good thing and why we want to consider dynamic teams as we face new challenges.
The world as we know it is growing more complex. As we automate away those things that can be easily repeated, we leave ourselves with ever more challenging work. The way we've worked in the past won't necessarily work for today's problems¦ or will it? Join Diane and Doc as they explore dimensions of complexity in software development and look at how teams and leaders might adjust their behaviors (and the software they create) based on the complexity of the problem at hand.
This hands-on, interactive workshop will provide a practical introduction to Cynefin (a sense-making framework for complexity) and show how it applies to the work we do every day as creators of software. You'll map your own work to Cynefin and learn about applicable management styles and optimal team interactions for each of the Cynefin contexts.
Building Blocks of a Knowledge Work Culture - NDC London 2016Doc Norton
Re-designed presentation on Autonomy, Connection, Excellence, and Diversity. This version shows a bit more about the management styles appropriate in different domains of complexity, connects knowledge work to Complicated and Complex, and then walks through the Building Blocks.
Even high functioning teams occasionally have a hard time making decisions or coming up with creative ideas. There are times when the conversation seems to drag on long after a decision is reached. There are times when we have too many people involved in the discussion or the wrong people involved. There are times when we’re not sure whose the actual decision maker. And there are those times when we just seem to be out of synch with each other. This creative collaboration workshop provides tools that help resolve all of these issues.
Among the traits that distinguish a good team from a great team is their ability to innovate. Despite the rhetoric in favor of innovation, most organizations are stuck in an implementation mindset, stifling creativity, excellence, and the resultant innovation. The experimentation mindset frees us from self-imposed constraints, allowing us to continually learn and improve. In this session, we'll talk about how we learn as individuals and how we learn as organizations. We'll take a look at some examples of the experimentation mindset happening in the agile community today and we'll talk about how you can foster such a mindset in your own organization.
Switching horses midstream - From Waterfall to AgileDoc Norton
You’ve been working for several months on a key software initiative for the company and leadership has decided they want it faster than projected, so the team has been told they’re getting “the agile” installed next week.
“Great.”, you think, “Right in the middle of the project. Nothing like changing horses in midstream. One way or another, this will go swimmingly.”
Sarcasm and puns aside, you’ve got a point. It isn’t easy to switch methodologies in the middle of a project. Doc shares some stories from his own experiences helping teams make this change and provides a few pointers that can help you do the same.
While this talk is focused on testing, it involves the whole team, as agile methods usually do.
Autonomy, Connection, and Excellence; The Building Blocks of a DevOps CultureDoc Norton
DevOps, to a great extent, is about people working together. Without true cross-discipline collaboration, the full value of DevOps cannot be realized.
But you can’t just mandate collaboration. Many organizations do more than separate developers and operations, they design systems, metrics, and rewards that make the two seem like natural enemies. “They don’t get it.”, you hear from both sides.
In this talk, Doc will take a look at what motivates teams, how our systems produce the exact results we design them to produce, and how we can use simple (but not necessarily easy) techniques to counter years of “us versus them” conditioning.
From NDC Oslo 2015 - Workshop with Denise Jacobs, Doc Norton, and Carl Smith
Even high functioning teams occasionally have a hard time making decisions or coming up with creative ideas. There are times when the conversation seems to drag on long after a decision is reached. There are times when we have too many people involved in the discussion or the wrong people involved. There are times when we're not sure whose the actual decision maker. And there are those times when we just seem to be out of synch with each other. This creative collaboration workshop provides tools that help resolve all of these issues. Come have some laughs with Denise, Doc, and Carl, play with new friends, and learn one or two new techniques you can try at home.
SDEC 2014 Keynote - Among the traits that distinguish a good team from a great team is their ability to innovate. And despite the rhetoric in favor of innovation, most organizations are stuck in an implementation mindset, stifling creativity, excellence, and the resultant innovation. The experimentation mindset frees us from self-imposed constraints, allowing us to continually learn and improve.
Agile Metrics : Velocity is NOT the Goal - NDC Oslo 2014Doc Norton
Velocity is one of the most common metrics used-and one of the most commonly misused-on agile projects. Velocity is simply a measurement of speed in a given direction-the rate at which a team is delivering toward a product release. As with a vehicle en route to a particular destination, increasing the speed may appear to ensure a timely arrival. However, that assumption is dangerous because it ignores the risks with higher speeds. And while it’s easy to increase a vehicle’s speed, where exactly is the accelerator on a software team?
Michael “Doc" Norton walks us through the Hawthorne Effect and Goodhart’s Law to explain why setting goals for velocity can actually hurt a project's chances. Take a look at what can negatively impact velocity, ways to stabilize fluctuating velocity, and methods to improve velocity without the risks. Leave with a toolkit of additional metrics that, coupled with velocity, give a better view of the project's overall health.
How does the common cold spread through a group of friends or co-workers. What about other contagions? Can a contagion be used for good? Doc explores how things like disease, politics, and even moods travel through (meat-space) social networks. What impact do we have on others? What impact do they have on us? And what does this mean for members of the software development community?
Teamwork ain’t always easy. From meetings where everybody has something to say but nothing gets done to poor decisions being made because the most senior or most forceful team member won the argument; sometimes you long for the days of high-walled cubicles and lone ranger coding. Long no more.
In this workshop, you will learn a few simple techniques that drastically improve a team’s ability to work together toward common goals with less conflict and more genuine collaboration.
Creating a Global Engineering Culture - Agile india 2014Doc Norton
A short (and incomplete) telling of how we got to where we are as an engineering organization for Groupon. A little philosophy about what motivates individuals and teams. And finally a little bit about what we're doing at Groupon.
When it comes to creating a global culture, remember that you are more archeologist than architect. Uncover the good that is already happening and help to share it rather than trying to design something new.
Love is a Contagion. Let's Start an Epidemic.
This is the slide deck to go along with the Keynote I gave at That Conference in August 2013. This talk is all about the stories. The visuals support the stories told, but do not tell them on their own. I will add details to my blog and may upload another version of the slide deck with notes.
Agile Metrics: Velocity is NOT the Goal - Agile 2013 versionDoc Norton
A newly formatted version of "Velocity is NOT the Goal" for Agile 2013. I've removed some details about standard deviation, added a few more thoughts around the "psychology" of setting targets for metrics, and show a bit more about how we do this at Groupon.
Code PaLOUsa rendition of Velocity is NOT the Goal.
Velocity is one of the most common metrics used—and one of the most commonly misused—on agile projects. Velocity is simply a measurement of speed in a given direction—the rate at which a team is delivering toward a product release. As with a vehicle en route to a particular destination, increasing the speed may appear to ensure a timely arrival. However, that assumption is dangerous because it ignores the risks with higher speeds. And while it’s easy to increase a vehicle’s speed, where exactly is the accelerator on a software team? Michael “Doc" Norton walks us through the Hawthorne Effect and Goodhart’s Law to explain why setting goals for velocity can actually hurt a project's chances. Take a look at what can negatively impact velocity, ways to stabilize fluctuating velocity, and methods to improve velocity without the risks. Leave with a toolkit of additional metrics that, coupled with velocity, give a better view of the project's overall health.
Teamwork ain’t always easy. From meetings where everybody has something to say but nothing gets done to poor decisions being made because the most senior or most forceful team member won the argument; sometimes you long for the days of high-walled cubicles and lone ranger coding. Long no more.
In this workshop, you will learn about two simple techniques that drastically improve a team’s ability to work together toward common goals with less conflict and more genuine collaboration.
Updated version of this talk as presented at Pacific Northwest Software Quality Conference in 2012. This is a longer version, including content on scatter diagrams and standard deviation.
Growing Into Excellence talk given at the Pacific Northwest Software Quality Conference. This is yet another version on this theme. A little more on Collaboration 8 and Six Thinking Hats along with new material from Dave Hoover on stretching into incompetence.
Search and Society: Reimagining Information Access for Radical FuturesBhaskar Mitra
The field of Information retrieval (IR) is currently undergoing a transformative shift, at least partly due to the emerging applications of generative AI to information access. In this talk, we will deliberate on the sociotechnical implications of generative AI for information access. We will argue that there is both a critical necessity and an exciting opportunity for the IR community to re-center our research agendas on societal needs while dismantling the artificial separation between the work on fairness, accountability, transparency, and ethics in IR and the rest of IR research. Instead of adopting a reactionary strategy of trying to mitigate potential social harms from emerging technologies, the community should aim to proactively set the research agenda for the kinds of systems we should build inspired by diverse explicitly stated sociotechnical imaginaries. The sociotechnical imaginaries that underpin the design and development of information access technologies needs to be explicitly articulated, and we need to develop theories of change in context of these diverse perspectives. Our guiding future imaginaries must be informed by other academic fields, such as democratic theory and critical theory, and should be co-developed with social science scholars, legal scholars, civil rights and social justice activists, and artists, among others.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
"Impact of front-end architecture on development cost", Viktor TurskyiFwdays
I have heard many times that architecture is not important for the front-end. Also, many times I have seen how developers implement features on the front-end just following the standard rules for a framework and think that this is enough to successfully launch the project, and then the project fails. How to prevent this and what approach to choose? I have launched dozens of complex projects and during the talk we will analyze which approaches have worked for me and which have not.
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
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
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.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...
Agile and Beyond :: The Technical Debt Trap
1. The Technical Debt Trap
Michael J Norton
@DocOnDev
LeanDog LLC*
*The views expressed are not necessarily the views of LeanDog LLC
(but they could be)
5. What is Technical Debt?
Ward Cunningham
Shipping first time code is
like going into debt.
oopsla’92
6. What is Technical Debt?
Ward Cunningham
Shipping first time code is
like going into debt.
A little debt speeds
development so long
as it is paid back
promptly with a
rewrite.
oopsla’92
7. What is Technical Debt?
Ward Cunningham
The danger occurs
when the debt is not
repaid.
Every minute spent on not-
quite-right code counts as
interest on that debt.
oopsla’92
8. What is Technical Debt?
Ward Cunningham
The danger occurs
when the debt is not
repaid.
Every minute spent on not-
quite-right code counts as
interest on that debt.
oopsla’92
14. Metaphors Rock
We reason by analogy
Can’t keep running
at this pace
Building on a weak foundation
Puts pressure on
It’s raining men our design
15. Metaphors Rock
We reason by analogy
Can’t keep running
at this pace
Building on a weak foundation
Puts pressure on
It’s raining men our design
(hallelujah)
17. Metaphorphosis
When Metaphors go wrong
Return on Investment
Short-Term Fraudulent Credit Card
Inadvertent RecklessScheme
Pyramid Debt
Auto Loan
High Interest in the Third Quadrant
Home Loan Voluntary
Intentional Loan Shark Long-Term
Prudent Student Loan
Pragmatic Leverage Operational
19. Metaphorphosis
When Metaphors go wrong
“cut a lot of corners”
James Shore
http://jamesshore.com/Blog/CardMeeting/Voluntary-Technical-Debt.html
“quick and dirty”
Martin Fowler
“sloppy”
http://www.martinfowler.com/bliki/TechnicalDebt.html
David Laribee “just hack it in”
http://msdn.microsoft.com/en-us/magazine/ee819135.aspx
Steve McConnell
http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
21. That’s not what I said
Ward Cunningham
[Many] have explained the debt metaphor
and confused it with the idea that
you could write code poorly with
the intention of doing a good job later.
http://www.youtube.com/watch?v=pqeJFYwnkjE&feature=player_embedded youtube.com 2009
22. That’s not what I said
Ward Cunningham
[Many] have explained the debt metaphor
and confused it with the idea that
you could write code poorly with
the intention of doing a good job later.
http://www.youtube.com/watch?v=pqeJFYwnkjE&feature=player_embedded youtube.com 2009
23. That’s not what I said
Ward Cunningham
... confused it with
the idea that you
could write code
poorly ... youtube.com 2009
24. Clean Code is Required
Ward Cunningham
The ability to pay back debt [...]
depends upon you writing code that
is clean enough to be able to refactor
as you come to understand your
problem. youtube.com 2009
25. Clean Code is Required
Ward Cunningham
The ability to pay back debt [...]
depends upon you writing code that
is clean enough to be able to
refactor as you come to
understand your problem. youtube.com 2009
26. Dirty Code is a Bad Idea
Ward Cunningham
Dirty code is to technical debt as the
pawn broker is to financial debt.
Don't think you are ever going to get
your code back.
http://twitter.com/WardCunningham/status/3742903303 twitter 2009
27. Is it Technical Debt?
Ask yourself...
Is the code clean?
Is the code tested?
Is there a learning objective?
Is there a plan for payback?
Is the business truly informed?
28. Is it Technical Debt?
If you said no to even one
Is the code clean?
Is the code tested?
Is there a learning objective?
Is there a plan for payback?
Is the business truly informed?
Then you don’t have Technical Debt
29. You have a mess
Mess (noun)
1. Disorderly accumulation, heap, or jumble
2. A state of embarrassing confusion
3. An unpleasant or difficult situation
30. You have cruft
Cruft (noun)
1. An unpleasant substance
2. The result of shoddy construction
3. Redundant, old or improperly written code
39. “Technical Debt”
in Other Industries
Construction
http://www.constructionmanagementschools.net/wp-content/uploads/2010/04/construction-mistakes-18.jpg
40. “Technical Debt”
in Other Industries
Construction
Reckless and Deliberate
http://www.constructionmanagementschools.net/wp-content/uploads/2010/04/construction-mistakes-18.jpg
41. “Technical Debt”
in Other Industries
Automotive
http://blog.ivman.com/wp-content/HomeRepair.jpg
42. “Technical Debt”
in Other Industries
Automotive
Reckless and Deliberate
http://blog.ivman.com/wp-content/HomeRepair.jpg
43. “Technical Debt”
in Other Industries
Medical
http://www.scientificamerican.com/media/inline/blog/Image/MedicalError.jpg
44. “Technical Debt”
in Other Industries
Medical
Reckless and Inadvertent
http://www.scientificamerican.com/media/inline/blog/Image/MedicalError.jpg
53. Cruft or Debt?
double getSpeed() {
switch (_type) {
case EUROPEAN:
return getBaseSpeed();
case AFRICAN:
return getBaseSpeed() - getLoadFactor() * _numberOfCoconuts;
case NORWEGIAN_BLUE:
return (_isNailed) ? 0 : getBaseSpeed(_voltage);
}
throw new RuntimeException ("Should be unreachable");
}
http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html
54. Cruft or Debt?
class Swallow ...
double getSpeed() { return getBaseSpeed(); }
end class
class EuropeanSwallow ...
end class
class AfricanSwallow ...
double getSpeed() { return super.getSpeed - coconutLoad(); }
double coconutLoad() { return getLoadFactor() * _numberOfCoconuts; }
end class
class NorwegianSwallow ...
double getSpeed() { return (_isNailed) ? 0:getBaseSpeed(_voltage); }
end class
56. Messy Code is a Bad Decision
Every Time
You are a professional developer
(Professionals behave ethically)
57. Messy Code is a Bad Decision
Every Time
You are a professional developer
(Professionals behave ethically)
You are going to create unintentional cruft
(You can’t help it. It’s unintentional.)
58. Messy Code is a Bad Decision
Every Time
You are a professional developer
(Professionals behave ethically)
You are going to create unintentional cruft
(You can’t help it. It’s unintentional.)
You have to clean up the existing cruft
(Intent doesn’t alter Responsibility)
61. The Trap
Mess begets mess
Precedent for Speed over Quality
Expectation of increased velocity
Mess slows you down
Must generate more mess to keep up
62. The Trap
Mess begets mess
Precedent for Speed over Quality
Expectation of increased velocity
Mess slows you down
Must generate more mess to keep up
Ask permission to do your job correctly
63. Avoid The Trap
Incremental Fixes Fail
http://www.jacoozi.com/blog/wp-content/uploads/2007/01/refactoring_coc_big.jpg
65. Avoid The Trap
Clean Constantly
Never make an intentional mess
Monitor your “Technical Debt”
Follow the Boy Scout Rule
Quality is your responsibility
66. Avoid The Trap
Clean Constantly
Never make an intentional mess
Monitor your “Technical Debt”
Follow the Boy Scout Rule
Quality is your responsibility
NEVER ask permission to do your job correctly
70. Monitoring Cruft/Debt
Code Coverage
Code exercised by automated tests
Monitor test types separately
Don’t set a coverage target
100% Coverage is a smell
71. Monitoring Cruft/Debt
Code Coverage
Code exercised by automated tests
Monitor test types separately
Don’t set a coverage target
100% Coverage is a smell
Monitor trends, not points
74. Monitoring Cruft/Debt
Cyclomatic Complexity
Number of logical branches in code
Direct relationship with bugs
Typically high in concentrated areas
Reduce Conditionals
Monitor trends, not points
82. Review
Technical Debt
Is a strategic design decision
Requires the business to be informed
Requires a pay-back plan - (Clean Code)
Cruft
83. Review
Technical Debt
Is a strategic design decision
Requires the business to be informed
Requires a pay-back plan - (Clean Code)
Cruft
Happens
Needs to be monitored and cleaned
Is (probably) NOT Technical Debt
85. Thank You!
The Technical Debt Trap
Michael J Norton
@DocOnDev
LeanDog LLC*
doc@leandog.com
*The views expressed are not necessarily the views of LeanDog LLC
(but they could be)
Editor's Notes
\n
\n
\n
\n
\n
\n
\n
\n
\n
Design decisions that allow for more rapid delivery / illicit quick feedback / gather data necessary to correct design\n
- Sales site for complex product. Create product configuration views.\n- Plan to sell several different products. Starting with just one. Don’t extract interface yet.\n\n\n
- Sales site for complex product. Create product configuration views.\n- Plan to sell several different products. Starting with just one. Don’t extract interface yet.\n\n\n
- Sales site for complex product. Create product configuration views.\n- Plan to sell several different products. Starting with just one. Don’t extract interface yet.\n\n\n
\n
\n\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
This is not a loan from a loan shark\n\nHow do we end up in massive high-interest debt unwittingly?\nrobbery or larceny or fraud\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
"We incurred structural debt in order to meet your deadline. We should discuss that debt and set a plan for paying it back later."\n
"We incurred mechanical debt to stay in budget. We should get metrics around that and make sure we pay the debt down in the future."\n
"We incurred health debt during the surgery. You see, it is like we paid for the surgery with a credit card instead of a home equity loan..."\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Not acceptable to violate accounting practices, violate safety laws, or risk patient’s health\n\n
Not acceptable to violate accounting practices, violate safety laws, or risk patient’s health\n\n
Not acceptable to violate accounting practices, violate safety laws, or risk patient’s health\n\n
Not acceptable to violate accounting practices, violate safety laws, or risk patient’s health\n\n
Not acceptable to violate accounting practices, violate safety laws, or risk patient’s health\n\n
Not acceptable to violate accounting practices, violate safety laws, or risk patient’s health\n\n
\n
\n
\n
\n
\n
\n
\n
Ruby - churn => volume of changes\ngit - gitswarm => visual history of changes\nJava - Cobertura or Sonar\n
Ruby - churn => volume of changes\ngit - gitswarm => visual history of changes\nJava - Cobertura or Sonar\n
Ruby - churn => volume of changes\ngit - gitswarm => visual history of changes\nJava - Cobertura or Sonar\n
Ruby - churn => volume of changes\ngit - gitswarm => visual history of changes\nJava - Cobertura or Sonar\n
Ruby - churn => volume of changes\ngit - gitswarm => visual history of changes\nJava - Cobertura or Sonar\n