This Skills Matter Online Meetup is... Technical Debt. Join us as we welcome Marijn Huizendveld, who will show you how to institute a process for managed technical debt.
Skills Matter Online Meetup is a virtual meetup on the topics that truly matter to today's developers. At each meetup we are joined by an expert from around the globe to explore topics such as functional languages, mobile development, agile methodologies and machine learning.
THE FORMAT: A 40-minute expert talk followed by a Q&A session.
Please note: Live streaming issues impacted the quality of this recording for the first few minutes of the session. Video quality improves around the 3:30 mark.
Discipline, determination, a highly visible area, and a few sticky notes, are all you need to move beyond problems with technical debt.
Making great software is challenging
It doesn't matter how qualified a team is, it will never be able to produce perfect, flawless, entirely bug-free software. While teams are discovering how to build the right software in the right way, the environment the team operates in changes. This results in a constant reorientation of the product, and the corresponding software solution, which will cause gaps between how things work, and how they should work.
Unfortunately the market won't wait infinitely until teams have addressed these issues in the software, and organizations tend to run out of patience too. That is why teams often have to move forward with designs and code that are... let's call them sub-optimal. These gaps, they are technical debt: a loan against the future, where things will be fixed, at some point... Hopefully.
According to a global survey performed by Stripe, Inc. amongst software engineers in 2018, researchers found that engineers estimate to spend 17,3 hours per week on addressing technical debt. That same research established that developers work about 41.1 hours per week. With that in mind, addressing technical debt constitutes well over a third of the time a typical engineer spends per week. If engineers are spending that much time, how could they better utilize their attention? Why do they seem unable to gain control over this metric and push it downwards?
While technical debt sounds nice and predictable: "you just have to pay interest", it really is like a loan with a mobster, and not with a bank. It will show up unannounced at your doorstep at 3.30 in the morning, demanding that you pay up now! How can you prevent being surprised by this goon?! And what can you do to leverage the benefits of borrowing against the future? Because when the conditions are right, taking out a loan and paying it back Tomorrow might just help you ship a better product Today.
- A lightweight process to discover technical debt without a big investment up front
- A data-driven approach to identify the technical debt that needs attention right now
- A system that is easy to introduce, and simple to enforce
- Something that will guide engineers to articulate technical debt in terms of our roadmap
- Which will ultimately improve the flow of work in your organization
The Wall of Technical DebtTM
A few years ago Mathias Verraes coined the term "The Wall of Technical Debt." During this presentation Marijn Huizendveld will show you how to institute such a process for managed technical debt. Doing so will provide you with a safety net that allows you to make "naive" design choices every now and again to ship your ideas as fast as possible, without sacrificing sustainable delivery in the long run.
Marijn works as an independent software consultant for (corporate) startups and scale-ups within Europe. He studied business school (boring though useful) and moonlighted as freelance developer (limited impact, lots of fun).
After getting stung by the start-up bug he founded a SaaS business in which he was involved for the next 6 years (lots of impact, little money). This experience provided him with a realistic perspective on business and firm roots in software architecture. He was at the frontier of event sourced domain models in PHP and has been actively involved in the DDD-community since its revival around 2012.
These days he helps his customers to apply the lessons he picked up along the way, in order to make software that propels organizations forward. He also laughs at his own jokes, for reasons unknown cause they typically aren't funny. Join the session to see if you agree.