Hey all, I'd love some feedback on audience expectations for a software talk I'll be giving at CodeMash in January. This is my first time speaking at a technology conference and I want to make sure I have a good chance at meeting a wide array of audience expectations.
Here is my accepted abstract:
Technical debt must die - Communicating code to business stakeholders
Our software sucks. We're up to our necks in bugs and technical debt, yet we often seem to hit roadblocks explaining things in ways that bring about meaningful change. In this session you'll learn to gather, analyze, and interpret data in order to create effective presentations to communicate quality, technical debt, and other technical matters in ways that tell a compelling story. You’ll master how to communicate effectively with key stakeholders by taking a data-driven approach and bridging common gaps between development and business stakeholders. You’ll explore the 7 tools of software quality, and how they can bring clarity and sanity to the decision-making process, justify paying down technical debt, and focusing on improving our quality in the areas that need it most.
If you were attending this talk:
- What would you most want me to focus on?
- What would you be disappointed about if I didn't cover?
- What work situations or other questions coming in would you want to find answers to?
- What other topics not explicitly listed here would you hope I covered?
Thanks for any help you can provide in the comments.
If you're curious about some of the things mentioned in the abstract, take a look at my post on the 7 basic tools of software quality.
Top comments (8)
What would you most want me to focus on?
What would you be disappointed about if I didn't cover?
Thanks for the very helpful feedback. I'll likely write more on this subject in the months leading up to the talk, so stay tuned, but that's fantastic feedback and something I'll be sure to include.
Awesome! Please keep us posted! :)
What would you most want me to focus on?
A: How to measure software quality, interpret and communicate the results.
What would you be disappointed about if I didn't cover?
Code coverage / software testing
What work situations or other questions coming in would you want to find answers to?
Being asked:
A) Is it ready / Can we ship it?
B) how long will it take to pay down this tech debt and what business benefits are there?
What other topics not explicitly listed here would you hope I covered?
Risk!
I would like to see such a talk,I don't know CodeMash, is it recorded?
Thanks for the valuable feedback. I'll take that into account. CodeMash has been recorded before, but I do not yet know if next year's will be. I could always record a practice and upload it to YouTube as well.
Yes please!
When I read the 7 tool and the abstract, I hope that there is a clear connection of how technical debt mitigation helps to improve the metric results.
Reading the 7 tools, how do I communicate that it is important to track these metrics because it is important to focus on heavy issues. We struggle with everything is a fire and no -technical- person is in charge of triage.
Thanks for the feedback there. The 7 tools are more of lenses for analyzing a particular problem. I plan on showing more persistent ways of measuring code over time - tools like SonarQube / SonarCloud, NDepend (for the .NET world), etc. However, a lot of the aspects of 7 basic tools - if you repeat the exact same experiment later on - you should see an improved result.
I do like your point on firefighting and no one person heads up the responsibility of paying down debt. I will be sure to incorporate that into my talk.