Dissolving Technical Debt on Agile Projects - Smidig 2012

•

1 recomendación•526 vistas

Experiences with dealing with legacy code while delivering value. Key points: 1) Legacy code costs a lot. 2) Design must be maintained & evolved. 3) Continous refactoring during each task is a way to achieve 2.

Tecnología

An Agile Approach to
Technical Debt
Is The Only Way

Jakub Holý @ iterate no

by Jon Baldock nz @ flickr

We've all been there - mess of code

by Ignaz Wiradi @ wikimedia

What we would like to have
- clean, structured, fitting

by cotallo-nonocot @ flickr

What we do have. It (likely) started with st. small & clean but requirements evolved
while the design of the code did not - only hacked & patched

God class
● 15 kLOC
● 300 properties
● 320 methods
● 50 constants
● used everywhere

by mandalinarossa @ flickr

Example of legacy - a typical monstrous god class that we were confronted with.

True cost of legacy

Pain <= Time wasted in code archeology, money & time wasted due to bugs being
introduced.
Legacy code matters to business for real money are wasted there.

Refactor!

The only way out is to improve the design

?

How do we get from L to R? The sad answer is we don't.
It took centuries to build R. We can never get from L to R in a reasonable time. There
is too much mess, too much to fix.

Code Churn

Michael Feathers: Getting Empirical about Refactoring

Code-churn driven refactoring: improve where it matters & pays off most - complex &
changed often

=> Boy Scout Refactoring
● Only task-related
● Time-boxed
● Always
● (+ TDD)

Refactoring can go on forever => focus, time-box. Task related => in code that
matters most now/in near future. (We: 1/3 every task devoted to refactoring.)

Refactoring: Improving the Design of Existing
Code
Martin Fowler

Working Effectively with Legacy Code
Michael Feathers

Behead Your Legacy Beast: The Mikado
Method
D. Brolund, O. Ellnestam

True cost of legacy

Show to your management; Legacy code = lot of money lost.

Challenge
Large-scale refactorings
● risky => avoid
● sometimes necessary
● boy scout rule doesn't help

Summary
● Design needs love
● Continuous, focused, time-boxed refactoring
● True cost of legacy

Recommended

Retrospectives: Group code reviews:

改 Observe
Evaluate
Teach
Learn
善 Adjust Unify

Something that worked great for us

Questions?

@HolyJak
jakub.holy@iterate.no
theholyjava.wordpress.com

Más contenido relacionado

Similar a Dissolving Technical Debt on Agile Projects - Smidig 2012

Devconf 2011 - PHP - How Yii framework is developed

Alexander Makarov

The ninth principle from the Agile Manifesto states that technical excellence enhances agility, but when the codebase is ugly and the deadlines are tight, most teams don’t choose to refactor mercilessly, adopt TDD, or evaluate automated testing tools—unless they have the proper support. In our experience working with multiple teams in a single codebase, developers can feel victim to a legacy codebase if only a few people are writing clean code or refactoring; guiding them on how to decrease technical debt while delivering their projects helps "unstuck" their other agile practices. We will talk about the challenges we’ve seen with Product Owners, Managers, and Scrum Masters interacting with teams at various stages of agile+technical excellence and how a focus on technical practices sparked a wider interest in craftsmanship. Learn how can you influence the team towards the right practices while fostering their sense of ownership. Getting serious about technical excellence requires support from technical and non-technical roles, and we’ll share how we partnered as coaches to help an organization through a technical turnaround with some tips for others who need to do the same.

Technical Excellence Doesn't Just Happen--Igniting a Craftsmanship Culture

Allison Pollard

