Share via

The mechanics of getting it done in software

  • Article

One thing that's very close to my heart as the developer division has grown over the last few years is the mechanics of how we get software done.  All of the things that don't really fit into “writing code or tests”.  These are all the tasks like:

  1. Making sure you get a consistent build out every day.
  2. Dealing with integrating changes from a large number of teams.
  3. Dealing with performance and functionality regressions.
  4. Understanding the ramifications of changes before checking in.

So you can see that although I'm more focused on performance tools and code coverage, VSTS is the natural fit for me, as this is the team that is starting to put into practice many of the things we've learned the hard way about large scale software develepment at MS into real products.  Take MSF for example.  A flexible template that models many of the 'ways we do software at MS'.  It's great to see a set of tools designed for the software lifecycle rather than edit, compile and debug.

So I'm interested in what people are doing to deal with the problems listed above, and how they dedicate resources to it.  I'm a big Hi-Fi fan (though my budget doesn't stretch to buying Linn equipment :( ) and there is a rule of thumb on spending a good percentage of your budget towards buying the interconnects between components.  I feel software development is like that.  It doesn't matter if all of your developers are individually very productive; if the right interconnects for the process are not in place, the end product sounds terrible. So please, I'd love to hear other people's stories from the frontlines on what interconnects they have in place and how much they invest in them,

JoC

Comments