5 ms·

(Note, speaking for myself, not Microsoft!) Pretty good article, only some minor inaccuracies. Things I noticed: 1) Private offices are nowhere near gone. So

(Note, speaking for myself, not Microsoft!) Pretty good article, only some minor inaccuracies. Things I noticed: 1) Private offices are nowhere near gone. Some teams have "gone team room" (TFS), some have not (Roslyn). I've worked in both and personally don't care either way, but there are a number of people who heavily favor one or the other. 2) Visual Studio is technically a team, yes, but there are thousands of devs working on it. I think of my team as Managed Languages (Roslyn), not VS. 3) Development strategy is a continuous process and one we're still currently engaged in. We haven't just decided that this is the new process and we're not changing it again. Oh, and some personal feelings: tooling isn't really mentioned in this article but it may be the most important. TFS and other teams have developed some quite good tools that help with the workflow considerably. If every dev is wasting time messing with bad tools, that's a huge amount of dev time wasted as an organization.

sliverstorm 12y ago
Tools is so huge! It is one of those sort of "intangible" assets of a large company, what is the quality (and projected future quality) of their tools... Poor tools decisions or tool apathy (for example, not enough funding to the tools teams) can shackle entire divisions of the company.
- seanmcdirmid 12y ago
  Google is famous for a tooling strategy that has paid off in spades. Reading about their RCS, build, and testing infrastructure is like reading an overly optimistic science fiction novel; it can't be that great right?
  - thrownaway2424 12y ago
    I take it you've only read about these tools, and not actually had to face them.
    - seanmcdirmid 12y ago
      Yes, but I've heard good things from those that actually use them. Preforce mated to GFS, lightning quick check outs and builds that work lazily, you can make a change to the code base even if you don't own it, and code review requests will be sent out automatically as well as tests run to ensure you didn't break...Google.
      - blake8086 12y ago
        The tools are world-class. But as soon as you use them, it is also obvious how far away they are from perfection. So I think you'll always here about how great they are from the outside, and grumbling from all the people who use them on the inside. They are really great, and they really do make a difference though.
    - marssaxman 12y ago
      I've had to face them; they are really damn good. I've never seen anything better.
      - thrownaway2424 12y ago
        Much like Churchill's characterization of democracy, Google's build and test tools are the worst, except for all the other ones.
