Trust, Users and the Developer Division | Hacker News Reader

Trust, Users and the Developer Division

m.facebook.com

51 pointsayi42 comments

As someone who's had to develop windows apps every few years, from Win16 to Windows 8, wow, I don't even know where to begin. Windows has always been a mess, long, long, long before CLR/.Net. The phrase "just work" came from the macintosh world, to contrast the experience you'd get on a mac versus the mess you had in the windows world with even the most trivial hardware devices (plug & pray) or apps (dll hell). I don't know where he got the idea that DOS apps "just worked" on windows -- MS spent a lot of money and effort getting the big apps to work when running on/in windows, but that effort really only helped with the big apps. Lotus 1-2-3 worked, but many apps wouldn't without setting up DOS-box settings.

But, let's put all that away. Everyone's guilty of looking at the past through rose-colored lenses. OWL was actually quite nice. MS's response, MFC, was an awful bare-thin wrapper over the windows API -- and that pig needed a lot more lipstick. MS was right to dump it. The problem was, looking from in from the outside, MS had too many cooks in too many kitchens, trying to do everything as fast as possible. In response, documentation was always pretty bad (there was lots of it, but the quality's pretty low), the APIs were rarely clear or straightforward, and you ended up single-stepping your debugger to figure out what the APIs really did.

Frankly, I think the APIs were always awful enough to warrant fixing, but they were never organized enough to do the real work in fixing it. It's not something you can grunt through, it requires a cohesive set of patterns, abstractions, mechanisms, and conventions. That kind of agreement just doesn't seem possible over such a large and contentious organization.

Yeah, I don't think there was any "golden age" for MS coders. Each individual tier gets to a point of "okay, now we've got this figured out" and then they deprecate it and give you a new mess from scratch.

The biggest disappointment is how many times they've started from scratch within the .NET framework. The constant churn of database APIs mentioned in the article is a great example. Finally now MS has followed a more open-source-ish development process with EF.Net and MVC - ironically by switching to faster iterations I feel more confident using it because I know it's being well cared-for and won't get abandoned and deprecated.

The big disappointment is how .NET has failed to be "write once run anywhere" even within Microsoft's universe. Every platform except the server gets a restricted subset of it, and you often don't find out that your subset is unavailable until run-time.

Ex-MSFT here. Even more than API churn, the organization is indeed the crux of the problem.

As the OP alluded to, the way Microsoft is built today it has a fatal organizational flaw that prevents creating the next great Windows platform. The platform/dev tools team and the OS team are in completely different business groups within the company. The platform team develops the wonderful .NET platform for small/medium applications and server apps while the OS team keeps crudging along with Win32. Managed languages have their place, but they have yet to gain traction for any top shelf large-scale windows client application vendors (Adobe, even Microsoft Office itself, etc.)

Major client application development still relies on unmanaged APIs, and IMHO the Windows unmanaged APIs are arguably the worst (viable) development platform available today.

What Windows needs is a new subsystem/development platform to break with Win32, providing simplified, extensible unmanaged application development, with modern easy-to-use abstractions for hardware services such as graphics, data, audio and networking.

What Apple offers is not some revolutionary OS architecture, but their Cocoa and Carbon APIs, and their Core libraries which are for the most part, well thought out and have survived multiple architectural transitions (PPC -> Intel -> ARM, desktop -> mobile).

Something similar is starting to come to fruition with WinRT, but the inertia in large scale apps is unbelievable.

It's somewhat ironic that your reply to an article about how M$ needs to pick a technology stack and stick with it is a comment about how is "What Windows needs is a new subsystem/development platform to break with Win32, providing simplified, extensible unmanaged application development, with modern easy-to-use abstractions for hardware services such as graphics, data, audio and networking."

Well, the point really is -- Microsoft has to eat its own dogfood. If you're developing tools, use em to build Windows! The pain you feel will be the pain other devs feel, and you'll write tools to compensate for that. But the large teams are too big to fail, so they rarely experiment, leaving third-party devs or small projects at risk instead.

This article is fan fiction at best.

For example, there was a big push toward tools support for Office. MS said this was a pillar for VS2010. I spent a lot time doing Office development with VSTO/VSTA.

Windows Phone 7 was released with a new user experience and was the answer to iOS and Android. It actually got developers excited. But, a year later with Windows Phone 8, Microsoft told all the developers that the investments they made in Windows Phone was a waste of time because none of their apps will work on Windows Phone 8.

Huh? That never happened. Virtually all WP7 apps work on WP8.

Yeah, that's a bit backwards. Really, what happened is they broke backwards compatibility for device owners which is a much worse scenario:

You couldn't upgrade your device to the new OS!

Why is this worse? It leads to a very immature platform with few avenues to improve upon it. At least iOS 7 makes it easy to still target 6, where the hard part is UI changes. Microsoft changed little in the UI between 7 and 8, but somehow the phones and tools remained incompatible.

"Again, we already were in a world of HTML and CSS but the teams were blinded and would use excuses on how they can build a better render tree."

