We got big full page newspaper ads delivered to our office doors this morning as part of the the Microsoft “People-Ready” marketing blitz. This type of thing does not happen every day, and caught me by surprise to be honest with you, these larger-than-life marketing messages are always so general that I sometimes feel they are meaningless by the time they reach me. But even with me, the jaded software tester, this one resonates with me.
It’s really what we’re trying to accomplish with Visual Studio Team System – help people break through and succeed. The general message seems to be something to the effect of:
- hire the best people
- form teams around goals
- trust people and give them what it takes to succeed
(… and of course use software that enables this and was designed with the above in mind)
I know it seems counterintuitive for a tool maker to be beating the agile manifesto drum here and begging that people and processes take priority over tools. This is one of the things I struggled to understand when was first introduced to agile, because “tools” are my job, and the idea that tools play second fiddle hurt my pride a bit. But humble pie is good medicine, and after talking with folks outside Microsoft in the dev community who use a wide mix of all sorts of tools from all over the place, it seems like when you make this shift in thinking and really start aligning your resources so that your bright people are fueling your business success, it becomes obvious how important it is to have reliable tools running in the background that don’t siphon away your best people just to keep them running, so getting the best tools is actually very important.
Unfortunately getting reliable toolsets like that in place right now involves manually solving the differential equation of finding just the right combination of bits and pieces of technology created by maintainers with no overarching vision or the the time or resources to make it play nicely with others. I’ve seen people outside of Microsoft demonstrate very impressive continuous integration systems pieced together for example with all sorts of third party tools and scripts and trigger actions. But the problem seems to be that for every one of these folks who has walked through the valley of the shadow of death to integrate tools like this, there are a bunch more who didn’t survive or gave up without even trying. And it is not something they could just install out of the box. I have this mental image of that person who does succeed in keeping things humming for everyone being the one most likely to be bribed by coworkers with home-made cookies.
I almost feel bad shipping this product because it doesn’t seem fair to those heros who on their own, with little thanks from others, spent months researching and piecing together, and experimenting, and basically doing the whole blood, sweat, and tears routine to get equivalent systems up and running. The VSTS base system can be set up in a matter of hours, not days. Customizing VSTS is still going to take time, so home-made cookie baking skills will probably still come in handy, but it seems like we’re moving in the right direction.
When I hear complaints from people at other software companies about their infrastructure (at companies that actually sell software to others, I’m not even talking about companies who just need to develop their own in-house software), it makes me think that one of the keys to Microsoft’s success is really just the robustness of our issue tracking system, how easy it is to set up a distribution list, stuff like that. There is this wealth of internal turnkey tools we have here that you can re-use at any group inside Microsoft. The catch to all of this of course is that they have up to this point been treated as “internal use only, secret sauce” type of tools. I don’t think we have any great earth-shattering secrets of success here other than just the reality that shipping hundreds of products with tens of thousands of developers using the same tools has a way of hammering in a certain level of robustness. Visual Studio Team System (Team Foundation Server in particular) is a big step forward for us, and a leap of faith on the part of Microsoft, because we are for the first time that I am aware of consciously identifying these building blocks we use internally, integrating them and making them work together, and then selling them.
Let’s say you could bring a key project to market faster if only you could find a way to free up 50% of the time of one of your brightest employees to work on a key project. If we can free smart people up to actually use their brains to solve hard business problems rather than hard maintenance problems, you could.
To some degree the telephone has become people-ready. We don’t think about how the telephone works each time we pick it up. We just dial the number, and talk, and think about the conversation we are having. When your brain is focused on the conversation you are having rather than the technical details, that’s success in phones putting people before tools. When as a developer you’re “in the zone” focused on your own code rather than just trying to get your tools to work, that’s success on our side.
I think as an industry we’ve grown so used to high maintenance cost of SDLC infrastructure, that we don’t realize how much better life could be. We’ve got systems cobbled together at each site with a unique patchwork of open source, commercial, and home-grown components, to the point it could makes or break project success. That’s not going to change overnight, if it ain’t broke, don’t fix it, etc., etc… But my vision for Team System is a tools foundation that is so reliable and customizable that people can just take it for granted and focus full time on the people and processes they are enabling with the software they are developing, not having to constantly context switch between infrastructure and the product under development.
Just some thoughts. Totally my opinion. I know you don’t come to my blog for vision talk, so I’ll just skydive the 30,000 feet back down to my day job where the air isn’t so thin. :)