Technical Debt Management

Too long time explaining the problem.

Concrete example of a piece of technical debt or something that needed to change would be helpful.
I think that the biggest source of technical debt is 1) we spend reasonable time to architect some software, and then we 2) code it, and then we find out later there was a different way we could have done it or the new requirements are not amenable to what we originally wrote.

This lecture was very abstract.
Simply saying that there is a comparison between personal finances and technical debt does not seem to actionable.

Again to simply say "make your code less complex" is very abstract.

When it came to best practices "attend a local user group" was a good example of an actionable helpful comment, rather than "find the best practices and use them."

It would be great to have more concrete examples and tools and how to's. It would have been great to see some technical debt dashboards, sonar examples, etc.

Great topic, not enough meat, details, examples, etc.

Thanks for the feedback!

This talk was in the Architecture track so it was intended to be applicable to any programming language or IT project. I will add some concrete examples of possible technical debt items for future presentations, good point.

The personal financial debt references were intended to help relate to the impacts and solutions to technical debt.

The discussion regarding technical tools and practices like continuous integration servers, unit testing, abstraction, interfaces, inheritance, static code analysis, and configuration management tools was intended to give direction on analyzing and addressing technical debt within a project.

Thanks again for the feedback.

A good talk on technical debt, which many shops tend to sweep under the rug. It was applicable to any technical stack, and the presenter was engaging and knowledgeable.

My only suggestion would be to give some examples of resources to help deal with tech debt, and perhaps to share some more specific anecdotes and/or success stories.

Learned a lot in how to handle and reduce technical debt. Fantastic tips and tricks.

The first 2/3 of the talk was trying to convince us that technical debt is bad. We know; that's why we're at the talk. The last bit was bullet points of ways to reduce technical debt but they were vague like "tools" or "unit testing" without going into *what* tools or *how* unit testing can help. There was just nothing to take away from this talk.

Being an architect track, it did lean towards PHP heavily and could have used more balance between languages. That said, it was great because it outlined not just that technical debt is bad but some causes for technical debt, i.e. code smells. The tools shown were great, it was really nice to see example output and what parameters were used to get the data set. I had already run across the website referenced for the tools shown, but it was great to be reminded of them again.

All in all a good talk, thanks for presenting.