And toss in JS to get stuff done, too? Web frontend tech is quite a mess, and I can't imagine how anyone thinks it's not possible to design a better system from the ground up.

It might not be practical, and it might have traction issues, but working with WPF (XAML's just a serialization format...) was vastly easier than HTML and CSS.

"This takes us to the Microsoft Developer Division or "DevDiv" (approximately 1993 - 2002) and later know as "DevTools" (2002 - 2013)."

I'm a bit confused by this, as it's certainly been called DevDiv between 2008 and the present.

"We had to rewrite VB to use the VS shell and this fundamentally changed the VB product and it user base forever. "

There's no reason the VB6 language couldn't have been changed to use the new shell or even the CLR. The real culprit was the decision not to attempt backwards compatibility between the new VB ("VB.NET") and the old one.

Whether commercial or open source, only time and market share can tell us which platforms are going to be winners.

I started as a Windows developer when I was 12, and enjoyed the transition from ugly MFC/VB6 to .NET, which was pretty well-designed.

They lost me when they changed “the” data framework from ADO .NET to LINQ to SQL to Entity Framework, simultaneously obsoleting Windows Forms in favor of WPF, and later in favor of Metro-ish Silverlight.

All this while Apple sticked with Foundation and Cocoa and built greater / high-level frameworks around them.

As Dare put it in the comments: “... platforms are being born and dying so often that it seems you need to subscribe to Mary Jo Foley's latest breakdown of Microsoft internal politics before deciding what to bet on...”.

Wait, someone is actually still voting for MFC?

Anyway - developers have long complained about Microsoft moving their cheese; when that's how Microsoft makes money it is guaranteed to be never-ending!

http://realworldsa.blogspot.com/2011/11/microsoft-moved-my-c...

I don't really understand stuff like that.

> The Windows trust and value proposition was always compatibility,

There are other platforms, you know? If you say "compatibility", you might want to add "compatibility with other proprietary microsoft stuff".

> low-cost devices,

They could be cheaper when not being forced to pay for windows with them.

> and an open architecture (to name a few).

I don't really get it. Almost everything he talks about is proprietary closed source microsoft specific stuff. How "open" of an architecture is that?

But then I don't really understand why people would want to tie themselves completely to proprietary microsoft technology, even if it did not change so much.

Aren't there enough actual open and cross platform frameworks that people could use? Why specialize yourself to create software that does and will only ever work on windows?

You have to put his words in context. For instance when he said "compatibility" he is talking about backward compatibility which was the jargon that MS used at that time.

> "How "open" of an architecture is that?"

Again is a jargon that was used way before that Linux came to light. He is talking in comparison with Apple which hardware was closed.

compatibility meant that your printer and scanner kept working...and your programs that you paid for kept working.

but whatever...MS is teh sux0rz! Hah!

Happy now?

Compatibility means you can take a Win16 VB program and run it on Win64 with a very high confidence that it will "just work". This is something grown-up OSs do... If you had a program that broke between Solaris version Sun would consider that a bug in Solaris and fix it for you.

I thought Win16 support was discontinued in Win XP??? Not so?

Nope. In fact, Win16 code still works on Windows 8 as long as you aren't running 64bit (and that is a processor limitation not an OS limitation).

Kinda huge, but interesting reading. I don't like windows, never did, (probably) never will - so the will to develop on windows has never reached me.

But it's a good bad example for others to avoid.

I am so glad you mentioned Hailstorm. I was in MSN when that was announced and we just all looked at each-other and went back to writing our C++ code.

> The Windows trust and value proposition was always compatibility, low-cost devices, and an open architecture

What?

It is strange how words lose their meaning once the concept becomes common-place.

We don't say motor-vehicle anymore, electric lamp, and so on. People would probably think you're weird if you do that :)

Sometimes I think computer science history need to be at-least an elective subject for software engineering/computer science courses.

Microsoft's products were never an example of open architecture; the meaning of open architecture didn't change much in the last decades.

It actually did change. In early eighties it basically meant support from different vendors and the ability to extend the hardware by adding new components.

So for instance, the first IBM PC and Apple II were considered open, because you could extend it by adding peripherals. On the opposite side, the Apple IIc was closed because it wasn't upgradable from outside of Apple.

In the case of MS, they were really opened in terms of hardware that would accept since was the fabricant who would provide the drivers.

Lately, pretty much all PCs are open under that definition just devices like iPad or some smartphones would be considered closed.

Sorry, but by only considering early PCs you are ignoring most of the IT industry in that era. The PDP-11 came with full schematics, that was normal in the day, that was what "open" meant in the day to engineers. The early proprietary Unix systems, although they were proprietary and you couldn't share the code, they usually came with the source code. It was considered normal in that day to modify the kernel and recompile it.

The PC business guys reused the term as part of their strategy, but for engineers it always meant something else.

>> Sometimes I think computer science history need to be at-least an elective subject for software engineering/computer science courses.

This is a really great idea, never thought about it before. Possibly even a decent book idea. Something that covers the hardware/software landscapes over the past 30 - 40 years, say.

