[JoshuaJB]

I spent this summer working on a Windows team at Microsoft, and this article is incredibly insightful for an outside perspective. The dev process internally is basically just waterfall sped up 3x. While my team only permitted code commits after adding to and running the tests, that did not seem to be the norm. Almost weekly one of our sister teams would not only break a feature (that happened pretty much every day) but break the build. Things got so bad that as we approached this most recent release, management (under pressure to reduce the number of failing tests) just disabled the majority of our failing tests.

While it might slow down some of the feature work, I think it's clear that an always release-ready master branch is the path forward for Windows. Some of my more enterprising managers were already working on splitting our subfeature out of the Windows release tree just so that we could do that when I left a couple months ago. I hope they succeed, otherwise I worry for the future.

[alxlaz]

Hey, do you accept congratulations from someone who's used nothing but Unices for ages now?

The stuff you and your (now former) colleagues have put up lately is remarkable. The last version of Windows I used on my home machine was Windows 2000, and Windows 10 is the first one I've looked at since then and said you know, I could actually use this thing, I guess.

I don't trust your (former) bosses enough to make the switch, but you folks have done some pretty amazing stuff lately.

[_greim_]

Ha! This makes me chuckle. I myself was a web developer during the decade of IE6 dominance, advocating for Mozilla all the while. Despite it being trendy and contrarian to praise "M$" nowadays, I feel like that ice is only now beginning to thaw. Not so much the coming of spring, but a slight decrease in the hoarfrost on the windowpane. Great shuddering booms as the lake ice cracks. That sort of thing. Yes, if Microsoft continues being non-horrible, I may eventually warm up to them :)

Shuffles back to corner. Furtively plays with new TypeScript toy. Hisses at passerby.

[godzillabrennus]

I remember installing Mozilla Firefox on family friends computers in those years and changing the icon to IE so the average person wouldn’t notice and the world would have one more Firefox user.

I was a teenager.

[gear54rus]

interesting. did it work?

[seba_dos1]

From my experience, it usually did.

[zaphirplane]

Not with my hank and other banks

[godzillabrennus]

It worked perfectly.

[mlazos]

> new TypeScript toy.

One thing I’ve come to realize is that MS definitely excels at programming language design, coming out of college I had no experience with the MS CLR languages and I was pleasantly surprised at how well designed and usable their languages are.

[ams6110]

That's funny, because Windows 2000 Pro was the version I liked the most.

[mixmastamyk]

Yep, a maintained Win2k with a real terminal and shell would be the pinnacle of OS interface design.

Remember when we were allowed to customize our own color themes?

[alxlaz]

I also liked Windows 2000, very much. I used it on-and-off (though mostly on...) while I was learning Linux. I switched around 2003 or so, I think. After that... up until Windows Vista or so I was just being a l33t h4x03 hipster kid. After that I was legitimately getting better stuff in Linux land.

[sizzle]

Windows 95 was a game changer for me.

[jowdones]

>> break the build... disable failing tests (under pressure)

This is the norm in the software industry. As grunts or lower management getting tasked with the impossible, saying "yes" and doing "maybe" is really the only way. What they (upper management) gonna do, fix it themselves?

[electrograv]

How about not releasing a software update until catastrophic bugs are fixed?

[pwg]

Sadly, when one gets away from open source development and sees "enterprise" and/or "government" (a subset of "enterprise") development, what one finds is that everything is almost exclusively "deadline date" driven. The PM's and/or upper level managers pick dates for deliveries (seemingly often without regard to ability to achieve deliverable X by date Y) at the start of any dev. cycle. The end result is the low level managers get pressured to "meet the date" and so the developers get pressured to go faster to "meet the date" with the result that often the deliverable X "meets the date" but is very buggy, hacky, ugly, hard to further extend, etc.

And then, of course, for the PM's and upper management layers, the fact that their project "met the date" is what is measured and congratulated all around. The product could be a stinking pile of XXXX, but "it met the date", so they get their kudo's, their bonuses, and the devs. and users are left with "stinking pile of XXXX".

[flarg]

As a PM I remember the halcyon days when my management would actually request a formal estimate and I would then work with delivery teams to calculate an answer and then add the traditional 50 to 100 pc buffer because I knew they were full of crap/I kept a personal record of their history of estimate vs reality. Nowadays management are in to top down planning so they don't ask for estimates, they don't add realistic buffers so they over promise with one hand and underestimate with the other. Seems to be a trend where everyone thinks they know how to do a PM's job.

[setquk]

And a stinking pile of XXXX is exactly what we end up with. Telemetry stuffed, file deleting bug ridden pile of fucking shit.

About ten years ago I had the option of taking the red or the blue pill. I took the Windows pill by mistake.

[camgunz]

Yeah but on the other side if you just let engineers do everything "the right way", we'll never deliver anything because there's always a "better" way to do it. I agree that "success-based planning" is ultra bad, but engineering needs to be held to some level of accountability.

Or maybe I just blame capitalism, haha. No deadlines! I do this because I like it!

[darcuss]

So this what happened to Evernote.

[rbanffy]

I bet they never tested that case.

Yes, they should have. adding tests long after the fact is next to impossible because, when you spend a long time not adding them, your codebase tends to degenerate into an untestable mess. One of the key benefits of strict TDD is that you feel the pain of testing your code before you write it, so your code is testable from the start.

[DominikD]

This must be new (maybe related to tons of experienced devs moving to other teams in recent years?) When I worked there around 2008 it was very rare for people to break Windows builds. Some teams were better than others but in general breakage was rare and often came from dev build system using previously generatrd artifacts vs nightlies building everything. Windows is amazingly complex. Comparing its codebase and process to smaller projects just doesn't make sense.

[DrPizza]

One of the (many) reasons I've heard they had to abandon Longhorn was that apparently it was essentially unbuildable. The build was broken so much of the time that they gave up and started over.

[DrPizza]

I wish you'd posted this as a comment on the article so I could have promoted it so that everyone would see it.