Big Ball of Mud (BBoM) architectures are viewed as the culmination of many design decisions that, over time, result in a system that is hodgepodge of steaming and smelly anti-patterns. It can be arguably claimed that one of the reasons for the growth and popularity of agile practices is partially due to the fact that the state of the art of software architectures was not that good. Being agile, with its focus on extensive testing and frequent integration, has shown that it can make it easier to deal with evolving architectures (possibly muddy) and keeping systems working while making significant improvements and adding functionality. Time has also shown that Agile practices are not sufficient to prevent or eliminate Mud. It is important to recognize what is core to the architecture and the problem at hand when evolving an architecture. This talk will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. I’ll explore what agile practices can help us avoid or cope with mud. I’ll also explain why continuous delivery and TDD with refactoring is not enough to help ensure clean architecture and why it is important to understand what is core to the architecture and the problem at hand. Understanding what changes in the system and at what rates can help you prevent becoming mired in mud. By first understanding where a system’s complexities are and where it keeps getting worse, we can then work hard (and more intelligently) at sustaining the architecture. This can become a key value to the agile team. The results will leave attendees with practices and patterns that help clean your code (refactor) as well as keeping the code clean or from getting muddier. Additionally, I’ll talk about some practices and patterns that help keep the code clean or from getting muddier. Some of these include: Testing, Divide & Conquer, Gentrification, Demolition, Quarantine, Refactoring, Craftmanship and the like.. The original Big Ball of Mud paper described some best practices such as SHEARING LAYERS and SWEEPING IT UNDER THE RUG as a way to help deal with muddy architectures. Additionally there are some other practices such as PAVING OVER THE WAGON TRAIL and WIPING YOUR FEET AT THE DOOR that can make code more habitable.

Taming Big Balls of Mud with Diligence, Agile Practices, and Hard Work

Joseph Yoder

Code Refactoring - Live Coding Demo (JavaDay 2014)

Peter Kofler

Technical Excellence Doesn't Just Happen - AgileIndy 2016

Allison Pollard

Have you always heard about refactor and it always sounded like a foreign language to you? Have you tried to change code several times but found it impossible to make such changes in several projects? Do you feel overwhelmed when working with legacy code? Let's see the benefits of refactoring your code and see some tips on how to do it safely! We will start talking about what is legacy code, what we understand about refactoring and why it is so important nowadays when in most cases we work with software that others have written. Later we will share when we should start thinking on refactoring code and next we will see some recommended techniques to work with legacy code, which will even help us to know where to start and how. And finally, we will see in a live coding session some of the most important and useful refactoring techniques we could apply in our day-to-day job  At the end of this session, I hope you may have learned some tips on how to work with legacy code and how to apply certain techniques to make your day to day more enjoyable ;-) === * Presentation shared at Jconf Mexico (October 3rd, 2020) - https://convoca.dev/jconf-mexico-2020/talk/FMDT8Z/ and revisited and updated for sharing at JConf Centro América (December 5th, 2020) https://hopin.to/events/jconf-centroamerica-2020

Refactor your code: when, why and how (revisited)

Nacho Cougil

Coding Dojo for Testers/Testing Dojo: Designing Test Cases with FitNesse (2014)

Peter Kofler

Deliberate Practice (2014)

Peter Kofler

Legacy Code. I never wrote it; everybody else did! How many times have you waded through an ageing, decaying, tangled forrest of code and wished it would just die? How many times have you heard someone say that what really needs to happen is a complete rewrite? I have heard this many times, and, have uttered that fatal sentence myself. But shouldn’t we love our legacy code? Doesn’t it represent our investment and the hard work of ourselves and our predecessors? Throwing it away is dangerous, because, before we do, we’ll need to work out exactly what it does, and we’ll need to tweeze out that critical business logic nestled in a deeply entangled knot of IF statements. It could take us years to do, and we’ll have to maintain two systems whilst we do it, inevitably adding new features to them both. Yes we get to reimplement using the latest, coolest programming language, instead of an old behemoth, but how long will our new cool language be around, and who will maintain that code, when it itself inevitably turns to legacy? We can throw our arms in the air, complaining and grumbling about how we didn’t write the code, how we would never have written it the way it is, how those that wrote it were lesser programmers, possibly lesser humans themselves, but the code still remains, staring us in the face and hanging around for longer that we could possibly imagine. We can sort it out, we can improve it, we can make it testable, and we can learn to love our legacy code.

