
How Microsoft dragged its development practices into the 21st century - amaks
http://arstechnica.com/information-technology/2014/08/how-microsoft-dragged-its-development-practices-into-the-21st-century/
======
Locke1689
(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.

~~~
DrPizza
[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
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
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.

------
credo
The title is eye-catching and the writer has a good writing style, but I see a
lot of problems with the headline as well as the content

\- Microsoft's private offices were an innovation in the 80s/90s, cramming
large numbers of worker bees into a single large office is a retrogressive
step, not a 21st century innovation

\- The writers focus is on Visual Studio, but a number of other teams had
switched to agile much earlier. I worked in Windows Live Mobile in when we
switched to "agile" in 2004. This wasn't being dragged into anything, it was a
relatively early adoption

\- Software projects do often get delayed, but not always. I was one of the
dev-leads who worked on Office XP in the 90s and though we had a long ~3year,
ship cycle, we did ship on the original planned shipped date (RTM 3/2/1)
Steven Sinofsky deserved a lot of credit for that.

~~~
greggman
I'm curious about the common belief that private offices are better. Here's an
article that suggests private offices _might_ not be better. Do the two ideas
fit together or do you just not believe the article (I didn't see any research
sited)

[http://www.theatlantic.com/business/archive/2011/04/working-...](http://www.theatlantic.com/business/archive/2011/04/working-
best-at-coffee-shops/237372/)

~~~
silverbax88
There's plenty of research that shows that open floor plans always hurt morale
and productivity. You're not looking hard enough.

~~~
ckluis
FWIW, I’ve read of ton of research and the consensus is that open floor plans
do hurt morale/individual production, but private offices hurt
communication/team production.

I’ve also seen some research (which I cannot recall right this second) - which
suggests team offices of 4-8 are ideal where you get some of the
communication/team productivity without the full disruption of an open office.

~~~
mbesto
I have a list of about 10 articles (with verified sources, etc) that go in
either direction. Making a bold claim that one type of office is more
productive than another is simply untrue.

~~~
ckluis
I made no such claim. I was making the claim that overall production maybe
affected differently than individual production for both scenarios. And
offering a middle-ground option which may be more beneficial, but is often not
discussed.

------
dschiptsov
Do not be too much impressed by big names and buzzwords.

The [very] successful process of developing the Linux kernel with nothing but
git, mailing lists and a small set of simple rules (no meetings, no Scrum, no
BS) proved to be good-enough.

It is not only Linux kernel, there are hundreds of other "decentralized, no-
water-fall" projects, notably FreeBSD, OpenBSD, Xorg, LLVM, Golang, CPython,
Ruby, you name it.

It is much better to consider the differences between a commercial
organization (a corporation) with all that bureaucracy obsessed with keeping
its positions and budgets, etc. and a team of enthusiastic professionals with
their own "inner" motivations and goals.

Corporations are producing products to make profit, while teams of enthusiasts
are producing (evolving) tools and services for themselves.

The difference is the same as between McDonald's and family/home-made-for-
themselves food.)

Consider, for example, LLVM/Clang (backed by Apple) as high quality and no-
cost alternative to VS. Its used as a primary compiler for OS X, iOS and
FreeBSD and optional one for Android NDK.

And, look ma, no bureaucrats, no meetings, no Scrum.

~~~
bignaj
LLVM/Clang and Visual Studio are not analogous... LLVM/Clang is a
compliler/compiler frontend while Visual Studio is an IDE. You're looking for
Visual Studio vs. Eclipse or .NET vs. Mono etc. in each case I think most see
the no-cost alternative as quite obviously inferior. This weakens your
argument a bit.

~~~
reitanqild
> You're looking for Visual Studio vs. Eclipse or .NET vs. Mono etc. in each
> case I think most see the no-cost alternative as quite obviously inferior.

In manys eyes it is quite the opposite: Netbeans and Eclipse used to run
circles around VS. I understand a lot of people like VS and there have been
improvements lately bur please don't spread FUD on HN. Thanks.

~~~
moron4hire
I don't think it's fair to call the parent post "FUD", both because I think
you've misused the term "FUD" and because I don't think the parent post is
qualitatively wrong.

Having been a user of all of them for... as long as they have existed (oh
God)... Visual Studio has been my preferred software at the time that each
version existed. Even the much-maligned Visual Studio .NET 2002 seemed
_relatively_ faster and less error-prone than the then-current release of
Eclipse. The decision to use Eclipse was usually a cost or programming
language issue. You don't code Java in Visual Studio. There were many times,
if I could have, I would have plunked down the cash.

Today, I try to setup my projects to be editor-agnostic, but I still end up
using VS Express 2013 for Web when I'm working from a Windows machine. When
I'm not, I'm not using Eclipse, I'm using something much lighter, like Vi or
Geany.

------
MrZipf
Like it or loathe it, MSFT has always been a learning corporation. Teams are
continually exploring different approaches to software development and trying
to figure out what works best for their team and org. To their credit, they
also publish a fair amount of this research and it looks pretty interesting,
e.g.

Transition from Centralized to Distributed VCS: A Microsoft Case Study on
Reasons, Barriers, and Outcomes, via [http://research.microsoft.com/en-
us/people/nachin/](http://research.microsoft.com/en-us/people/nachin/)

Have Agile Techniques been the Silver Bullet for Software Development at
Microsoft? via [http://research.microsoft.com/en-
us/people/bmurphy/](http://research.microsoft.com/en-us/people/bmurphy/)

[ $0.02, Scrum or no scrum, for my money having a private office is infinitely
better than open plan for getting stuff done. Each to their own, getting
harder to find jobs with your own space ]

------
forgotAgain
Seems to be a lot of words to describe what is basically a company adapting to
its place in the market.

When Microsoft had a dominant market position it could freeze its customer's
in-house strategies by tactically leaking details (real or perhaps not) of its
future releases. Extended release intervals did not matter because customers
waited.

Fast forward to today and it is not dominant in markets where it sees growth
potential. Customers will no longer wait. Microsoft is seen seen as a laggard
by many adopting new technologies. Extended development time would preclude
any chance they have of success so they had to change. The outcome is as yet
undetermined.

------
CurtMonash
Sometimes I think one of the more important innovations in development
technology is the headphone. Open-plan development without great ways to block
out noise would be ridiculous.

~~~
Blackthorn
I work in an open-plan office and it's the most miserable thing in the world,
even with headphones. After this I will never again accept a job without a
private office.

~~~
sliverstorm
I have not been blessed with a private office yet, but fortunately cubes are
still _dramatically_ better than open-plan (IMO).

~~~
iolothebard
It's sad that we live in a world where the cube is now the "good" option.

If I ever have another company, if I can't afford the office space, I don't
need the person. Office space is cheap compared to salary and wasted
productivity.

------
tedks
This article has depressingly little about _how_ Microsoft went about changing
the culture from a waterfall to agile mindset. The article is also pretty
rosy; I'd expect a little more bumps on the way.

~~~
Locke1689
What do you want to know?

Culturally, I think it's important to notice that VS is really a bunch of
smaller teams put together, and not all of them have the same development
strategies or systems.

So the biggest motivator here seemed to be a few pioneering teams who thought
they had a better way to develop software, and had support from leadership.

So the pioneering teams pushed forward and started to put up measurable
results. I think after that culture is bound to follow.

~~~
tedks
I'd most like to know how the developers reacted -- to losing offices, to
speeding up dev cycles, to changing up testing. Presumably some of them were
supportive, some of them were against it, but what were their reasons, and how
did they react to the change?

I think it's more likely that the early adopter teams had some measurable
result, and then management pushed the change through to other teams. So how
did those teams react?

The article just paints a very optimistic picture. Something as big as VS,
there's a lot of stuff to actually change when you go about changing things. I
feel like there's just more to this story.

------
jacques_chester
I remember reading about changes to development during the Windows 7 project,
which I wrote up[1] for a different lay audience.

People underestimate Microsoft. It has enormous inertia, but historically
enough introspection to recognise strategic errors and reorient. The most
famous being accepting that the Internet was not going away, circa 1998.

[1] [http://clubtroppo.com.au/2008/10/20/microsoft-
rebooted/](http://clubtroppo.com.au/2008/10/20/microsoft-rebooted/)

------
BmoreDaniel
The fact that specification and documentation are abandoned is pretty sad.
Software should be adequately specified and specs should be kept up to date
with code. Code is not a spec.

~~~
drtse4
The fact that you were downvoted is extremely sad. Downvoters, good luck
understanding how the next crappy project[1] you'll inherit was supposed to
work without even a one-line specification describing what the reasoning
behind certain choices was!

Everything about methodologies should be taken with a grain of salt, what
works somewhere, with a specific set of people and for some projects is not
guaranteed to work anywhere. And not every aspect linked with "old"
methodologies should be viewed as pure evil.

Consider that many of the ideas that ended up in the agile manifesto could
already be found in Peopleware from the eighties and that no methodology is
the last. There was Waterfall, RUP and other clones, with the Agile wave
someone defined XP (now dead) and after that Scrum. Now even Scrum is seen as
something with too much overhead and people start turning to custom solution
that use kanban/kaizen/etc...

[1] Referring to a project that has some logic worthy of benig explained,
interaction with external components, ecc... not some CRUD.

------
curiousDog
The private offices were one of the best parts of working at Microsoft. Open
plans suck and I blame facebook/google for perpetuating this fad ;)

------
kethinov
Here is a repost of a comment I posted directly to the Ars Technica thread in
reply to the author endorsing Agile/Scrum and expressing ambivalence towards
telecommuting:

"That's 20th century thinking, Peter! Marshall McLuhan would be disappointed!
[https://www.youtube.com/watch?v=NNhRCRAL6sY](https://www.youtube.com/watch?v=NNhRCRAL6sY)

Spontaneous collaboration can happen just as effectively with a remote staff,
but you have to default all your channels of communication to digital ones.

Instead of a culture of shoulder taps, use IM.

Instead of a culture of hallway conversations, get the entire team on a
permanent group chat.

Skype is one of the best tools for this, so it's ironic that the company which
owns it isn't making the best use of its own tools! ;)

The guys over at Basecamp did a great book recently on how to do this remote
collaboration stuff right called "Remote: Office Not Required"
[http://37signals.com/remote](http://37signals.com/remote)

It's a great read. I read it recently while on the plane to a meeting that
totally could have been over the internet. The irony was not lost on me.

It's also worth noting that Agile/Scrum is not universally well liked anyway.
In fact it's incredibly divisive. People who love it seem to _really_ love it
and people who hate it seem to _really_ hate it.

For example, here's a site parodying the Agile Manifesto, asking the world to
adopt something more modern:
[http://asyncmanifesto.org](http://asyncmanifesto.org)

And here's a much saucier (and perhaps less serious) take on the same idea:
[http://programming-motherfucker.com](http://programming-motherfucker.com)

TL;DR: Agile/Scrum is a management fad. Collaboration can succeed or fail
using any methodology. All the blind praise the media spews for Agile/Scrum is
arguably harmful to discussing what is and isn't effective management."

Original post: [http://arstechnica.com/information-technology/2014/08/how-
mi...](http://arstechnica.com/information-technology/2014/08/how-microsoft-
dragged-its-development-practices-into-the-21st-
century/?comments=1&post=27347511)

~~~
AndrewDucker
"Spontaneous collaboration can happen just as effectively with a remote staff,
but you have to default all your channels of communication to digital ones."

So, if you handicap your local staff to use only a fraction of their
communications capability then your remote ones are just as good?

Seriously - I've spent a large amount of time dealing with offshort staff and
onshore staff, and staff both in the different buildings, the same building
but different rooms, and staff in the same room - and having people sitting
right next to each other makes a massive difference to the communication
bandwidth.

The ability to turn your screen towards a co-worker, say "What do you think of
that?" and get a reply three seconds later is _fantastic_ - and simply
impossible with remote communications. (Where you can ping them on IM, wait
for them to notice the message, start a screen-share, wait for them to accept,
and then wave your cursor over the bit of screen you want them to pay
attention to. It's effective, but it's nowhere near as fluid as pointing and
handwaving.)

~~~
RogerL
Depends on what that other co-worker is doing. If you are both aligning
buttons on a windows form, sure. If the person being interrupted has 10
minutes of debugging state in her head, well, there goes over 1/2 hour of work
(10 minutes to build that state, 10-15 minutes to recover from the
interruption, another 10 to get back to where you were).

~~~
overgryphon
Which is another good reason for in person communication- you can see if your
coworker is intensely focusing and give them space. Pinging them on IM is
distracting and interrupts them regardless of what they are doing. Pinging an
entire team on the "team chat" is even worse.

~~~
kethinov
Easy solution: set IM to do not disturb and mute notifications until you're
done with the intense focus task.

------
kelukelugames
I left Microsot recently. Going from desktop development to web development.
One of my ex-coworkers told me web and mobile development was a fad. -_-

~~~
CmonDev
Client web development _is_ a fad. Using a document markup language and a
scripting language to build apps - what a joke. And what is this "desktop
development" you are referring to? When it comes to modern development,
desktop is just a subset of the native experiences, all of which could share
the same logic (e.g. via Xamarin).

------
shmerl
Also, lock-in tactic [1] is so much last century, but MS is still quite slow
on dropping it. With general decline of Windows domination they'll drop lock-
in approach even more, but that's still in the future.

[1]
[https://en.wikipedia.org/wiki/Criticism_of_Microsoft#Vendor_...](https://en.wikipedia.org/wiki/Criticism_of_Microsoft#Vendor_lock-
in)

~~~
bentcorner
Look around you, lock-in is everywhere. For example, it's the bread and butter
of social networking.

~~~
shmerl
_> Look around you, lock-in is everywhere._

Only in markets with poor competition. I.e. in unhealthy markets.

MS is used to such situation, because for a long time they were in a very sick
market, where they dominated heavily. Lock-in was used to preserve that
domination. Now the situation has changed, and them sticking to lock-in
actually harms their position more than helping them to preserve their grip on
the market. They slowly realize that, but they could do it faster. Moving
slowly has become their habit, exactly because of the above.

Competition does wonders. Remember the times of heavy IE lock-in tactics? They
are gone because of the competition.

~~~
bellerocky
> Only in markets with poor competition

This is blatantly and obviously false. Mobile has lots of competition, and
lots of lock in. Apple's App Store, Google Play Services on Android, DRM on
Kindles, DRM everywhere. I can watch Amazon Video on iOS and a Kindle Fire but
not on an Android Tablet. I can get a gmail app on iOS and Android but not
Kindle Fire. It's lock in everywhere. On Apple's ecosystem, on Google's, on
Microsoft's and even on Amazon's.

~~~
shmerl
_> Mobile has lots of competition_

Not enough really. Current situation of two heavily dominant participants is
not called a lot of competition.

Other competitors are too much behind, barely making any traction in the
market. And it shows. For example getting native drivers from hardware
manufacturers is close to impossible, unless they are requested for existing
incumbents. That's a perfect example of implicit lock-in caused by the lack of
competition in the mobile space.

Another example are mobile browsers which are dominated by these incumbents.
Again, not enough competition there.

~~~
bellerocky
> Not enough really.

Now you're just devolving your argument into a No True Scotsman fallacy.
Mobile has a ton of competition, Samsung just lost the top spots in China and
India. If anything it's lock in that's preventing it from being more
competitive if anything.

~~~
shmerl
_> Samsung just lost the top spots in China and India._

And? Samsung's own OS is barely registered on the market (Tizen). Which
demonstrates poor competition on the scene dominated by Android and iOS.

 _> lock in that's preventing it from being more competitive if anything._

As I wrote above, lock-in can turn around and bite the one who is using it.
It's a crooked practice.

~~~
bellerocky
I don't understand your argument anymore, I think we do agree that lock in is
bad, so that's good.

