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.
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 9 months ago
People who liked this proposal, also liked:
Adam Tornhill - Meet The Social Side of Your ArchitectureAdam TornhillAuthorSoftware Design X-Rays
schedule 9 months 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 9 months 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 11 months 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 Ownership: A Certified Scrum Product Ownership WorkshopJeff PattonAuthorUser Story Mapping
schedule 6 months agoSold Out!
Product Ownership is hard! If you're working as a product owner in an Agile team, you already know this is the toughest and most critical role in a successful product organization. If you're a UX practitioner, senior engineer, or marketing professional in your organization, it may seem like adopting Scrum or Agile development has stripped away your ability to contribute as a product decision-maker.
If you're adopting an Agile approach, your organization may be struggling with bloated backlogs that aren't well understood, stressful planning meetings that last too long and fail to get at details needed to deliver predictably, a nagging feeling that you're building the wrong thing, a lack of time to work with customers and users, chronically late delivery, and frustrated business stakeholders...There's hope!
The Passionate Product Ownership workshop takes on the bad assumptions and bad practices that often emerge from overly simplistic approaches to agile development and Scrum. Jeff Patton will leverage his past product leadership experience, and years of coaching product teams to teach an effective product ownership strategy.
Ralf Westphal - TDD 2.0 - Situation-Aware ProgrammingRalf WestphalCo-FounderClean Code Developer School
schedule 9 months 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.
Alex Sloley - The Product Owner and Scrum Master Brain Transplant! Mwuhahahaha!!!Alex SloleyAlex Sloley
schedule 10 months 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!