How I Learned to Stop Worrying and Love Legacy Code.....

Mike Harris

Workshop fight legacy code write unit test

Tung Nguyen Thanh

[XPday.vn] Legacy code workshop (at) [XP Day Vietnam 2015]

Agile đây Vietnam

The bigrewrite

Codecamp Romania

"Why should we write our tests first? Isn't that going to slow my development?" "What? Assigning a single task to 2 developers? How is that efficient? What a waste of resources!" "Look, in the perfect world your advises are great, but I have a project to finish here." In this talk Marcello explores efficiency in contrast to effectiveness. He looks into how practices, traditionally accepted as efficient, sometimes turn out to be less effective than a few "impractical" things he has come across.

Pair Programming, TDD and other impractical things

Marcello Duarte

Effective entrepreneurship for developers

Carlos Ble

The bigrewrite

Codecamp Romania

From Journeyman to Master

Angad Singh

Our industry has a problem: We are not lacking software methodologies, programming languages, tools or frameworks but we need great software engineers. Great software engineer teams build quality-in and deliver great software on a regular basis. The technical excellence of those engineers will help you escape the "Waterfall sandwich" and make your organization a little more agile, from the inception of an idea till they go live. I will talk about my experiences from the last 15 years, including small software delivery teams until big financial institutions. Why would a company like to be "agile"? How can a company achieve that? How can you achieve Technical Excellence in your software teams? What developer skills are more important than languages, methods or frameworks? This will be an interactive session with a Q&A at the end.

Achieving Technical Excellence in Your Software Teams - from Devternity

Peter Gfader

Docker is killing your #devops Efforts

Kris Buytaert

Coding Dojo Firenze - vol1

Massimo Iacolare

Designing Test Cases for the Gilded Rose Kata (2013)

Peter Kofler

Similar a Dissolving Technical Debt on Agile Projects - Smidig 2012 (20)

Devconf 2011 - PHP - How Yii framework is developed

Technical Excellence Doesn't Just Happen--Igniting a Craftsmanship Culture

Taming Big Balls of Mud with Diligence, Agile Practices, and Hard Work

Code Refactoring - Live Coding Demo (JavaDay 2014)

Technical Excellence Doesn't Just Happen - AgileIndy 2016

Refactor your code: when, why and how (revisited)

Coding Dojo for Testers/Testing Dojo: Designing Test Cases with FitNesse (2014)

Deliberate Practice (2014)

How I Learned to Stop Worrying and Love Legacy Code.....

Workshop fight legacy code write unit test

[XPday.vn] Legacy code workshop (at) [XP Day Vietnam 2015]

The bigrewrite

Pair Programming, TDD and other impractical things

Effective entrepreneurship for developers

The bigrewrite

From Journeyman to Master

Achieving Technical Excellence in Your Software Teams - from Devternity

Docker is killing your #devops Efforts

Coding Dojo Firenze - vol1

Designing Test Cases for the Gilded Rose Kata (2013)

Último

Artificial Intelligence Chap.5 : Uncertainty

Khushali Kathiriya

Dubai, often portrayed as a shimmering oasis in the desert, faces its own set of challenges, including the occasional threat of flooding. Despite its reputation for opulence and modernity, the emirate is not immune to the forces of nature. In recent years, Dubai has experienced sporadic but significant floods, testing the resilience of its infrastructure and communities. Among the critical lifelines in this bustling metropolis is the Dubai International Airport, a bustling hub that connects the city to the world. This article explores the intersection of Dubai flood events and the resilience demonstrated by the Dubai International Airport in the face of such challenges.

Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...

Orbitshub

How to Troubleshoot Apps for the Modern Connected Worker

ThousandEyes

MS Copilot expands with MS Graph connectors

Nanddeep Nachan