- keithnoizu 12y ago
  I think the old review system ( i think they've changed it since I left ) killed the internal tooling story. No one gets 1s or excelleds for maintaining an existing tool. They get a boost for pushing out a good enough tool and then they move on to something else rather than focusing on incremental improvements. Because those don't play well into your annual review.
DrPizza 12y ago
[author here] You know, I should have written about that a bit more. It makes sense in retrospect, I didn't even think about it at the time, even after leading off with the problems of the VS2010 cycle. But, yes. If one looks at how VS and TFS have evolved, it's been very clear that there must have been some internal customer who really wanted to use them for scrum (no external customer would ever be that influential). The last few releases, not to mention the VS2012/2013 quarterly(ish) updates have all had an emphasis on improving this aspect of the products. Accordingly, they seem to have become pretty decent, and this has no doubt helped teams change how they work.
- keithnoizu 12y ago
  I don't know. My understanding is that external customer requests on TFS are ranked higher than internal requests. As in internal feature requests related to agile and scrum that would have made other teams life much easier have in the past been explicitly refused because they were unsure of how well it translated into the needs of the retail consumers.
  - DrPizza 12y ago
    External requests might have motivated the initial foray into supporting agile processes, but it's internal users that make it worth a damn, IMO. My view is that you can't develop effective general purpose application software without an internal customer, because until you have that internal customer, you can't meaningfully dogfood it, and you can't get the feedback loop tight enough. Take, for example, WPF. WPF addressed a real need, I think; developers wanted a decent GUI stack (which Win32/WinForms/MFC/whatever just ain't), and long term, Microsoft wanted something amenable to 3D acceleration and DPI increases. Great. Except that for the longest time, WPF was deeply problematic for any major application. Problems around text handling and performance were the biggies. Microsoft had no real internal customer for WPF. Some of the Blend apps used it, but they (now discontinued) were never a critical part of Microsoft's day-to-day operation. When did WPF get good? When an important application (Visual Studio 2010) started using it, and made clear that hey, something needs to be done about that text rendering and performance. I think there are quite a few little corners of Microsoft's software in a similar boat. The new-to-Vista sound card/audio APIs were plainly not fit for purpose in their original form, but nobody in Microsoft noticed, because nobody in Microsoft was actually using them. Late in the development cycle the APIs were updated (adding notifications when a buffer was nearly empty) to make them usable, but it created a troublesome driver situation for a year or more post-release. With the internal customer, the feedback becomes much more immediate. Microsoft's customers don't get to see every 3 week cycle. Internal customers do. When the developers are using the very product they're developing, this becomes better still; there's an implicit understanding of what the thing should do, and how it needs to be better. This becomes institutional knowledge, and it likely never even manifests as an explicit request. It doesn't have to. The implicit understanding of how customers are using the software and not just what they want but _why_ they want it is sufficient to ensure proper and effective implementation of their requests.
keithnoizu 12y ago
I think my pet peeve at Microsoft was that the tooling, TFS included just wasn't that good for agile development. I mean you can see SD smothered all across TFS and while SD was nice for it's time it's grossly inferior to github/mercurial in every regard other than supporting massive codebases. There's also in my opinion a huge problem in that what sort of technology you can use is severely restricted by what Microsoft makes. I'd get push back for asking for a license for something like reflector (yes we had a ilasm dissambler but it was horrible) let alone something like recommending using selenium instead of some horrible, under maintained internal solution. Then there are just the utterly ridiculous political restrictions on the development pipeline. "Oh you have to use Razzle or CoreXT instead of TFS because even though you're a html5 website with SOA components your team is technically part of windows and they use Razzle."
- dblock 12y ago
  You know, in 2003 we (I'm the original author of CoreXT) had some attempts at a serious discussion of merging CoreXT + Razzle and whatever the VS team was doing. I was told "Windows is too big" and "Visual Studio is built for a different customer than Microsoft developers" and the "future is Team System". Here we are 10 years later ...
  - larsberg 12y ago
    Hey! I was the one running the build environment stuff in VS at the time. IIRC, CoreXT didn't handle some really oddball scenarios we had that involved self-hosted compilers and runtimes. e.g., rerunning the build with the compiler you just built or just the runtime you just built, or... We were also trying to shift as much of the managed parts of the stack as possible to using MSBuild natively, which required a custom local runtime build to support asmmeta (which rudi and I created to solve the circular build dependencies in managed libraries in VS). We were also using subtly different versions of build.exe whose parallel build support and support for scenarios with files over 2^31 bytes differed in non-trivial ways. In the end, I think I stole everything I liked in CoreXT (which was a lot!) but we couldn't really adopt the workflow without breaking basic requirements that VS had that nobody outside of a compiler toolchain really sees. (BTW, I apologize if some of this is off. Like you pointed out, this is more than 10 years ago.)

sliverstorm 12y ago

Tools is so huge! It is one of those sort of "intangible" assets of a large company, what is the quality (and projected future quality) of their tools... Poor tools decisions or tool apathy (for example, not enough funding to the tools teams) can shackle entire divisions of the company.

seanmcdirmid 12y ago
Google is famous for a tooling strategy that has paid off in spades. Reading about their RCS, build, and testing infrastructure is like reading an overly optimistic science fiction novel; it can't be that great right?
- thrownaway2424 12y ago
  I take it you've only read about these tools, and not actually had to face them.
  - seanmcdirmid 12y ago
    Yes, but I've heard good things from those that actually use them. Preforce mated to GFS, lightning quick check outs and builds that work lazily, you can make a change to the code base even if you don't own it, and code review requests will be sent out automatically as well as tests run to ensure you didn't break...Google.
    - blake8086 12y ago
      The tools are world-class. But as soon as you use them, it is also obvious how far away they are from perfection. So I think you'll always here about how great they are from the outside, and grumbling from all the people who use them on the inside. They are really great, and they really do make a difference though.
  - marssaxman 12y ago
    I've had to face them; they are really damn good. I've never seen anything better.
    - thrownaway2424 12y ago
      Much like Churchill's characterization of democracy, Google's build and test tools are the worst, except for all the other ones.
keithnoizu 12y ago
I think the old review system ( i think they've changed it since I left ) killed the internal tooling story. No one gets 1s or excelleds for maintaining an existing tool. They get a boost for pushing out a good enough tool and then they move on to something else rather than focusing on incremental improvements. Because those don't play well into your annual review.

DrPizza 12y ago

[author here] You know, I should have written about that a bit more. It makes sense in retrospect, I didn't even think about it at the time, even after leading off with the problems of the VS2010 cycle. But, yes. If one looks at how VS and TFS have evolved, it's been very clear that there must have been some internal customer who really wanted to use them for scrum (no external customer would ever be that influential). The last few releases, not to mention the VS2012/2013 quarterly(ish) updates have all had an emphasis on improving this aspect of the products. Accordingly, they seem to have become pretty decent, and this has no doubt helped teams change how they work.

keithnoizu 12y ago
I don't know. My understanding is that external customer requests on TFS are ranked higher than internal requests. As in internal feature requests related to agile and scrum that would have made other teams life much easier have in the past been explicitly refused because they were unsure of how well it translated into the needs of the retail consumers.
- DrPizza 12y ago
  External requests might have motivated the initial foray into supporting agile processes, but it's internal users that make it worth a damn, IMO. My view is that you can't develop effective general purpose application software without an internal customer, because until you have that internal customer, you can't meaningfully dogfood it, and you can't get the feedback loop tight enough. Take, for example, WPF. WPF addressed a real need, I think; developers wanted a decent GUI stack (which Win32/WinForms/MFC/whatever just ain't), and long term, Microsoft wanted something amenable to 3D acceleration and DPI increases. Great. Except that for the longest time, WPF was deeply problematic for any major application. Problems around text handling and performance were the biggies. Microsoft had no real internal customer for WPF. Some of the Blend apps used it, but they (now discontinued) were never a critical part of Microsoft's day-to-day operation. When did WPF get good? When an important application (Visual Studio 2010) started using it, and made clear that hey, something needs to be done about that text rendering and performance. I think there are quite a few little corners of Microsoft's software in a similar boat. The new-to-Vista sound card/audio APIs were plainly not fit for purpose in their original form, but nobody in Microsoft noticed, because nobody in Microsoft was actually using them. Late in the development cycle the APIs were updated (adding notifications when a buffer was nearly empty) to make them usable, but it created a troublesome driver situation for a year or more post-release. With the internal customer, the feedback becomes much more immediate. Microsoft's customers don't get to see every 3 week cycle. Internal customers do. When the developers are using the very product they're developing, this becomes better still; there's an implicit understanding of what the thing should do, and how it needs to be better. This becomes institutional knowledge, and it likely never even manifests as an explicit request. It doesn't have to. The implicit understanding of how customers are using the software and not just what they want but _why_ they want it is sufficient to ensure proper and effective implementation of their requests.

keithnoizu 12y ago

I think my pet peeve at Microsoft was that the tooling, TFS included just wasn't that good for agile development. I mean you can see SD smothered all across TFS and while SD was nice for it's time it's grossly inferior to github/mercurial in every regard other than supporting massive codebases. There's also in my opinion a huge problem in that what sort of technology you can use is severely restricted by what Microsoft makes. I'd get push back for asking for a license for something like reflector (yes we had a ilasm dissambler but it was horrible) let alone something like recommending using selenium instead of some horrible, under maintained internal solution. Then there are just the utterly ridiculous political restrictions on the development pipeline. "Oh you have to use Razzle or CoreXT instead of TFS because even though you're a html5 website with SOA components your team is technically part of windows and they use Razzle."

dblock 12y ago
You know, in 2003 we (I'm the original author of CoreXT) had some attempts at a serious discussion of merging CoreXT + Razzle and whatever the VS team was doing. I was told "Windows is too big" and "Visual Studio is built for a different customer than Microsoft developers" and the "future is Team System". Here we are 10 years later ...
- larsberg 12y ago
  Hey! I was the one running the build environment stuff in VS at the time. IIRC, CoreXT didn't handle some really oddball scenarios we had that involved self-hosted compilers and runtimes. e.g., rerunning the build with the compiler you just built or just the runtime you just built, or... We were also trying to shift as much of the managed parts of the stack as possible to using MSBuild natively, which required a custom local runtime build to support asmmeta (which rudi and I created to solve the circular build dependencies in managed libraries in VS). We were also using subtly different versions of build.exe whose parallel build support and support for scenarios with files over 2^31 bytes differed in non-trivial ways. In the end, I think I stole everything I liked in CoreXT (which was a lot!) but we couldn't really adopt the workflow without breaking basic requirements that VS had that nobody outside of a compiler toolchain really sees. (BTW, I apologize if some of this is off. Like you pointed out, this is more than 10 years ago.)