Monday, October 07, 2013

The short answer to the question of whether the Microsoft .NET Framework (and its related tools and technologies) has a future is of course, don’t be silly.

The reality is that successful technologies take years, usually decades, perhaps longer, to fade away. Most people would be shocked at how much of the world runs on RPG, COBOL, FORTRAN, C, and C++ – all languages that became obsolete decades ago. Software written in these languages runs on mainframes and minicomputers (also obsolete decades ago) as well as more modern hardware in some cases. Of course in reality mainframes and minicomputers are still manufactured, so perhaps they aren’t technically “obsolete” except in our minds.

It is reasonable to assume that .NET (and Java) along with their primary platforms (Windows and Unix/Linux) will follow those older languages into the misty twilight of time. And that such a thing will take years, most likely decades, perhaps longer, to occur.

I think it is critical to understand that point, because if you’ve built and bet your career on .NET or Java it is good to know that nothing is really forcing you to give them up. Although your chosen technology is already losing (or has lost) its trendiness, and will eventually become extremely obscure, it is a pretty safe bet that you’ll always have work. Even better, odds are good that your skills will become sharply more valuable over time as knowledgeable .NET/Java resources become more rare.

Alternately you may choose some trendier alternative; the only seemingly viable candidate being JavaScript or its spawn such as CoffeeScript or TypeScript.

How will this fading of .NET/Java technology relevance occur?

To answer I’ll subdivide the software world into two parts: client devices and servers.

Client Devices

On client devices (PCs, laptops, ultrabooks, tablets, phones, etc.) I feel the need to further split into two parts: consumer apps and business apps. Yes, I know that people seem to think there’s no difference, but as I’ve said before, I think there’s an important economic distinction between the consumer and business apps.

Consumer Apps

Consumer apps are driven by a set of economic factors that make it well worth the investment to build native apps for every platform. In this environment Objective C, Java, and .NET (along with C++) all have a bright future.

Perhaps JavaScript will become a contender here, but that presupposes Apple, Google, and Microsoft work to make that possible by undermining their existing proprietary development tooling. There are some strong economic reasons why none of them would want every app on the planet to run equally on every vendor’s device, so this seems unlikely. That said, for reasons I can’t fathom, Microsoft is doing their best to make sure JavaScript really does work well on Windows 8, so perhaps Apple will follow suit and encourage their developers to abandon Objective C in favor of cross-platform JavaScript?

Google already loves the idea of JavaScript and would clearly prefer if we all just wrote every app in JavaScript for Chrome on Android, iOS, and Windows. The only question in my mind is how they will work advertising into all of our Chrome apps in the future?

My interest doesn’t really lie in the consumer app space, as I think relatively few people are going to get rich building casual games, fart apps, metro transit mapping apps, and so forth. From a commercial perspective there is some money to be made building apps for corporations, such as banking apps, brochure-ware apps, travel apps, etc. But even that is a niche market compared to the business app space.

Business Apps

Business apps (apps for use by a business’s employees) are driven by an important economic factor called a natural monopoly. Businesses want software that is built and maintained as cheaply as possible. Rewriting the same app several times to get a “native experience” on numerous operating systems has never been viable, and I can’t see where IT budgets will be expanding to enable such waste in the near future. In other words, businesses are almost certain to continue to build business apps in a single language for a single client platform. For a couple decades this has been Windows, with only a small number of language/tool combinations considered viable (VB, PowerBuilder, .NET).

But today businesses are confronted with pressure to write apps that work on the iPad as well as Windows (and outside the US on Android). The only two options available are to write the app 3+ times or to find some cross-platform technology, such as JavaScript.

The natural monopoly concept creates some tension here.

A business might insist on supporting just one platform, probably Windows. A couple years ago I thought Microsoft’s Windows 8 strategy was to make it realistic for businesses to choose Windows and .NET as this single platform. Sadly they’ve created a side loading cost model that basically blocks WinRT business app deployment, making Windows far less interesting in terms of being the single platform. The only thing Windows has going for it is Microsoft’s legacy monopoly, which will carry them for years, but (barring business-friendly changes to WinRT licensing) is doomed to erode.

You can probably tell I think Microsoft has royally screwed themselves over with their current Windows 8 business app “strategy”. I’ve been one of the loudest and most consistent voices on this issue for the past couple years, but Microsoft appears oblivious to the problem and has shown no signs of even recognizing the problem much less looking at solutions. I’ve come to the conclusion that they expect .NET on the client to fade away, and for Windows to compete as just one of several platforms that can run JavaScript apps. In other words I’ve come to the conclusion that Microsoft is willingly giving up on any sort of technology lock-in or differentiation of the Windows client in terms of business app development. They want us to write cross-platform JavaScript apps, and they simply hope that businesses and end users will choose Windows for other reasons than because the apps only run on Windows.

