Windows 8

Poll: Is Windows 8 more of a development opportunity or problem?

Justin James notes Windows 8 will lead to pain and opportunities for developers. Will the upcoming release lead to more joy or problems for you?

The Windows 8 release is likely to cause some pain for developers and organizations using Windows. It's also possible that Windows 8 will be provide a big opportunity for developers to have access to markets that have been previously been dominated by established players. Just as the uptake in Windows 3.X allowed Word to bull into WordPerfect's market, Metro/WinRT puts everyone on the same playing field with all sorts of products.

I see Windows 8 as both a pain and a joy. What about you?

J.Ja

More about Windows 8 from Justin James

Keep your engineering skills up to date by signing up for TechRepublic's free Software Engineer newsletter, delivered each Tuesday.

About

Justin James is the Lead Architect for Conigent.

31 comments
apotheon
apotheon like.author.displayName like.author.displayName 2 Like

It's an excellent opportunity to migrate to web interfaces for software that runs on a Unix server on the back-end. Of course, this won't work for all applications.

CharlieSpencer
CharlieSpencer

So you think W8 will drive development even further toward web-based apps than it will toward Metro?

Justin James
Justin James

I think that smart developers will put all of the business logic on servers if possible... then build a Web front-end to that so out of the gate they have a universal client, and then add native clients to access the Web services from there, based on market share in target audience. J.Ja

apotheon
apotheon

QUOTE: But as a strategy, you get the Web app out first since it is a universal client, then you roll out "native" apps (including desktops if you feel the need) as time and budget and resources permit. It may not be ideal... but it sure beats building one "native" client and hoping you picked the right one. That works sometimes, but not always. Each situation needs to be evaluated on its own terms. For instance, an application that will be especially atrocious through a browser may actually impose such a drag on user uptake that you won't capture any user base to speak of at all with the web version of the application, and as a result your business model may not survive long enough to get around to building the "native" implementation(s). Meanwhile, an application that gains popularity rapidly on one platform can easily fund porting to other platforms. Even in corporate business climates, where there may be money to blow on sustaining the project despite lackluster business performance throughout the web application deployment, the decision makers might cut the project based on a failure of the concept itself even though it's not the concept that failed, but the specific implementation. In short, it is often the case that a better application is far more important than a more widely usable application, at least at first. This is not always the case, which is why it pays to make an evaluation of your specific case and come to an informed decision on how to proceed. QUOTE: BlackBerry isn't dead by any means, and they could enjoy a resurgence as well. The business decisions at RIM all point to death. For instance, RIM is retreating to the "high ground" -- that is, to serving enterprise and high-end customers, ignoring the more numerous (but more frugal) lower-tier market. Unfortunately, that's an almost invariably losing strategy in technological markets where the basic product or service being offered is not by nature confined to that "high ground", because such niches are typically overtaken by whoever controls the far more diverse and distributed segments of the market, over time. In circumstances like that, the "high ground" is where you go to die, because company executives can achieve short-term success in the numbers, get big bonuses, then leave for greener pastures before the guillotine blade falls on the company. QUOTE: So for folks who need to get their stuff on as many devices as possible (and that's an awful lot of devs), the best and maybe only strategy that fits their time and resource limitations is Web, regardless of what's "better" or "right". There's probably at least half a dozen development toolsets that (to varying degrees of capability) offer the ability to build an application once and deploy across multiple platforms, typically including the major mobile platforms and, often enough, "desktop" systems as well. Their deployment packaging mechanisms provide much more responsive "native" applications than the creeping slowness of web applications on those platforms, with richer UIs that feel more integrated with the platform and are better designed for use on each supported device. One of the big problems with web applications in the browser, after all, is the fact that the interface generally sucks horribly in comparison with "native" applications. In fact, I only go to the browser on my smartphone when I absolutely must (e.g. when what I want is actually a website), because the browser (any browser) is an awful interface for a captive interface application (as opposed to a basic knowledge source -- using the browser to just offer interconnected content). I guess the upshot is that "native" applications are for "doing things", and the browser is more for "reading things". Using the browser for "doing things" just results in a miserable experience, and that's regardless of hardware platform (but exacerbated by a small touchscreen interface). QUOTE: Using Web on a freebie Android phone is probably quite painful. I think hardware is the big problem here, and not the OS. I don't use a "freebie Android phone"; the only real problem with mine, in terms of what we've been discussing, is that it's old (and that the state of the art of smartphone OSes is still pretty damned primitive, anyway). QUOTE: Also, speaking of "native", with Windows 8 clearly going to replace WP7 on the next version of Windows Phone, I am curious if they will bring the C++ compatibility to it that they have in Windows 8. I am also curious if the C++ on Windows 8 runs under the .NET CLR or if it is truly native. If it's running C++ on the CLR, the only difference between that and C# will be the relative difficulty of writing clean code that does exactly what you want in C++.

Justin James
Justin James

I know Web applications on smartphones aren't great... and the speed is part of that. Screen size and UI choices are a big part too. In my mind, the "native" (and you are right that it deserves the scare quotes when a phone is the topic) phone apps are the way to go, backed by the service. But as a strategy, you get the Web app out first since it is a universal client, then you roll out "native" apps (including desktops if you feel the need) as time and budget and resources permit. It may not be ideal... but it sure beats building one "native" client and hoping you picked the right one. For public use, the market has too much churn in it to really predict what client to build for. I remember when Android was around 1.5%, 2% of the market after a year, then the Droid 1 landed and a year later Android was a "must build for" client. iOS is slowly declining in market share but I do not think it will ever be unimportant. With Nokia rolling out WP7 stuff, there is the chance (not sure how strong, but it is obviously a chance) for WP7 to become a true 3rd player. BlackBerry isn't dead by any means, and they could enjoy a resurgence as well. So right there, we are looking at 2 - 4 OS's for domestic use, and if you add in international, you get Symbian and maybe also MeeGo (not sure about its numbers). So for folks who need to get their stuff on as many devices as possible (and that's an awful lot of devs), the best and maybe only strategy that fits their time and resource limitations is Web, regardless of what's "better" or "right". Incidentally, I have had far, far less of a problem with speed since I moved to WP7 from Android. WP7 is a much more responsive OS, even on older/slower hardware than Android. Just about every reviewer out there has remarked on it, so I am sure it's not my imagination. After a year with a more responsive (even to Web stuff) OS, it's easy to forget that not everyone has that experience. Using Web on a freebie Android phone is probably quite painful. Also, speaking of "native", with Windows 8 clearly going to replace WP7 on the next version of Windows Phone, I am curious if they will bring the C++ compatibility to it that they have in Windows 8. I am also curious if the C++ on Windows 8 runs under the .NET CLR or if it is truly native. J.Ja