Scaling API-first – The story of a global engineering organization Ian Reasor, Senior Computer Scientist - Adobe Radu Cotescu, Senior Computer Scientist - Adobe Apidays New York 2024: The API Economy in the AI Era (April 30 & May 1, 2024) ------ Check out our conferences at https://www.apidays.global/ Do you want to sponsor or talk at one of our conferences? https://apidays.typeform.com/to/ILJeAaV8 Learn more on APIscene, the global media made by the community for the community: https://www.apiscene.io Explore the API ecosystem with the API Landscape: https://apilandscape.apiscene.io/

Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe

apidays

Elevate Developer Efficiency & build GenAI Application with Amazon Q

Bhuvaneswari Subramani

EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER

MadyBayot

Webinar Recording: https://www.panagenda.com/webinars/why-teams-call-analytics-is-critical-to-your-entire-business Nothing is as frustrating and noticeable as being in an important call and being unable to see or hear the other person. Not surprising then, that issues with Teams calls are among the most common problems users call their helpdesk for. Having in depth insight into everything relevant going on at the user’s device, local network, ISP and Microsoft itself during the call is crucial for good Microsoft Teams Call quality support. To ensure a quick and adequate solution and to ensure your users get the most out of their Microsoft 365. But did you know that ‘bad calls’ are also an excellent indicator of other problems arising? Precisely because it is so noticeable!? Like the canary in the mine, bad calls can be early indicators of problems. Problems that might otherwise not have been noticed for a while but can have a big impact on productivity and satisfaction. Join this session by Christoph Adler to learn how true Microsoft Teams call quality analytics helped other organizations troubleshoot bad calls and identify and fix problems that impacted Teams calls or the use of Microsoft365 in general. See what it can do to keep your users happy and productive! In this session we will cover - Why CQD data alone is not enough to troubleshoot call problems - The importance of attributing call problems to the right call participant - What call quality analytics can do to help you quickly find, fix-, and prevent problems - Why having retrospective detailed insights matters - Real life examples of how others have used Microsoft Teams call quality monitoring to problem shoot problems with their ISP, network, device health and more.

Why Teams call analytics are critical to your entire business

panagenda

AWS Community Day CPH - Three problems of Terraform

Andrey Devyatkin

CNIC Information System with Pakdata Cf In Pakistan

danishmna97

Strategies for Landing an Oracle DBA Job as a Fresher

Remote DBA Services

FWD Group - Insurer Innovation Award 2024

The Digital Insurer

Six Myths about Ontologies: The Basics of Formal Ontology

johnbeverley2021

💥 You’re lucky! We’ve found two different (lead) developers that are willing to share their valuable lessons learned about using UiPath Document Understanding! Based on recent implementations in appealing use cases at Partou and SPIE. Don’t expect fancy videos or slide decks, but real and practical experiences that will help you with your own implementations. 📕 Topics that will be addressed: • Training the ML-model by humans: do or don't? • Rule-based versus AI extractors • Tips for finding use cases • How to start 👨‍🏫👨‍💻 Speakers: o Dion Morskieft, RPA Product Owner @Partou o Jack Klein-Schiphorst, Automation Developer @Tacstone Technology

DEV meet-up UiPath Document Understanding May 7 2024 Amsterdam

UiPathCommunity

MINDCTI Revenue Release Quarter One 2024

MIND CTI

The microservices honeymoon is over. When starting a new project or revamping a legacy monolith, teams started looking for alternatives to microservices. The Modular Monolith, or 'Modulith', is an architecture that reaps the benefits of (vertical) functional decoupling without the high costs associated with separate deployments. This talk will delve into the advantages and challenges of this progressive architecture, beginning with exploring the concept of a 'module', its internal structure, public API, and inter-module communication patterns. Supported by spring-modulith, the talk provides practical guidance on addressing the main challenges of a Modultith Architecture: finding and guarding module boundaries, data decoupling, and integration module-testing. You should not miss this talk if you are a software architect or tech lead seeking practical, scalable solutions. About the author With two decades of experience, Victor is a Java Champion working as a trainer for top companies in Europe. Five thousands developers in 120 companies attended his workshops, so he gets to debate every week the challenges that various projects struggle with. In return, Victor summarizes key points from these workshops in conference talks and online meetups for the European Software Crafters, the world’s largest developer community around architecture, refactoring, and testing. Discover how Victor can help you on victorrentea.ro : company training catalog, consultancy and YouTube playlists.

Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024