Perhaps a business would settle on iOS or Android as the “one client platform”, but that poses serious challenges given that virtually all businesses have massive legacies of Windows apps. The only realistic way to switch clients to iOS or Android is to run all those Windows apps on Citrix servers (or equivalent), and to ensure that the client devices have keyboards and mice so users can actually interact with the legacy Windows apps for the next several years/decades. Android probably has a leg up here because most Android devices have USB ports for keyboards/mice, but really neither iOS nor Android have the peripheral or multi-monitor support necessary to truly replace legacy Windows (Win32/.NET).

This leaves us with the idea that businesses won’t choose one platform in the traditional sense, but rather will choose a more abstract runtime: namely JavaScript running in a browser DOM (real or simulated). Today this is pretty hard because of differences between browsers and between browsers on different platforms. JavaScript libraries such as jquery, angular, and many others seek to abstract away those differences, but there’s no doubt that building a JavaScript client app costs more today than building the same app in .NET or some other more mature/consistent technology.

At the same time, only JavaScript really offers any hope of building a client app codebase that can run on iOS, Android, and Windows tablets, ultrabooks. laptops, and PCs. So though it may be more expensive than just writing a .NET app for Windows, JavaScript might be cheaper than rewriting the app 3+ times for iOS, Android, and Windows. And there’s always hope that JavaScript (or its offspring like CoffeScript or TypeScript) will rapidly mature enough to make this “platform” more cost-effective.

I look at JavaScript today much like Visual Basic 3 in the early 1990s (or C in the late 1980s). It is typeless and primitive compared to modern C#/VB or Java. To overcome this it relies on tons of external components (VB had its component model, JavaScript has myriad open source libraries). These third party components change rapidly and with little or no cross-coordination, meaning that you are lucky if you have a stable development target for a few weeks (as opposed to .NET or Java where you could have a stable target for months or years). As a result a lot of the development practices we’ve learned and mastered over the past 20 years are no longer relevant, and new practices must be devised, refined, and taught.

Also we must recognize that JavaScript apps never go into a pure maintenance mode. Browsers and underlying operating systems, along with the numerous open source libraries you must use, are constantly versioning and changing, so you can never stop updating your app codebase to accommodate this changing landscape. If you do stop, you’ll end up where so many businesses are today: trapped on IE6 and Windows XP because nothing they wrote for IE6 can run on any modern browser. We know that is a doomed strategy, so we therefore know that JavaScript apps will require continual rewrites to keep them functional over time.

What I’m getting at here is that businesses have an extremely ugly choice on the client:

  1. Rewrite and maintain every app 3+ times to be native on Windows, iOS, and Android
  2. Absorb the up-front and ongoing cost of building and maintaining apps in cross-platform JavaScript
  3. Select one platform (almost certainly Windows) on which to write all client apps, and require users to use that platform

I think I’ve listed those in order from most to least expensive, though numbers 1 and 2 could be reversed in some cases. I think in all cases it is far cheaper for businesses to do what Delta recently did and just issue Windows devices to their employees, thus allowing them to write, maintain, and support apps on a single, predictable platform.

The thing is that businesses are run by humans, and humans are often highly irrational. People are foolishly enamored of BYOD (bring your own device), which might feel good, but is ultimately expensive and highly problematic. And executives are often the drivers for alternate platforms because they like their cool new gadgets; oblivious to the reality that supporting their latest tech fad (iPad, Android, whatever) might cost the business many thousands (often easily 100’s of thousands) of dollars each year in software development, maintenance, and support costs.

Of course I work for a software development consulting company. Like all such companies we effectively charge by the hour. So from my perspective I’d really prefer if everyone did decide to write all their apps 3+ times, or write them in cross-platform JavaScript. That’s just more work for us, even if objectively it is pretty damn stupid from the perspective of our customers’ software budgets.

Server Software

Servers are a bit simpler than client devices.

The primary technologies used today on servers are .NET and Java. Though as I pointed out at the start of this post, you shouldn’t discount the amount of COBOL, RPG, FORTRAN, and other legacy languages/tools/platforms that make our world function.

Although JavaScript has a nescient presence on the server via tools like node.js, I don’t think any responsible business decision maker is looking at moving away from existing server platform tools in the foreseeable future.

