Episode 66: Getting a lesson about Technical Debt from Gary Short

Sunday, March 27 2011 - Podcast

Subscribe to the show via or

 

About This Episode

In this episode, Keith and Woody sit down with Gary Short of DevExpress to talk about Technical Debt, the cost of putting off good development practices, and how it can cripple a project's velocity, flexibility, and quality.

Thanks To Our Sponsor

DevExpress products are built by developers for developers. We don’t believe in limitations or wasting anybody’s time. Our lightning-fast grid controls, slick reporting components and powerful IDE add-ins fill your development toolbox with an arsenal against repetitive tasks that erode productivity. Invest in your toolbox - download your 60 royalty-free controls from DevExpress now.

Thanks to our guest this episode

Gary Short works for Developer Express as the Technical Evangelist on the frameworks team. He has a deep interest in technical architecture, especially in the areas of technical debt and refactoring. Gary is a C# MVP and gives presentations at user groups and conferences throughout the UK. As well as C#, Gary also has an interest in dynamic languages such as Smalltalk, Ruby and Python as well as iPhone development using Objective-C. Gary’s blog is at http://community.devexpress.com/blogs/garyshort Gary can be found on Twitter at http://twitter.com/garyshort

Show Notes

•  Blog post defining it on Gary’s blog

Download Show

Subscribe To The Show

There are three ways to subscribe to our show so you can stay current. We support standard RSS, subscriptions via the iTunes Store and we are also available in the Zune Market place. Chose your poison by clicking on your choice below.

#1 Rob Vander Sloot on 3.27.2011 at 10:36 PM

Great interview guys!

Technical Debt has been a pet peeve of mine for a very long time. I understand the business reasons for planned technical debt, but when shortcuts are taken just because the developer is lazy or they think that their boss will be more impressed getting it done "faster", it drives me nuts, especially because I'll probably be the one to unravel it the next time that I to touch that section of code.

When measuring the time that it takes to implement a new feature, it really doesn't take any longer to code it "right" the first time. Sure, the developer who takes short cuts gets it into QA faster, but by time they've gone around in circles a few times with the testers to work out all the kinks, they are not only pushing schedule boundaries, but their code is already starting to smell.

Thank you, especially to Gary for providing some great information.

#2 Hosted Call Center on 4.22.2011 at 3:28 PM

I agree completely that it is better to spend more time up front planning a project and making sure the right processes are in place. There is so much pressure to just start coding, but in the long run, you will save time when you don't cut those corners. I am so frustrated with the trend to outsource development to India for example, thinking that cheaper labor will save development costs. It ends up costing as much or more because the effort wasn't put into planning.

Leave a Comment