Comment by narrator
8 years ago
The thing about the MS platforms that has always been an issue is that they change the developer APIs around all the time. Every year they come out with the latest greatest way to access a database or whatever and it really isn't that much better than what they had last year, but it still requires a rewrite.
Yes. They also rewrite stuff half way through and tell you it's the same project just to piss you off. Windows Workflow and Windows Communication Foundation for example.
I'm really disinclined to invest in any of their technology because my headspace is finite and I want to deliver business value, not change the unworn carpets once a year.
It's also just such a bad idea because they never get to mature their features, add uniqueness or allow 3rd party devs to build the ecosystem. They just build the same thing over and over again while their competitors keep refining, innovating and adding features. Really a bound to fail strategy
Exactly that.
The feedback loop is shit as well. Out falls a broken pile of shit for a CTP. No one accepts any feedback. It hits RTM, no one accepts any feedback. Two years down the line, the same bugs are open.
You should hear the partner reps wanting to cry when you report a bug in something that you NEED a fix for and are paying support for. You get fuck all other than a registry fix or a hack even if the mainline product is falling to bits across a thousand or so users (which is what happened to us).
Money where the mouth is as well. Typical shit:
https://github.com/Microsoft/SCVMMLinuxGuestAgent/issues/2 -> ignored. Regularly hoses our new VMs deploying windows on SCVMM.
https://github.com/dotnet/cli/issues/3093 -> fuck you go away we're just going to take your data unless you set a magic variable even though no one wants to give it away as indicated by the ticket and there are bugs in the configuration and it causes people massive audit problems.
4 replies →
Maybe MS and the FLOSS world aren’t as different as we thought. Look up CADT by Zawinski for details.
1 reply →
Same here. I can't even imagine how 3rd party tool developers feel. Let's say you have a grid component. In the last few years you had to do a Winforms and several XAML versions( WPF, WinRT, Silverlight and now UWP). The XAML look superficially the same but all have their set of weird limitations and bugs. I am definitely done with Windows desktop.
Wow, imagine someone trying to make this statement 15 years ago...things have sure changed.
16 replies →
Most of the legacy stuff continues working long after it's the hot new thing, though.
Until you hit a bug. The one that killed us was we had to deploy a registry fix to 2000 workstations at hundreds of companies because they broke ClickOnce in IE9 and later. It still isn't fixed today. We still have to eat the administrative cost. Over time, that's a shit ton of cash leaked out on a mistake the vendor has made.
6 replies →
But it never matures. You are stuck with half-assed stuff in many cases.
...sometimes to the extent where the hospitals in your country get crippled by malware :-/
Basically "Fire and Motion" in a situation where that strategy is NOT to their advantage.
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
Wow that was a great read.
As stupid as [my reply] may sound, thanks. Your comment prompted me to read that, and you were right, it was a great read.
I do get where you're coming from but I have a more moderate perspective.
I mean we can certainly point to examples where that's the case: Silverlight's a classic here, if that term's even appropriate, and then of course there's WP7, 8, and 10, as mentioned by the grandparent. And these are clearly not trivial examples.
Nevertheless, I must point out that large bodies of code I wrote in the mid-noughties are still running substantially unmodified today. What's perhaps interesting is that these codebases are desktop tools, where it can be argued that Microsoft have achieved true mastery (after WPF came out everything notably settled down, and unlike MFC and WinForms it really hasn't been replaced).
It tends to be other areas where the worst of the churn has occurred: web, mobile, database access (how many versions of EF to get it right?). Of course, these are areas that have seen significant growth over the past few years.
Still, even in their worst period Microsoft did not begin to approach the lunacy of framework churn in the JavaScript world.
My pet theory is that this is because the dev tools department at Microsoft is not a pure cost centre with the sole task of improving the platform, they have Visual Studio licenses to sell. If there is any truth in that, we should see a slow decline in "API of the year" as non-subscription licenses (where customers are prone to skip an update when it does not have enough "revolutionary must-haves") are slowly phased out.
This is the single most baffling thing about Windows to me, and it always has been. Why insist on trying to sell Visual Studio licenses, instead of maximizing the amount of software written for your platform(s)?
It doesn't even seem like they're acting in rational self-interest by doing that.
I suppose their rationale is that they give a lot of development tools away for free, and you only really have to pay for the really enterprise-y editions. I guess? Still dumb to me.
MS DOS used to come with a Basic interpreter, if that's what you mean ;)
Later, when the PC platform became what we know today, there wasn't really a channel for free (small f) software except shareware magazines and Microsoft surely would not be seen with that crowd! In those days, Microsoft wasn't concerned with losing the heads and minds to another platform but with losing the revenue to Borland. Since then, more and more has been made available (I still fondly remember laying my hands on the first Windows SDK day came with a free command line version of the MSVC compiler), but it is a culture shift that won't be rushed as long as there are no really pressing reasons.
> Why insist on trying to sell Visual Studio licenses, instead of maximizing the amount of software written for your platform(s)?
For a while now they haven't been doing that. Community editions are just as good as paid ones and before that Express versions were still comparable if not better than open source IDEs.
Licensing their dev toools gives discounts on tools for development which pushes orgs to buy for-realsies licenses.
Partnering with them gives rebates on their dev tools licenses and gives you kickback when you push your customers to buy for-realsies licenses.
VS is just the fishermans hook, the haul are the 600 SQL server CPU licenses you have ticking all day, every day.
> The thing about the MS platforms that has always been an issue is that they change the developer APIs around all the time.
There was a time when MS would detecting the binary name, and change core kernel functionality just to provide bug-compatibility to older versions of Windows. By that time they got an unbeatable market dominance...
That’s because you don’t get promoted there unless you do something new and super complicated. That’s also part of the reason why Android SDK is such a pile of garbage, the other part being they rush half baked shit to market all the time.
In Microsoft's defense, they also tend to support their stuff for a long time. I work with MFC every day. It's 20+ years old and still being developed.
I stumbled over a few bugs in WPF (worked in WPF3.5, would hang in WPF4), which were, for at least 4 years, documented and "WONTFIX" with no acceptable workaround (workaround provided slows things down by a factor of 10 under some circumstances).
Maybe it's fixed with the reinvigorated WPF on Win10. I don't care anymore, but I do caution anyone to ever use any MS Technology younger than 15 years.
I'd say .Net Core is worth considering, but no real UI story as of yet... pretty nice for services though.
OMG. MFC ? You mean Microsoft Foundation Classes ? mmh. that stuff is still supported ? eventhough there was/is all the .NET crazyness. That's actually pretty good of MS. I guess the main question is: how do you in advance if you got a MFC-like library from MS with 20+ year support vs a library like Sliverlight where they drop support and let you alone with a migration to a different platform ?
Maybe there's a cautionary tale about being an early adopter here. I don't know if I would start a new project with MFC, but it was a fantastic decision in 1996.
In a way, I think it's harder to pick technologies today for large projects. It seems like if something isn't new and growing steadily, it's stale and fading fast. What are the tools and frameworks with a long, healthy middle age ahead of them? I'm learning Go right now because there are a couple of web services I need, but I'm not that confident that I'll be able to run the same code for the next 20 years.
3 replies →
As someone that worked on migrations to Silverlight and then to UWP, I still don't understand why these are seen as such big deals. The APIs were more similar than they were different and XAML is still XAML. (The only big loss from Silverlight was being able to browser-host it, but even then that was probably worth losing for the greater good to avoid terrible plugin websites.) The only thing they really dropped was Silverlight as (an unnecessary) brand name.
If they had semvered the whole thing: Avalon => UWP 0.x, WPF => UWP 1.x, Silverlight => UWP 2.x, Windows 8.1 UAP => UWP 3.x, today's UWP ~=> UWP 4.x, I don't think any developer would have blinked, I feel like we'd have a lot fewer people feeling they dropped support for things... Then again, developers like to complain when their cheese is moved, it could be just like Python 2 versus Python 3 or VB6 versus VB7.
15 replies →
> how do you [know] in advance if you got a MFC-like library from MS with 20+ year support vs a library like Sliverlight where they drop support and let you alone with a migration to a different platform ?
If it is old, it will be supported for a long time. If it is new, the odds are mostly on it not surviving. Ever wondered why so many people insist on using outdated stuff?
You get a better deal from open source. But even there you may not like the possible consequences of using non-mainstream things.
They support the stuff they can't kill for a long time.
You can still run VB6 apps but try running a .net framework 1.0 app!
Easy, just get the runtime from here.
https://www.microsoft.com/de-de/download/details.aspx?id=162...
I'm not sure it requires a rewrite, the old stuff still works. The trouble is the constant churn is draining, I've pretty much abandoned the platform because of it. We keep hearing about new JavaScript frameworks but we had exactly the same from MS: win32 => MFC => WTL => VB => WFC => Winforms => WPF => Metro => UWP, no doubt there is something else just around the corner.
Calling that "constant churn" is a massive exaggeration. First, using WTL or WFC were just bad decisions because those were side-projects and MS never told companies to switch to that and definitely didn't encourage rewrites into that. They were not replacements of anything by any stretch of imagination. That's like complaining that MS made you rewrite your app in Lightswitch or IronPython. It is just a side-project, not something ever intended to become the main MS dev stack.
So realistically for most MS stack devs it was MFC -> VB -> WinForms -> WPF -> Metro -> UWP. And MFC was released 25 years ago. So they switched 5 times in 25 years. You could possibly add Silverlight in there (which is extremely similar to WPF so only half-counts for churn purposes).
Now, I agree that the Metro -> UWP part was unnecessary because they were doing the same thing twice so they should have gotten it right the first time (and I think the whole UWP concept is worthless anyway).
If we look at MFC -> VB -> WinForms -> WPF, all those technologies provided a lot of value to us and it was very useful to have them. Would you want to still be programming in MFC today? I am pretty sure you wouldn't. I do not feel any "churn" from this (note: I never switched to Metro/UWP because I considered it a step backwards, unlike the previous "switches", so I stopped at WPF when it comes to desktop), I can barely remember programming in VB 6.0 because it was such a long time ago.
Saying that's "exactly the same" as the situation with web is ridiculous.
Your 5 times in 25 years suggests an overhaul every 5 years. Context matters. WPF became mainstream in 2007
WPF, Metra, UWP, and Silverlight in 2007 -> 2017 is 4 overhauls in 10 years or an overhaul every 2.5 years.
Also not fixing bugs in earlier tech creates a compulsion to switch to the next tech.
1 reply →
Microsoft used to only make money selling software licenses. This has changed with Azure cloud stuff, but the majority of their incentives still don't align with their developer/customers.
With Azure they can bill you for the licenses and the computing platform, while also ensuring a pretty impressive degree of lock-in once the platform is sold.
Not only are their incentives still out of alignment, the massive consultant eco-system they maintain is still incentivized to push the same-old lock in in a new costume.
SOAs are like partners in bed... it's not just about who you're sleeping with, you gotta think about who they have slept with too.
Picking Apple as an example, other are possible.
Object Pascal, Powerplant, Quickdraw, Java Bridge, Quicktime, QuicktimeVR, Carbon, OpenGL, ...
Apparently only Microsoft does it.
This is exactly what made me quit desktop development on Windows. MFC, ATL, COM+ learning going to waste was a bridge too far.