DEV Community

Matt Eland
Matt Eland

Posted on

Feedback requested for Software Quality talk

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.

Discussion (8)

Collapse
pavlosisaris profile image
Paul Isaris

What would you most want me to focus on?

  • How to prioritize technical debt?
  • How is technical debt tackled in SCRUM

What would you be disappointed about if I didn't cover?

  • What to do if technical debt is an issue in a project that is tight (both on a budget and time)
Collapse
integerman profile image
Matt Eland Author

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.

Collapse
pavlosisaris profile image
Paul Isaris

Awesome! Please keep us posted! :)

Collapse
dowenb profile image
Benjamin Dowen

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?

Collapse
integerman profile image
Matt Eland Author

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.

Collapse
dowenb profile image
Benjamin Dowen

Yes please!

Collapse
jessekphillips profile image
Jesse Phillips

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.

Collapse
integerman profile image
Matt Eland Author

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.