In other words the current 60/40 split (or 50/50, depending on whose numbers you believe) between .NET and Java on the server isn’t likely to change any time soon.

Personally I am loath to give up the idea of a common technology platform between client and server – something provided by VB in the 1990s and .NET over the past 13 years. So if we really do end up writing all our client software in JavaScript I’ll be a strong advocate for things like node.js on the server.

In the mid-1990s it was pretty common to write “middle tier” software in C++ and “client tier” software in PowerBuilder or VB. Having observed such projects and the attendant complexity of having a middle tier dev team who theoretically coordinated with the client dev team, I can say that this isn’t a desirable model. I can’t support the idea of a middle tier in .NET and a client tier in JavaScript, because I can’t see how team dynamics and inter-personal communication capabilities have changed enough (or at all) over the past 15 years such that we should expect any better outcome now than we got back then.

So from a server software perspective I think .NET and Java have a perfectly fine future, because the server-side JavaScript concept is even less mature than client-side JavaScript.

At the same time, I really hope that (if we move to JavaScript on the client) JavaScript matures rapidly on both client and server, eliminating the need for .NET/Java on the server as well as the client.

Conclusion

In the early 1990s I was a VB expert. In fact, I was one of the world’s leading VB champions through the 1990s. So if we are going to select JavaScript as the “one technology to rule them all” I guess I’m OK with going back to something like that world.

I’m not totally OK with it, because I rather enjoy modern C#/VB and .NET. And yes, I could easily ride out the rest of my career on .NET, there’s no doubt in my mind. But I have never in my career been a legacy platform developer, and I can’t imagine working in a stagnant and increasingly irrelevant technology, so I doubt I’ll make that choice – stable though it might be.

Fwiw, I do still think Microsoft has a chance to make Windows 8, WinRT, and .NET a viable business app development target into the future. But their time is running out, and as I said earlier they seem oblivious to the danger (or are perhaps embracing the loss of Windows as the primary app dev target on the client). I would like to see Microsoft wake up and get a clue, resulting in WinRT and .NET being a viable future for business app dev.

Failing that however, we all need to start putting increasing pressure on vendors (commercial and open source) to mature JavaScript, its related libraries and tools, and its offspring such as TypeScript – on both client and server. The status of JavaScript today is too primitive to replace .NET/Java, and if we’re to go down this road a lot of money and effort needs to be expended rapidly to create a stable, predictable, and productive enterprise-level JavaScript app dev platform.

Monday, October 07, 2013 9:24:20 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [39]  | 
 Thursday, August 29, 2013

As you can tell from my post volume, I’ve had a few weeks of enforced downtime during which time a lot of thoughts have been percolating in my mind just waiting to escape :)

There’s an ongoing discussion inside Magenic as to whether there is any meaningful difference between consumer apps and business apps.

This is kind of a big deal, because we generally build business apps for enterprises, that’s our bread and butter as a custom app dev consulting company. Many of us (myself included) look at most of the apps on phones and tablets as being “toy apps”, at least compared to the high levels of complexity around data entry, business rules, and data management/manipulation that you find in enterprise business applications.

For example, I have yet to see an order entry screen with a few hundred data entry fields implemented on an iPhone or even iPad. Not to say that such a thing might not exist, but if such a thing does exist it is a rarity. But in the world of business app dev such screens exist in nearly every application, and typically the user has 1-2 other monitors displaying information relevant to the data entry screen.

Don’t get me wrong, I’m not saying mobile devices don’t have a role in enterprise app dev, because I think they do. Their role probably isn’t to replace the multiple 30” monitors with keyboard/mouse being used by the employees doing the work. But they surely can support a lot of peripheral tasks such as manager approvals, executive reviews, business intelligence alerts, etc. In fact they can almost certainly fill those roles better than a bigger computer that exists only in a fixed location.

But still, the technologies and tools used to build a consumer app and a business app for a mobile device are the same. So you can surely imagine (with a little suspension of disbelief) how a complex manufacturing scheduling app could be adapted to run on an iPad. The user might have to go through 20 screens to get to all the fields, but there’s no technical reason this couldn’t be done.

So then is there any meaningful difference between consumer and business apps?

I think yes. And I think the difference is economics, not technology.

(maybe I’ve spent too many years working in IT building business apps and being told I’m a cost center – but bear with me)

