Comment by dtx1
8 years ago
I worked 3 years as a windows phone dev and i'm sorry to say but Microsofts efforts were ... almost insultingly bad.
It started with windows phone 8 and the Metro UI. Bad Idea. The UI was too far away from Android/iPhone to be easily ported and adding corporate design to it was hard as it was too different. Silverlight and XAML was okay for the time.
Then came windows 8.1 and windows desktop 8 which was universally hated. The whole fullscreen apps debacle was just horrible and all the unnecessary restrictions on store apps for desktop made no one ever consider porting their desktop app to a store app. The whole phone and desktop app in one was a joke aswell since it was (and still is!) horrible implemented. Did I mention they broke compatibility from 8.1 to phone 8? I didn't even bother starting all over again for windows 8.1 i just straight up skipped it.
Then windows 10 came and it finally looked like the UWP Plattform might do the trick. Well nope. The SDK is garbage. Scaling from phone to desktop is hidiously bad and afaik still not solved. The Live-Tiles got even worse since you couldn't programm them like the windows 8 ones. Just a whole mess. Couple that with the hillariously bad store interface (backend aswell as frontend) and 0 User engagement and it was bound to fail (as will all UWP apps)
You guys build a, I'm sorry to say but after 3 years of frustration it's fair to say, half-baked half-assed phone plattform that at no point had even a single feature that wasn't available better on iOS and Android, restricted the developers unecessarily, broke compatibility once a year requiring a complete rewrite and frankly build a product that only microsoft liked but was universally hated by their users.
It's a story of too little too late and a whole lot of arrogance on microsofts side.
Oh and don't even get me started on microsoft completely ignoring the european market where they actually got up to 15% marketshare of new devices sold for a while.
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
8 replies →
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.
17 replies →
Most of the legacy stuff continues working long after it's the hot new thing, though.
9 replies →
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.
1 reply →
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.
3 replies →
> 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.
1 reply →
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 ?
21 replies →
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!
1 reply →
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.
2 replies →
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.
There's a semi-contradiction in your post that I think speaks to some of the issues MS had:
"It started with windows phone 8 and the Metro UI. Bad Idea. The UI was too far away from Android/iPhone to be easily ported "
"half-baked half-assed phone plattform that at no point had even a single feature that wasn't available better on iOS and Android"
As someone who played around with WP7 when it first came out, I'd argue that the Metro UI was the best one available at the time. But the side effect of that is that it was different, and difficult to adapt an existing app to.
Essentially, MS needed to make a bold new platform with inventive new features, but also make the platform very compatible with the other major mobile platforms. You can't easily square that circle. Now, MS also messed up in a million and one ways (like my phone never getting a WP8 upgrade...) but I think their fundamental challenge was very, very difficult.
My wife had several Windows Phones in succession.
Her use of a phone is very practical: contacts, texting, weather information. All of this was available at a glance in a much much better way than either Android or the iPhone have. It was a better business UI.
It was harder to use if you had many apps. But seriously, having a phone open to the equivalent of Windows 3.1's Program Manager (which is what Android and iPhone deliver) is not great!
The iPhone opens to something like the Program Manager (but with little numbers showing which apps have active notifications).
Android opens to something like a Desktop, with some combination of Widget apps and/or app shortcuts. Mine is configured to show a clock, mini calendar, and weather. Incoming e-mails, SMSes, or other messages are visible in the notification bar. I could configure it to show me little previews of messages, but I chose not to.
Android has supported home screen widgets and activity shortcuts since forever. Live tiles are hardly better, they're just a very Metro-y approach to the same feature.
1 reply →
Thats imo no contradictions. Metro did things different but in no way better and felt severly restricted compared to android/ios ui design at the time. They banked on having everything look the same in the whole OS but never considered that certain apps just straight up wouldn't work with the metro UI concept.
> that at no point had even a single feature that wasn't available better on iOS and Android
According to the dates[0] I found online says Windows was the first to have a feature that would automatically connect to your cellular connection if the Wifi didn't work. Most consumers don't care but it is something I was surprised iPhones[1] and Android[2] didn't have at least at the time. In addition continuum is unique/better in many ways although that is more recent. It has been a while since I have used a Windows Phone.
[0] Windows 8.1 definitely had it in 2014 according to this https://support.microsoft.com/en-us/help/10652/windows-phone... I'm pretty sure Windows Phones predating this also had it although documentation seems lacking.
[1] Wi-fi assist was introduced in iOS 9(2015). https://support.apple.com/en-us/HT205296
[2] There are apps for Android that do this but at least this one is 3rd party. No sources says it predates 2015. I have not experimented with this on Android. https://www.guidingtech.com/54831/get-ios-like-wi-fi-assist-...
> first to have a feature that would automatically connect to your cellular connection if the Wifi didn't work.
Huh? Maybe my memory if failing me, but that's how networking on iOS always worked.
Previously to iOS 9 if you had a solid WiFi connection but were stuck in the LAN for some reason (broken DNS or captive portal, no WAN connection, broken route or whatever not affecting the LAN segment) you were toast and had to turn WiFi off. WiFi Assist solves that.
Perhaps he is referring to the long-standing habit of iOS to NOT drop the wifi until way out of range which would lead to an awkward hang. I think they fixed that in the last year or two, but it was pretty damn annoying.
> According to the dates[0] I found online says Windows was the first to have a feature that would automatically connect to your cellular connection if the Wifi didn't work.
This is the most infuriating feature ever. Google implemented it in 2014 in Android, and you couldn't properly disable it. Not even today.
I frequently need to connect to intranets where Google services are blocked for security reasons, and it's infuriating to fight hundreds of times with the settings so you can get the WiFi to work.
Then in my opinion it sounds like it is still not "properly implemented" with a toggle. Thank you. I have always been curious about Android. I do agree it's probably better not to have this feature by default then to have without a toggle. Just depends on use case.
1 reply →
Now they've introduced this "Mobile data has run out" which stops me from accessing my telco's app to check my prepaid balance, because it completely cuts off all mobile data. Just as annoying.
> If I recall correctly Windows was the first to have a feature that would automatically connect to your cellular connection if the Wifi didn't work. Most consumers don't care but it is something I was surprised iPhones and Android didn't have at least at the time.
I remember having an app on android that did that long before windows phone had it. It was able to turn on/off your wifi based on your location. Great battery saver.
> In addition continuum is unique/better in many ways although that is more recent. It has been a while since I have used a Windows Phone.
Samsung cloned it for their S8 Series and it seems to be actually usable from the start compared to windows continuum. Though by the time continuum was available, wp was dead.
> I remember having an app on android that did that long before windows phone had it. It was able to turn on/off your wifi based on your location. Great battery saver.
That is technically different although similar. I have updated with dates. Windows Phone definitely appears to have been first in this scenario unless you count rooted devices which may have something I don't know about.
> I found online says Windows was the first to have a feature that would automatically connect to your cellular connection if the Wifi didn't work.
If the wifi doesn't work, no phone will use it. If the wifi is BAD, that is completely different.
I am implying an inconsistent wifi with speed or LAN issues. The wifi goes down all the time at my house because of Spectrum/time warner cable issues. My iPhone prior to Wifi Assist will use the network at my house if it has a good wifi connection regardless if was broken or just slow.
I had the same experience while working on WP in 2012-13.
In early 2013, I reported a bug when some of the elements inside LongListSelector would disappear randomly on scrolling. LongListSelector is WP’s counterpart for iOS’s tableView.
So I started a discussion on Microsoft forums on this bug. Someone from Microsoft confirmed this bug.
I tracked this bug for 9 months. And guess what they never fixed it. They never fixed a critical bug in the most used UI component of mobile apps.
> it finally looked like the UWP Plattform might do the trick. Well nope. The SDK is garbage. Scaling from phone to desktop is hidiously bad and afaik still not solved.
A lot people tell me Xcode is garbage, Eclipse is a nightmare, but these apps keep getting cranked out. The Android / iOS language and platform api's are SNAFU, but people get still get into the IDE and start making, without any promise for a set of conversion-frameworks + XML files that will make the app for All The Things. At the rate an app builder is adding features, the universal-platform paradigm is cognitive overload.
I think a No-XML based approach to app development, similiar to VB6 / VBA, would have been greatly appreciated. If MS gives me a stable API to an email client, a calendar, a shared drive, and a messaging or video chat service, I'd spend the 5 hours to automate a 5 minute inconveneince. A windows phone with a bunch of "lifehacks" apps would tremendously useful to much of the smartphone market, as long as they had the cant-live-without-apps too.
> A lot people tell me Xcode is garbage, Eclipse is a nightmare
Xcode is absolutely sits at the bottom of the IDE rankings, but Eclipse shouldn't even be a concern for Android devs.
Android Studio is a very nice IDE and no Android dev should touch Eclipse ever again. It's a shame it's tied to the Android platform, honestly.
I'd kill to have Android Studio's functionality when developing for iOS. (And no, AppCode doesn't make the cut)
> It's a shame it's tied to the Android platform, honestly.
It's not, it also supports Java, C++/C/ObjC, Go, Python, PHP, JS, and many more. Find the other Jetbrains IDEs at https://www.jetbrains.com/
14 replies →
> Then came windows 8.1 and windows desktop 8 which was universally hated. The whole fullscreen apps debacle was just horrible and all the unnecessary restrictions on store apps for desktop made no one ever consider porting their desktop app to a store app. The whole phone and desktop app in one was a joke aswell since it was (and still is!) horrible implemented. Did I mention they broke compatibility from 8.1 to phone 8? I didn't even bother starting all over again for windows 8.1 i just straight up skipped it.
What was so horrible about it? I almost invested in a surface just off the strength of the UI; I rather liked that they were trying to merge desktop and tablet. Why was the experience so bad?
Windows 8 "metro" UI caused an uproar for many reasons, some of the biggest ones being:
- the start menu covered the whole screen
- applications could only run full screen, even the simplest ones. You literally couldn't have 2 applications on the screen at the same time.
- it was hard to close applications
- it was very difficult to find the shutdown/reset/etc options
- the metro versions of "default" apps looked bad and were vastly inferior to the "old" versions. A lot of system settings ones had this problem, too (not relevant to the average user, but I use a VPN that is impossible to set up to work in the simple "metro" VPN app, but if you find and start the old win7 app which still exists, you can set it up correctly and you can even connect to it from the "metro" VPN app after that)
- a lot of computer games that worked on 7 didn't work on 8 (likely unrelated to metro UI but still a reason for many people not to update)
Some problems were fixed in Windows 8.1. In Windows 10, most of these things are fine (although Win10 gets hate because of its update system and because it installs unwanted apps, but it seems to have much more acceptance overall).
Windows 8 basically offered nothing to the average user except annoyance so people didn't want to update. It had a very nice improvement for developers in the form of Hyper-V, which is the only reason I upgraded, and only after 8.1 was released.
The root problem with Windows 8 UI was that it was clearly not designed with the intention of being a better desktop UI. It was designed with the intention of forcing users to get used to the Windows Phone-style UI on their desktop computer, in hopes that they will then buy Windows Phones out of familiarity. Basically desktop Windows had to "take one for the team". We can see here how much that helped WP.
Personally I remember the biggest pull to windows 8 for me being Games that ran on both 7 and 8/8.1, seemed to perform alot better on 8.1; they didn't advertise that it was a preferred OS or that it was designed for it.
I suspect it was related to streamlining by removing the oldest backward compatibility features, as the only apps that broke were those that ran on windows XP, most frequently they were games that weren't programmed with Vista+ in consideration (often because it didn't exist when originally released).
I specifically remember a bunch of games capping at about 20 FPS on Windows 7 and going 60-100fps on 8 when it was new using my nVidia Quadro SLI setup at the time, and having no luck finding anyone else report this on google (likely because so many people weren't giving 8.x a chance so they didn't notice).
I actually loved 8 and thought that 8.1's gui was a step backwards, the gui was extra easy to use and originally had me going back and forth between windows 7 and 8 when the performance difference eventually won me over completely as my default environment. I still kept 7 installed on another drive for the infrequent use of incompatible apps.
The biggest frustration, to me, is that WPF was basically left on the vine while they pursued this WinRT stuff.
I think the evolutionary path connecting WPF and "this WinRT stuff" is extremely clear and if you've built WPF you can build UWP. UWP .NET/XAML is great to work with if you know WPF, it's truly a successor to WPF in every way. (It'll be even better soon [as in next month] thanks to .NET Standard 2.0.)
That may be so, but WinRT comes with a bunch of limitations, so there isn't really a no-brainer choice for application development, and also, considering how deeply it's associated with the unpopular Windows Store app and Windows phone, who wants to throw in their lot with it? Frankly it hasn't seemed worth investing that much time into any of them and I pretty much just end up reaching for yet another WinForms MVP app. But WinForms practically works against you in the effort to separate UI from behavioral code so that isn't that satisfying either.
7 replies →
The problem with UWP is that it requires Win10. This makes it a no-go for vast majority of developers targeting desktop Windows, given that Win7 is still dominant, and will be for a while to come.
9 replies →
Yeah, and what enterprise have done? It had to switch to legacy crap of JS and HTML(5). Sinofski was an evil moron.
That was probably going to happen anyway because the zero-installation, easy-update, relatively upgrade-safe environment of Web apps is really attractive to businesses.
Good to hear from someone who was valiantly trying to create apps for this platform. I always wondered why developers never flocked to the MS platform since it always seemed wide open with not a lot of competition compared to the IOS and Android platforms.
Thanks for laying bare why it failed so badly.
This reminds me of a Timer app I downloaded when I had a HD8 that didn’t actually alert you when your time was up because of the way the native Alarm SDK was written (something to do with being unable to dispatch an alarm notification at exactly a given time). It made things...difficult.
> at no point had even a single feature that wasn't available better on iOS and Android
Not only is this untrue for years past, it's still untrue (See Continuum + UWP)