apotheon
apotheon like.author.displayName 1 Like

Smartphones are actually one of the worst examples you could use to support your point, I think, Justin. Have you tried using a web application on a smartphone lately? It's excruciatingly slow and laggy by comparison with "native" applications on the smartphone -- even when the "native" application deals with networked data access. I use "scare quotes" around "native" because, of course, Java is for some asinine reason probably *THE* dominant "native" application development language for smartphones, and even if it isn't C# is no better for purposes of defining nativity in a way that bears any notable resemblance to what I think of as a native application.

Justin James
Justin James like.author.displayName 1 Like

"For computer games, image editing, and other resource-intensive realtime applications, not so much (still). You're talking about data, and I'm talking about the application itself." Yes, I agree completely. But, as I said, the percentage of applications that fall into this category is falling... not because folks are doing less of it necessarily, but because so many businesses are doing so many data-aware apps. Do I still work on apps that do not depend on a remote data source? Absolutely. Ironically, they tend to be smartphone apps... but the overwhelming majority of the projects I am on... and projects that most business developers are on... need a network connection, unless they plan on a caching/syncing strategy (which is a good idea in general). J.Ja

Sterling chip Camden
Sterling chip Camden like.author.displayName like.author.displayName 2 Like

As for assuming network, we're in a strange place right now -- a lot of apps require network, but network is not always there. Unless and until network bandwidth is as available as the air we breathe, smart applications should be able to operate offline.

apotheon
apotheon