It means that any company can make hardware and put Windows on it, and anyone can make software for Windows without paying Microsoft. This set Windows apart from various platforms in the 80's that are now dead, game consoles and Apple.

Linux is much more open of course.

Compatibility is a red-herring, as Valve is about to show us (in spades)

Unless someone who just has to get something done needs to print something...The MAC has made a lot of progress in getting people to accept other platforms...

I wish Valve all the success. More platform choices would be good...I just doubt that they will succeed against Sony, MS, and Nintendo...but hey, I've been wrong before.

This gets reposted here every couple of days. I get it...you guys like Go and Rust. Most of you are Open Source all the way. That's cool. Some of us actually like MS technologies. Not all of them, but some of them are great. I guess I'm just getting tired of the fanboy need to run down things you don't like.

Anyway, it sounds like some of the new work at Microsoft gets that they need something closer to the metal without dumping c# developers. I won't link to it, because it too was linked to death around here.

> Some of us actually like MS [...]

You sure? :-P

Yes, all the way to the bank.

Look, I still write my software with MFC, I'm no longer a fanboy of 'compiles one day, not the next' api chasing with many OS libraries, but you have to admit that the points he raises are valid. VB to VB.Net? XAML? ADO/DAO and all that? These things are serious frustrations, and I probably would have ran from the platform too if I was heavily exposed to them.

Right, you ever track all the changes in Php or Java? The idea that something being open source means that there aren't changes is just nonsense.

Change happens. It's life. I guess you just pick your poison.

Forget about PHP. Java's development pace has been glacial the last few years (though Oracle seems determined to do something about it), but when introducing new features, it's rare that backward compatibility breaks (even when it would be desirable).

Explain to me exactly when the core Java stack has massively deprecated something as core as database access in favor of a marginally-redesigned but API-incompatible New Hotness. Thanks.

"Change happens. It's life. I guess you just pick your poison."

What? No, it doesn't have to, or at least not at the pace of once a year. It's not because everybody else does it, it's OK all of a sudden. I like php exactly because it's relatively stable (I'm not talking about the frameworks here, let's not go there).

But fuck all those others - that wasn't my point. The win platform could have been so much better for pragmatic developers who just want their foundation to be stable to just get shit done. Why abandon C++ in the way they did? Why the 4-5 different paradigms for UI development? Not incremental changes, or libraries, but completely incompatible new ways of doing things, and if you don't follow the trend, you'll be left out. If the dev tools group had known their place, they would have served developers as customers, instead of the situation we have now.

Of course the vocal minority of chase-the-next-thing developers brought this on us as well, it's similar to the 'disregard everything from the past and reinvent everything because I'm so much much than everybody else' often displayed on sites like here and reddit programming - 6 years ago Python was the hot thing, 4 years ago Rails, 2 years ago Node and I'm not even sure what it is now. Anyway, my point is that it's innate in inexperienced software people to want to dive into tech for the sake of it and forgetting the business case behind it. And that is what holds back the industry as a whole, reinventing and re-implementing everything every few years under the guise of 'innovation' or 'we'll do it right this time', but it's really just NIHS. And that goes for the Windows ecosystem, the OS ecosystem, others as well I guess but I don't know them well enough, or they're not old enough yet for this pattern to unfold).

I dont think the guy who wrote it had any interest in Go and Rust, otherwise he would be applauding Microsoft's approach to ruining their own developer ecosystem.

In fact, my read of the article is "Microsoft, we were going to make money together, why are you throwing out the baby with the bathwater?"

If MS develops an altogether new thing, what's the chance that it wont get thrown out in 2 years, again?

I primarily work in the MS ecosystem and it is something I meet with trepidation with every product announcement.

(Also, if this was posted every couple of days, wouldn't it need to be posted a little longer ago than Jan 7?)

No, no. It's just Microsoft.

Borland and Digital Research put MS to shame back in the late 80s. (compilers and OS)

Then I got Linux around 95 and really liked it. MS API changes were maddening. (had been using a dozen other OSs, mostly *nix, at work the 2 or 3 years before that)

The last few years, I've had to interact with OSX, iOS & Android. It's not about open source vs closed, it's about "works" vs "sprawling, shifting, unreliable mess".

Perhaps MS's foibles would be more forgivable if it weren't perennially shoved down my throat as "industry leader". In what, crapware???

... "industry leader" - in marketing.

>But, a year later with Windows Phone 8, Microsoft told all the developers that the investments they made in Windows Phone was a waste of time because none of their apps will work on Windows Phone 8.

Isn't that completely false? All WP7 apps run on WP8, bar a few minor incompatibilities.

He's probably got the timeline a bit mangled in his head and is confusing app compatibility with device compatibility (which WP8 did break). Although XNA apps did get stranded in a legacy quirks mode.

99% of WP7 apps worked perfectly well on WP8. The only ones that had issues were usually the ones that had managed to get exemptions from Microsoft to use underlying private APIs that may have changed (hence private).

Reply on news.ycombinator.com