Victor Rentea

Boost Fertility New Invention Ups Success Rates.pdf

sudhanshuwaghmare1

ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke

Product Anonymous

Understanding the FAA Part 107 License ..

Christopher Logan Kennedy

Dubai, known for its towering skyscrapers, luxurious lifestyle, and relentless pursuit of innovation, often finds itself in the global spotlight. However, amidst the glitz and glamour, the emirate faces its own set of challenges, including the occasional threat of flooding. In recent years, Dubai has experienced sporadic but significant floods, disrupting normalcy and posing unique challenges to its infrastructure. Among the critical nodes in this bustling metropolis is the Dubai International Airport, a vital hub connecting the world. This article delves into the intersection of Dubai flood events and the resilience demonstrated by the Dubai International Airport in the face of such challenges.

Rising Above_ Dubai Floods and the Fortitude of Dubai International Airport.pdf

Orbitshub

Dissolving Technical Debt on Agile Projects - Smidig 2012

1. An Agile Approach to Technical Debt Is The Only Way Jakub Holý @ iterate no

2. Origins

3. by Jon Baldock nz @ flickr We've all been there - mess of code

4. by Ignaz Wiradi @ wikimedia What we would like to have - clean, structured, fitting

5. by cotallo-nonocot @ flickr What we do have. It (likely) started with st. small & clean but requirements evolved while the design of the code did not - only hacked & patched

6. God class ● 15 kLOC ● 300 properties ● 320 methods ● 50 constants ● used everywhere by mandalinarossa @ flickr Example of legacy - a typical monstrous god class that we were confronted with.

7. The pain! It was pain!

8. True cost of legacy Pain <= Time wasted in code archeology, money & time wasted due to bugs being introduced. Legacy code matters to business for real money are wasted there.

9. Escape???

10. Refactor! The only way out is to improve the design

11. ? How do we get from L to R? The sad answer is we don't. It took centuries to build R. We can never get from L to R in a reasonable time. There is too much mess, too much to fix.

12. Code Churn Michael Feathers: Getting Empirical about Refactoring Code-churn driven refactoring: improve where it matters & pays off most - complex & changed often

13. => Boy Scout Refactoring ● Only task-related ● Time-boxed ● Always ● (+ TDD) Refactoring can go on forever => focus, time-box. Task related => in code that matters most now/in near future. (We: 1/3 every task devoted to refactoring.)

14. Refactoring: Improving the Design of Existing Code Martin Fowler Working Effectively with Legacy Code Michael Feathers Behead Your Legacy Beast: The Mikado Method D. Brolund, O. Ellnestam

15. It worked!

16. Required: Management endorsement

17. True cost of legacy Show to your management; Legacy code = lot of money lost.

18. Challenge Large-scale refactorings ● risky => avoid ● sometimes necessary ● boy scout rule doesn't help

19. Summary ● Design needs love ● Continuous, focused, time-boxed refactoring ● True cost of legacy

20. You too can do it!

21. Recommended Retrospectives: Group code reviews: 改 Observe Evaluate Teach Learn 善 Adjust Unify Something that worked great for us

22. Questions? @HolyJak jakub.holy@iterate.no theholyjava.wordpress.com

Dissolving Technical Debt on Agile Projects - Smidig 2012

Recomendados

Recomendados

Más contenido relacionado

Similar a Dissolving Technical Debt on Agile Projects - Smidig 2012

Similar a Dissolving Technical Debt on Agile Projects - Smidig 2012 (20)

Último

Último (20)

Dissolving Technical Debt on Agile Projects - Smidig 2012