For smartphone applications, alleviating network issues is relatively easy. For computer games, image editing, and other resource-intensive realtime applications, not so much (still). You're talking about data, and I'm talking about the application itself. There's also a big difference between "not miserable" and "snappy and responsive". In many software niches, "snappy and responsive" will kick the crap out of "not miserable". It's true that the percentage of applications for which this is the case is shrinking, just as it's true that the percentage of cars on the road that used fossil fuels was shrinking in the 1990s, but that didn't mean that in 1996 it was reasonable to expect the majority of internal combustion engine automobiles to be replaced by electric cars over the next three or four years. I use craptons of applications that are useful without a network connection. So does my SigO. So do her mother and father, in relative terms. So do my parents. So do at least two out of the other three people in my weekly Pathfinder RPG sessions. I think part of the reason people don't keep local resources for things like software development as much as they used to is the fact that they have come to just accept that if they're away from a network connection they can't do any work. I think that leads to assumptions that it's okay to not offer such resources in a manner that's convenient for local storage and access, which then perpetuates the cycle. Meanwhile, the Unix tradition offers heaps of manpages on system calls, and I have both hardcopies and digital files of some good C programming books, and the only thing that's really missing is my access to realtime communication with people who know C better than me (credit where it's due: thanks for being one of those people, Sterling). Of course, C is a special case, not only because it's so well supported on Unixy systems, but also because learning oriented information about it is so atrocious on the Internet in comparison with many other languages despite its venerable status. I like having the Internet for research when I write, whether it's in Ruby, C, English, or some other language, but I often don't need it. I really try to ensure that is the case for myself, because I like to move around and work in a variety of locations -- coffee shops, for instance -- and because I do not like to feel like my productivity is destroyed any time there's a network hiccup or I'm traveling in an area where free wifi access is not reasonable to expect at all times. You don't really have to just accept you can't get anything done when you don't have network connectivity. You probably do so out of a mild case of Stockholm syndrome, really. I think the majority of these "business users" could easily get by without connectivity from time to time if they just planned ahead a little. I also don't think that talking about how much people rely on the net effectively disputes the simple fact that having the actual program logic split between client and server would make whole classes of important software people use regularly suddenly useless for most users.

Justin James
Justin James

I used to feel the same way that you do. After a few years of using a smartphone, and having a lot of times in high latency or poor connectivity situations, low bandwidth, etc. etc. etc., what I've seen is that smart application design alleviates nearly all of it. The key is to send as little data as needed over the wire in response to user input, and to try to pre-load data when possible, in moderation. Add in local caching/syncing for the "no connectivity" situations (which are increasingly rare, between expanding cell networks and WiFi availability), and what I've seen is that with the exception of "mission critical" applications, it is quite surprisingly just how many applications can have a dependency on a server without it being miserable in those scenarios. The percentage of applications which are useful without a network connection is shrinking, because more and more apps have a dependency on a database anyways. I can tell you that for me, the only applications I use on a regular basis that are useful without a network connection are Office and Visual Studio... and even they are not too useful without connectivity, because of the research that needs to be done when I'm using them. It is rare for me to do anything with Word where I do not need to look anything up from outside my local system, and the same is true for development work. All of the reference materials, not just Microsoft's, but anything I'm working with, integrating with, etc., it's all external anyways. I think that if you look at a typical business user, they are totally dead in the water without connectivity. There are a few mobile workers out there who can survive without always-on, but they are disappearing too. J.Ja

apotheon
apotheon

"Smart developers" is a vanishingly small minority, and there are a lot of applications in the world that don't have "business logic" per se anyway. There's also the fact that though, in theory, hiding the back-end behind a network connection sounds great in a lot of cases, the reality makes it a bad choice a lot of the time when little issues like connection latency, bandwidth, or just plain ol' connectivity fails to keep up with user needs. I think a more realistic answer is "Uh -- maybe?"

apotheon
apotheon

Maybe. It's an opportunity, but opportunities are not always seized.

Justin James
Justin James like.author.displayName 1 Like

With all of the churn in front-end and client-side technology, Windows was stable and you could say, "oh, but I don't need that architecture, I do Windows desktop apps". Well, now those folks are looking at the same churn, and now that Windows is in, "shiny and new" mode on that end, you can be sure that the next version (service pack 1 or 2? Windows 9?) will bring additional changes as they refine. If someone *can* move non-trivial amounts of logic to a server, and doesn't, and there are no business reasons for it, I'd be tempted to label them as negligent. And with the consistently wild swings in .NET server-side functionality, I am starting to see the *NIX technologies as a "safe haven". Innovation is great and innovation is important, but Microsoft lately has been innovating on their own stack in ways that are not only not backwards compatible, but do not logically derive from each other. For example, the new "Web API" framework is not the logical extension of WCF, it is the logical extension of ASP.NET MVC... it makes sense, except that WCF is what people were using for the job previously, not MVC. It's like if someone gave you a "Phillips head screw turning attachment" for your hammer instead of giving you a Phillips head screwdriver to complement your existing slotted screwdriver... J.Ja

apotheon
apotheon like.author.displayName like.author.displayName 2 Like

It's not "innovation" if it doesn't give us real benefits; then, it's just "change". Part of the problem, of course, is that Microsoft wants to integrate everything, which means you don't get to choose your technologies. Microsoft throws something out to make room for something new, and a bunch of people either change the way they develop software dramatically (often for no real benefit) or they abandon the MS Windows platform as a target (perhaps by targeting the browser; perhaps by targeting something else entirely).

apotheon
apotheon like.author.displayName 1 Like

I'll buy that for a dollar.

Justin James
Justin James like.author.displayName like.author.displayName 2 Like

What I've been seeing in the .NET world, is that from conception until about 3 years ago, the *entire* .NET ecosystem was driven by Microsoft's perception of what "enterprises" needed. That meant big, clunky systems, all designed to scale out and expand across the universe, but no way of doing "get in and get out" work. In the last few years, along with the shift to open source, they've been making stuff more lightweight, and easier to get up and running without reading through 800 pages of manuals and such. Web API vs. WCF is a good example. Even though Web API basically means abandoning the investment in WCF, it only takes a few minutes to learn enough Web API to get up and running while WCF takes a while to really get bootstrapped. So yeah, you are throwing out a big investment (or calling it "legacy" and putting it into maintenance) but the replacement is a LOT easier to learn than what it's replacing. I didn't really mean to call it "innovation" in the sense that it's actually innovative, but I meant it in the sense that Microsoft sees what they are doing as innovation. I see it as, "looking at what everyone else is doing, trying to shoehorn it into the .NET ecosystem, and then kind of supporting it for a few years"... J.Ja

Sterling chip Camden
Sterling chip Camden like.author.displayName like.author.displayName 2 Like

Some of my clients have just mastered WinForms or WPF. They were hoping that climbing that learning curve would give them tools they could use for several years. Now they're wondering how many generations behind are they going to get before they take the next step. Something a little more consistent on the UI, backed by their solid 30-year-old app on the back-end might be just the ticket.

tootall3
tootall3

I have worked with computers for 24 years and I can not even remember how many OS's I've tried. Windows / DOS has been the most consistent development environment of all. We have applications inside and outside the firewall and they come to work every day! We will modify the way things are done and keep things working.

gak
gak

I used to believe that Windows Phone has a fixed set of requirements and that fights platform fragmentation. Now we have dirt cheep memory and 256M entry level devices. Whenever Microsoft is involved, there are no 100% development opportunities.

Regulus
Regulus like.author.displayName like.author.displayName 2 Like

Demonstrating once again that the Ferengi domination of Microsoft benefits all mankind!

Skruis
Skruis

Windows 8 is still Windows and it still supports all of the legacy applications so the existing market for Windows development is still there but now there's more of a consumption market too with the Windows Store...that's something that Windows user's have traditionaly relied on websites to provide and never really downloaded and installed smaller purpose built applications like you see on Windows Phone, iOS or Android. Of course, with any new opportunity there are learning curves but pretty much anyone familiar with .net, silverlight or mobile development in general will be able to create new apps with relative ease. Overall, it's an opportunity for Windows development and as developers begin to layout their apps, they simply have to choose which environment fits their application best, the desktop or metro.

CharlieSpencer
CharlieSpencer like.author.displayName 1 Like

"Of course, with any new opportunity there are learning curves but pretty much anyone familiar with .net, silverlight or mobile development in general will be able to create new apps with relative ease." I wonder what percentage of Windows developers have concentrated on developing for desktops and laptops, and previously never had to consider the specialized needs of a mobile app.

Sterling chip Camden
Sterling chip Camden like.author.displayName 1 Like

When software vendors are demoing against each other, it could be important to have the metro interface, even if that isn't the best interface for day-to-day usage. I said "could" because I'm not certain that metro will catch on -- it could almost as easily backfire and become a mark of shame.

Skruis
Skruis

Most desktops and laptop users in business will not be using Metro primarily. Most of the metro use will be home or mobile users so the expectation that a "metro" app is available I think will be a bonus but not expected. In addition to that, a desktop app is expected to be powerful. That's not to say that a metro app can't be powerful but the expectations are different and I expect that most business metro applications will be released in addition and as a supplement to the primary desktop applications. Even still, with your comment, you're showing that Metro offers additional opportunity's and that the only drawback is the additional effort one would have to put into developing the additional metro application if it would be required.

apotheon
apotheon

I only just now realized what bothered me about your comment: your use of the word "logic" for both cases. Maybe "(il)logic" would have made for a more comfortably applicable a statement in this context.

Sterling chip Camden
Sterling chip Camden like.author.displayName 1 Like

Those will have it a bit easier who have already properly separated UI from business logic -- both of them.

Justin James
Justin James like.author.displayName 1 Like

... depending on architecture. Remember, anything running under Metro has to use the WinRT API instead of the Win32 API or the full .NET Framework, which may mean a MAJOR rewrite of many apps, if not a "back to the drawing board" approach. J.Ja

Sterling chip Camden
Sterling chip Camden like.author.displayName 1 Like

If I could snap my fingers and add a Metro interface to an existing app, then of course I would do it. But I have to devote time and resources to doing that instead of working on something else -- so I have to be really sure that what I'll get in return make it worthwhile.

mattohare
mattohare

And development tools too? The consumer-oriented platform may be nice. How will it be for the business-oriented?

Sterling chip Camden
Sterling chip Camden like.author.displayName like.author.displayName 2 Like

It will undoubtedly lead to more business, which is good. However, I may also get to take some undeserved blame.