3 ms·

Like the idea, but it feels heavy to me and like it may suit slower release cycles better. Maybe that's because MS is still shipping installed software tools (T

by jaynate 11y ago

Like the idea, but it feels heavy to me and like it may suit slower release cycles better. Maybe that's because MS is still shipping installed software tools (TFS in this case). "We’ve done it 3 times now over the past ~7 years and have been happy with the results every time" This comment confirmed it for me. I'm interested in companies who are using this model in a context where software is released continuously or at least multiple times per year?

taylaf 11y ago
Actually, this team is responsible for both TFS (major releases 1-2 years, minor releases quarterly) and Visual Studio Online which is a hosted service and releases once every three weeks. Pretty much everyone on the team works on both products because they share a very large percentage of their code. Source: I'm the guy closest to the camera in the picture. Oh, and we're hiring if anyone is interested.
- taspeotis 11y ago
  I don't suppose you're hiring in Brisbane, Australia?
- VOYD 11y ago
  Nice!
adamtait 11y ago
Same. Changing teams every two years seems like a long time. Not mentioned in the post, but I would bet that in Microsoft-land, the release cycle is about two years so it gives a natural transition point. Let's say that an engineer takes 4-6 months to ramp-up on a new team, that still gives 18 months of full productivity. I'm sure that engineers reach 80% of the learning curve was traversed at 12 months. The fact that it takes them 3-4 days to decide the next round of teams seems very long, in spite the post's insistence that it's short. I'm interested in environments where teams chose a much shorter cycles. I think shorter cycles would present a different set of challenges, like reducing ramp-up times and cycle decision times. It may also be easier, like reducing the risk of a single cycle decision. I have heard reports from a company with ~50 engineers who had 2 week cycle times, which was basically their sprint time though releases would have much more frequently. They had the advantage of a mostly homogeneous language and development environment. There kept in up for more than two years, at which point the company pivoted, no longer had a homogeneous dev environment and were doing more greenfield and less support/optimization/incremental-improvement. All reports were great. People were always surprised how the team would even out the teams when put in a single room, where the teams and choices were clear to everyone.
MichaelCrawford 11y ago
I feel that continuous and frequest releases do not serve the end user. It can take time to find and fix subtle bugs. Adding new features introduces new subtle bugs. Even as a developer, for me to grow happy with a tool often means that Apple will crush my joy by altering thatntool in a way that makes no sense to me. Today's "UX" is particularly tragic. I find so many user interfaces that make no sense. Perhaps thats because there isnt enough time to solicit feedback from end users.

by jaynate 11y ago

taylaf 11y ago

Actually, this team is responsible for both TFS (major releases 1-2 years, minor releases quarterly) and Visual Studio Online which is a hosted service and releases once every three weeks. Pretty much everyone on the team works on both products because they share a very large percentage of their code. Source: I'm the guy closest to the camera in the picture. Oh, and we're hiring if anyone is interested.

taspeotis 11y ago
I don't suppose you're hiring in Brisbane, Australia?
VOYD 11y ago
Nice!

adamtait 11y ago

Same. Changing teams every two years seems like a long time. Not mentioned in the post, but I would bet that in Microsoft-land, the release cycle is about two years so it gives a natural transition point. Let's say that an engineer takes 4-6 months to ramp-up on a new team, that still gives 18 months of full productivity. I'm sure that engineers reach 80% of the learning curve was traversed at 12 months. The fact that it takes them 3-4 days to decide the next round of teams seems very long, in spite the post's insistence that it's short. I'm interested in environments where teams chose a much shorter cycles. I think shorter cycles would present a different set of challenges, like reducing ramp-up times and cycle decision times. It may also be easier, like reducing the risk of a single cycle decision. I have heard reports from a company with ~50 engineers who had 2 week cycle times, which was basically their sprint time though releases would have much more frequently. They had the advantage of a mostly homogeneous language and development environment. There kept in up for more than two years, at which point the company pivoted, no longer had a homogeneous dev environment and were doing more greenfield and less support/optimization/incremental-improvement. All reports were great. People were always surprised how the team would even out the teams when put in a single room, where the teams and choices were clear to everyone.

MichaelCrawford 11y ago

I feel that continuous and frequest releases do not serve the end user. It can take time to find and fix subtle bugs. Adding new features introduces new subtle bugs. Even as a developer, for me to grow happy with a tool often means that Apple will crush my joy by altering thatntool in a way that makes no sense to me. Today's "UX" is particularly tragic. I find so many user interfaces that make no sense. Perhaps thats because there isnt enough time to solicit feedback from end users.