If I’m writing a consumer app, that app is directly or indirectly making me money. It generates revenue, and of course creating it has a cost. For every type of device (iOS, Android, Win8, etc.) there’s a cost to build software, and potential revenue based on reaching the users of those devices. There’s also direct incentive to make each device experience “feel native” because you are trying to delight the users of each device, thus increasing your revenue. As a result consumer apps tend to be native (or they suck, like the Delta app), but the creators of the apps accept the cost of development because that’s the means through which they achieve increased revenue.

If I’m writing a business app (like something to manage my inventory or schedule my manufacturing workload) the cost to build software for each type of device continues to exist, but there’s zero increased revenue (well, zero revenue period). There’s no interest in delighting users, we just need them to be productive, and if they can’t be productive that just increases cost. So it is all cost, cost, cost. As a result, if I can figure out a way to use a common codebase, even if the result doesn’t “feel native” on any platform, I still win because my employees can be productive and I’ve radically reduced my costs vs writing and maintaining the app multiple times.

Technically I’ll use the same tools and technologies and skills regardless of consumer or business. But economically there’s a massive difference between delighting end users to increase revenue (direct or indirect), and minimizing software development/maintenance costs as much as possible while ensuring employees are productive.

From a tactical perspective, as a business developer it is virtually impossible to envision writing native apps unless you can mandate the use of only one type of device. Presumably that’s no longer possible in the new world of BYOD, so you’ve got to look at which technologies and tools allow you to build a common code base. The list is fairly short:

  • JavaScript (straight up or via various wrapper tools like PhoneGap)
  • Microsoft .NET + Xamarin

(yes, I know C++ might also make the list, but JavaScript sets our industry back at least 10 years, and C++ would set us back more than 20 years, so really????)

I’m assuming we’ll be writing lots of server-side code, and some reasonably interactive client code to support iPad, Android tablets, and Windows 8 tablets/ultrabooks/laptops/desktops. You might also bring in phones for even more narrow user scenarios, so iPhone, Android phones, and Windows Phone too.

Microsoft .NET gets you the entire spectrum of Windows from phone to tablet to ultrabook/laptop/desktop, as well as the server. So that’s pretty nice, but leaves out iPad/iPhone and Android. Except that you can use the Xamarin tools to build iOS and Android apps with .NET as well! So in reality you can build reusable C# code that spans all the relevant platforms and devices.

As an aside, CSLA .NET can help you build reusable code across .NET and Xamarin on Android. Sadly some of Apple’s legal limitations for iOS block some key C# features used by CSLA so it doesn’t work on the iPad or iPhone :(

The other option is JavaScript or related wrapper/abstraction technologies like PhoneGap, TypeScript, etc. In this case you’ll need some host application on your device to run the JavaScript code, probably a browser (though Win8 can host directly). And you’ll want to standardize on a host that is as common as possible across all devices, which probably means Chrome on the clients, and node.js on the servers. Your client-side code still might need some tweaking to deal with runtime variations across device types, but as long as you can stick with a single JavaScript host like Chrome you are probably in reasonably good shape.

Remember, we’re talking business apps here – businesses have standardized on Windows for 20 years, so the idea that a business might mandate the use of Chrome across all devices isn’t remotely far-fetched imo.

Sadly, as much as I truly love .NET and view it as the best software development platform mankind has yet invented, I strongly suspect that we’ll all end up programming in JavaScript – or some decent abstraction of it like TypeScript. As a result, I’m increasingly convinced that platforms like .NET, Java, and Objective C will be relegated to writing “toy” consumer apps, and/or to pure server-side legacy code alongside the old COBOL, RPG, and FORTRAN code that still runs an amazing number of companies in the world.

Thursday, August 29, 2013 3:20:39 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [8]  | 
 Thursday, April 04, 2013

In 1991 I was a DEC VAX programmer. A very happy one, because OpenVMS was a wonderful operating system and I knew it inside and out. The only problem was that the “clients” were dumb VT terminals, and it was terribly easy to become resource constrained by having all the CPU, memory, and IO processing in a central location.

This was the time when Windows NT came along (this new OS created by the same person who created OpenVMS btw) and demonstrated that PCs were more than toys – that they could be considered real computers. (yes, this is my editorial view Smile )

From that time forward my personal interest in software has been expressed entirely via distributed computing. Sure, I’ve built some server-only and some client-only software over the past 22 years, but that was just to pay the bills. What is interesting is building software systems where various parts of the system run on different computers, working together toward a common goal. That’s fun!!

This type of software system implies a smart client. I suppose a smart client isn’t strictly necessary, but it is surely ideal. Because most software interacts with humans at some point, a smart client is ideal because that’s how you provide the human with the best possible experience. Obviously you can use a VT terminal or a basic HTML browser experience to provide this human interface, but that’s not nearly as rich or powerful as a smart client experience.

