Peter Provost

Peter Provost PeterProvost

Niner since 2006

Peter Provost is a Principal Group Program Manager for Application Insights, a new product by Microsoft for monitoring your application's availability & performance and helping you improve your application by understanding customer usage patterns. Prior to that he was part of the Visual Studio ALM team, focusing on agile and enterprise development tools. Before joining the Visual Studio team, he managed the patterns & practices development team at Microsoft where they created tooling and guidance for enterprise .NET customers.

Before joining Microsoft, Peter was a software development consultant in the Rocky Mountain region focusing on Microsoft technologies and agile software development techniques. He has spoken at numerous of conferences and user groups and has written articles on agile development, Visual Studio, ASP.NET, Web services and other topics.

Comments

  • Tour: Patterns and Practices Lab

    DigitalDud wrote:
    

    I'd say working with as a team is definitely important but so is developer privacy. Considering developers are going to be spending most of their time debugging, I'd say some privacy and the ability to shut off distractions is going to be pretty important. The last thing you want when you're debugging, and going deep into the call stack, is someone coming in and disrupting your concentration.

    The most interesting thing about the way we work is how little time our developers actually have to spend in the debugger. When you practice things like TDD and pair-programming, you literally spend less than 10% of your time in the debugger.

    I was giving a "agile" presentation to another team here on campus lately and had a few other agile folks from around MSFT with me. I asked the room, "How much time you spend in the debugger?"

    The team I was talking to responded with numbers like 50% or 75%. Then I asked my agile friends and they responded with numbers like 0% or 5%.

    TDD allows you to build the system in a small way so surprises rarely occur. You don't spend very much time in the debugger, because you only added one or two lines of code since you last ran the tests.

    I typically only use the debugger when an API call I'm using doesn't behave the way I expect. But then it is a VERY targeted attack. Step into the one test I'm having problems with, trace through to the API call and inspect the result. Once I've learned better what's going on, I add typically add a new test that explains that behavior better and then I can move on.

    Hopefully that helps explain things a bit better.

    --Peter