Manage Technical Debt in Microservices and Monoliths
Many codebases contain code that is overly complicated, hard to understand, and hence expensive to change and evolve. Prioritizing the technical debt to pay down is a hard problem since there's always a trade-off between improving existing code versus adding new features. In this masterclass, you learn how easily accessible development data let us uncover the technical debt with the highest business impact. The techniques cover both technical and organizational decisions around your codebase, and we cover both traditional architectures as well as microservice architectures where you learn to measure non-code properties like team coupling, system mastery, and detect implicit dependencies between services.
- Identify the code that's most expensive to maintain amongst millions of lines of code.
- Put costs on technical debt and assess its delivery impact.
- Detect architectural decay and learn to control it.
- Perform architectural analyses of layers and microservices to uncover team coupling and implicit dependencies.
- Learn refactoring patterns to address technical- and architectural debt.
- Measure how organizational patterns influence code quality and the link to software architecture.
- Uncover the social side of your codebase and use data to mitigate off-boarding risks.
Participants are encouraged to take this opportunity and analyze their own codebases. As part of the workshop, you also get access to CodeScene – a tool that automates the analyses – which we use for the practical exercises. We also look at open-source alternatives, and see how we can use Git itself for data mining; the workshop is not about tools, but rather about the techniques and their applications. This is a new perspective on software development that will change how you view code.
DateTime: This workshop is scheduled on Oct 19th and 20th from 2 PM to 6 PM IST
Architects, Tech Leads, Senior Developers, and Technical Managers
Prerequisites for Attendees
The target audience is architects, senior developers, and technical managers. While we won't write any code during the class, the participants need to be comfortable with reading code. If you plan to analyze your own code -- which we encourage -- you need to have it in one or more Git repositories.
Style: Hands-on -- you will analyze real-world codebases -- so bring your laptop. The masterclass is based on the books Your Code As A Crime Scene (2015) and Software Design X-Rays (2018) by the instructor. The techniques are based on software evolution research and findings from various fields within psychology.
schedule Submitted 1 year ago
People who liked this proposal, also liked:
Adam Tornhill - Meet The Social Side of Your ArchitectureAdam TornhillAuthorSoftware Design X-Rays
schedule 1 year agoSold Out!
Software projects often mistake organizational problems for technical issues and treat the symptoms instead of the root cause. The main reason is that the organization that builds the system is invisible in our code. From code alone, we cannot tell if a module is a productivity bottleneck for five different teams, or whether our microservice boundaries support the way our codebase evolves or not. This session closes that gap by taking a behavioral view of code combined with insights from social psychology to measure aspects of software development that we haven't been able to capture before. You learn how this information lets you detect modules with excess coordination needs, measure how well your architecture supports your organization, as well as why Conway's law is an oversimplification. To make it specific, each point is illustrated with a case study from a real-world codebase.
Adam Tornhill - A Crystal Ball to Prioritize Technical DebtAdam TornhillAuthorSoftware Design X-Rays
schedule 1 year agoSold Out!
The technical debt metaphor has taken the software world with storm. No wonder, since software projects have their fair share of challenges. Most organizations find it hard to prioritize and repay their technical debt. The main reason is due to the scale of modern systems with million lines of code and multiple development teams; No one has a holistic overview. So what if we could mine the collective intelligence of all contributing programmers and start to make decisions based on data from how the organization actually works with the code? This session introduces one such approach with the potential to change how we view software systems.
In this session, you'll get an introduction to techniques that help us uncover both problematic code as well as the social dimension of the teams that build your software. The techniques are based on software evolution and findings from various fields within psychology. This combination lets you prioritize the parts of your system that benefit the most from improvements, detect organizational issues and make practical decisions guided by data. Each point is illustrated with a case study from a real-world codebase.
Jutta Eckstein / John Buck - Beyond KPIs and OKRs: Creating an environment for high-performing, innovative teams that leads to true effectivenessJutta EcksteinCoach, Consultant, Trainerself-employedJohn BuckPresidentGovernanceAlive LLC
schedule 1 year agoSold Out!
Too often innovative people in medium to large organizations have the feeling of being in a box - with startling new ideas - and no one really listens. In essence, these innovators are trying to “measure performance upwards.” This upward voice intrinsically measures strategies and customer impact, and applying the concept can significantly improve the overall performance without relying on top down OKRs and KPIs. Moreover, “measuring from above,” tends to measure the output of production rather than the truly important outcome: what is really making a difference for our customers and therefore for our company.
Adding “measurement from below” to a company can create a mindset that empowers everyone to follow their passion and interest and nourish the company’s effectiveness. Implementing a “from below” approach to measurement involves a fundamental shift that asks the company to synthesize a variety of new approaches. One such synthesis is Beyond Budgeting, Open Space, Sociocracy, and Agile (BOSSA nova). This synthesis enables a company to “measure upwards” without jeopardizing the strengths of “leading downwards.” Fortunately, the implementation can be done in small steps that probe and demonstrate new measurement ideas on a small scale such that the proof cascades beyond the demonstration. This session will enable you to get started on your journey to spreading the idea of upwards measurement company-wide.
This workshop asks participants to start where they are, explains what it means to probe, and helps them develop strategies and experiments they can use in their own situation to create an environment for high performance that goes beyond what OKRs and KPIs can offer.
Jeff Patton - Passionate Product Leadership: A Certified Scrum Product Ownership CourseJeff PattonAuthorUser Story Mapping
schedule 11 months agoSold Out!
This product thinking, leadership, and process workshop combines contemporary tech product thinking with agile development and Scrum.
Stop! Don’t bother taking this course if your only concern is learning Scrum and mastering the product ownership role. Because:
This is not just a product ownership class
This online workshop is about product thinking and how to apply it in your organization.
A strong product-centric approach places emphasis on customers and users and creating successful outcomes and, ultimately, a big impact on your business. All that sounds good, maybe obvious, right? But, in your organization you may be focused more on happy business stakeholders and on-time delivery than successful products. It’s not that those things aren’t important. It’s just that focusing mostly on those things can distract you and your team from really focusing on the outcomes that benefit your organization.
One of the first things you’ll learn is that, while “product owner” may be a Scrum role, product ownership is a whole team responsibility. If you’re a product owner or product manager you likely already know that you’ll be the most successful if you’re collaborating effectively with your whole team, and if your whole team understands product thinking.
This workshop will help you build a deeper understanding of product thinking and the ways of working that support it. We’ll build on agile principles and Scrum practice and add back the product thinking you don’t get with agile development alone. You’ll leave with a mindset that will help you help others in your organization, along with the practices that’ll help you do your job on a daily basis.
21st century tech product development concepts and practice
You may have noticed that technology products are different today than they were 10 or 20 years ago. They work more like services. They continuously evolve and improve. And, not surprisingly, the way we design and build them has evolved and improved. In this workshop we’ll talk about approaches we layer on top of agile development and the Scrum framework. Things like:
- Lean Startup and Lean UX practice
- Design Thinking
- Dual-Track Development
- User Stories and Story Mapping
8 Reasons why taking this live online workshop is better
I’ll be honest with you. I used to hate online workshops. I always thought they were second best. But, thanks to living during a pandemic, I’ve started to realize all the advantages to them. Here’s a few:
- Low daily time commitment: I can participate a few hours a day and still have time to get other work done, or have a life outside of work.
- No travel: No time in a plane or car, just a short walk from one room to another.
- You’ve got a mute button: There are always interruptions in life, and they seem to stress me less in an online class. I can mute a mic, turn off video, and answer a question, or put the dog out.
- No pants: Speaking of less stress, it’s nice to sit down in shorts and a t-shirt to work. Some of you may already get to do that. In an online workshop, you can come as you are. But, if you’re not wearing pants (or trousers for the UK people) please avoid standing while on camera.
- More time to ask questions: When I teach an in-person workshop, there are usually too many people, and never enough time to speak with everyone. Participants often go home sad they didn’t get to ask the questions they wanted or have the conversation they wanted. Now, online, I can follow every class with an office-hours session. No agenda. Come, talk, dig into the tough questions you didn’t want to bring up with the whole group.
- More time to think: Since we’ll be meeting and working only a few hours a day, you'll have the rest of your day and your night to “sleep on it”. For me, I’ve loved having more time to think deeply about what I’ve learned. The best questions come to me hours after I’ve processed the concept and not while I’m learning it. How about you?
- More interaction with other participants: Personally, I’m a bit of an introvert. So talking to more people isn’t usually a benefit for me. But, online it’s become one. Zoom breakout rooms help keep conversations small and quiet. During this workshop you’ll work with a couple different groups and have several one-on-one conversations with individual participants. I find talking with someone about a concept, and getting their perspective, deepens my understanding.
- A chance to sharpen online collaboration skills: Sadly, online collaboration is part of the new normal for people working in technology. During this workshop you’ll get more comfortable with Zoom and collaborating with online tools like Mural. That’s going to help you in your everyday job.
You’ll use Zoom to connect with the class and your teammates. You’ll get good at muting and unmuting yourself and staging your background to impress other participants.
You’ll use Mural to support online collaborative work. You’ll get hands-on practice every day.
After every workshop day you’ll have time for deep-dive discussions during optional “office hours” sessions with me, your instructor.
Not just for product managers and owners
While one person in a team may hold a product manager or product ownership role, it takes a cross-functional team with strong product thinking to design and build the product. That’s why this class isn’t just for product owners.
- If you’re a product manager or product owner, this workshop is for you.
- One thing you likely already know is that best product decisions balance business, user experience and technology concerns. If you’re a UX practitioner or senior engineer, this workshop is for you.
- If you’re a Scrum master or agile coach, have you seen your organization struggle to apply product thinking using a Scrum and agile approach? If you’d like to better understand how to help your organization become a strong product organization, this workshop is for you.
- If you’re a business stakeholder, manager, or leader in your organization, do you understand how product thinking changes the way you’ll need to work with teams? If you’d like to better understand how to motivate teams and keep them focused on successful outcomes while being self-directed, this workshop is for you.
4 days, 4 hours per day
We’ve got a lot to cover, and it’ll take 4 half-days to do it.
We’ll meet daily via Zoom: 5:30 pm IST to 9:30 pm IST
We’ll take frequent short breaks every 60-90 minutes so you can stay hydrated and caffeinated.
We’ll keep the class size small: 30 people max. You’ll do teamwork in smaller groups of 4 or 5 people. You’ll work with two different groups during the class, and have several one-on-one conversations with other participants. Ideally, you’ll get to meet and speak with everyone in the workshop.
What you’ll get
Scrum Alliance Certification: This is a certified scrum product ownership course, so at the conclusion of the class you’ll receive certification with the Scrum Alliance along with 2 years membership in the Scrum Alliance.
Worksheets, articles, and a 120-page course guide: Supporting material will help you recall and practice everything we discuss in the workshop.
Alex Sloley - The Product Owner and Scrum Master Brain Transplant! Mwuhahahaha!!!Alex SloleyAlex Sloley
schedule 1 year agoSold Out!
Imagine you are a Mad Agile Scientist and have a diabolical experiment to conduct - what would happen if you exchanged the brains of a Product Owner and Scrum Master? Mwuhahahaha!!! How would the body of a Product Owner with the brain of a Scrum Master act? And vice versa?
Perhaps the Scrum Master would now treat the team like a backlog? This Scrum Master would be focused on value and maintaining a coaching backlog of team and person improvements. This Scrum Master is refining the team, crafting a group that delivers value.
And perhaps the Product Owner might treat the backlog like a team? Rather than backlog refining, they coach the backlog. They would be focused on nurturing, protecting, and empowering the backlog. The backlog might transform from an irritation into a labor of love.
Although this experiment sounds terrible, this change of perspective might be what you need to reanimate your dead team or backlog.
Join the fun and come learn what horrifying results await!
Ralf Westphal - TDD 2.0 - Situation-Aware ProgrammingRalf WestphalCo-FounderClean Code Developer School
schedule 1 year agoSold Out!
Are you "doing it" the TDD way? Really? Are you getting the results from TDD as you expected? Yes? Great, check out one of the other exciting sessions at this conference.
No? Then: How come? Isn't TDD supposed to be easy? Just do the red-green-refactor dance and all code's gonna be functional plus clean.
Sorry, but I beg to differ. It's not that simple. And there are many reasons for that as I'll show you in this talk.
My main objection is, that TDD as it's commonly explained and demoed, is ignoring the plain and simple reality of problems being of very, very different difficulty. Or have you ever seen a TDD demo beyond the usual code kata exercises like "Fizz Buzz" or "Game of Life"?
Hence in this talk I want to present a bigger picture. I'll classify programming situations according to the Cynefin framework and put TDD in perspective. It will become clear where TDD might be a good fit and why - but also, where TDD is overtaxed.
And since TDD is only a fit for a small subset of problems, of course alternative approaches to test-first programming will be presented.