For the past couple decades the default and dominant smart client experience has been expressed through Windows. With smart client software written primarily in VB, PowerBuilder, and .NET (C#/VB).

The thing is, I am entirely convinced that our industry is at a major inflection point. At least as big as the one in the mid-1990’s when we shifted from mainframe/minicomputer to PC, and when n-tier became viable, and when the infant web became mainstream.

Prior to the mid-1990’s computing was chaos. There were many types of mainframe and minicomputer, and none were compatible with each other. Even the various flavors of Unix weren’t really compatible with each other… Software developers tended to specialize in a platform, and it took non-trivial effort to retool to another platform – at least if you wanted to be really good.

Over the past couple decades we’ve been spoiled by having essentially one platform: Windows. Regardless of whether you use VB, PowerBuilder, .NET, or Java, almost everyone knows Windows and how to build software for this one nearly-universal platform.

Now we’ve chosen to return to chaos. Windows is still sort of dominant, but it shares a lot of mindshare with iOS, OS X, Android, and ChromeOS. We appear to be heading rapidly into an environment more like the late 1980’s. An environment composed of numerous incompatible platforms, all of which are viable, none of which are truly dominant.

There is one difference this time though: JavaScript.

Please don’t get me wrong, I’m not a rah-rah supporter of js. I am extremely skeptical of cross-platform technologies, having seen countless such technologies crash and burn over the past 25+ years.

But there’s an economic factor that comes to bear as well as technical factors. Unlike in the late 1980’s when computing was important but not critical to the world at large, today computing is critical to the world at large. Individuals and organizations can not function at the levels of productivity we’re used to without computing and automation.

In other words, in the late 1980’s we could afford to be highly inefficient. We could afford to have a fragmented developer space, split by myriad incompatible platforms.

Today the cost of such inefficiency is much higher. I suspect it is too high to be acceptable. Think about your organization. Can you afford to build every client app 3-6 times? Will your board of directors or company owner accept that kind of increase in the IT budget?

Or can you afford to pick just one platform (iOS, Windows, whatever) and tell all your employees and partners that you only work with that one type of device/OS?

(btw, that’s what we’ve done for the past 20 years – we just tell everyone it is Windows or nothing, and that’s been working well – so such a move isn’t out of the question)

Let’s assume your organization can’t afford a massive increase in its IT budget to hire the dev/support staff to build and maintain every app 3-6 times. And let’s assume we collectively decide to embrace every random device/OS that comes along (BYOD). What then?

I suggest there are two options:

  1. Return to a terminal-based model where the client device is a dumb as possible, probably using basic HTML – to which I say BORING! (and awful!)
  2. Find a common technology for building smart client apps that works reasonably well on most device/OS combinations

Personally I am entirely uninterested in option 1. As I said, I spent the early part of my career in the minicomputer-terminal world, so I’ve been there and done that. Boring.

The only technology that looks even remotely capable of supporting option 2 is JavaScript.

Is that a silver bullet? Is it painless? Clearly not. Even if you ignore all the bad bits of js and stick with JavaScript: The Good Parts it is still pretty messy.

However, VB 1, 2, and 3 were also pretty immature and messy. But a lot of us stuck with those products, pushing for (and getting) improvements that ultimately made VB6 the most popular development tool of its time – for apps small and big (enterprise).

So sure, js is (by modern standards) immature and messy. But if the broader business development community sees it as the only viable technology going forward that’ll bring a lot of attention and money into the js world. That attention and money will drive maturity, probably quite rapidly.

OK, so probably not maturity of js itself, because it is controlled by a standards body and so it changes at a glacial pace.

But maturity of tooling (look at the amazing stuff Microsoft is doing in VS for js tooling, as well as TypeScript), and libraries, and standards. That’ll be the avenue by which js becomes viable for smart client development.

If it isn’t clear btw, I am increasingly convinced that (like it or not) this is where we’re headed. We have a few more years of Windows as the dominant enterprise client OS, but given what Microsoft is doing with Windows 8 it is really hard to see how Windows will remain dominant in that space. Not that any one single device/OS will displace Windows – but rather that chaos will displace Windows.

As a result, barring someone inventing a better cross-platform technology (and I’d love to see that happen!!), js is about to get hit by a lot of professional business developers who’ll demand more maturity, stability, and productivity than exists today.

This is going to be a fun ride!

Thursday, April 04, 2013 8:44:57 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [10]  |