3 inevitable things; a glimpse into the future of our industry

In our industry, the future is uncertain. As technology gets more complex, employment seems assured. But as technology gets more complex, perhaps a unified theory of technology will emerge, wiping away the need for keyboard monkeys pounding out apps. It’s just uncertain. But in the short-term, there are three inevitable things. And, here they are.

1. More with less hardware

This one sort of blows the minds of normal developers. The new direction of apps is to remove functionality, in part because the new direction of apps is to run on weaker hardware like the ARM processor. These processors give us more portability and battery life. But they suck.

By and by, the development community will finally get it through their heads that apps on low-end hardware can perform (even out-perform) the same functions as apps on high-end hardware. That means CAD apps, Photoshop, and high-end math processing can be run on your watch the same as anywhere. No kidding.

How do we accomplish this computer science marvel? Offloading work to the cloud is how. Most developers remain stuck in the world where they have to write efficient client-side code in order to have a productive app. But apps that offload to the cloud can do more, faster, and everywhere. The ubiquity and dropping cost of cloud services like Azure have turned the tide. This isn’t a toy for the 1% anymore.

Is this just a game of semantics? No. Consider Star Trek. When the Away Team needs to forecast the decay rate of the system’s star, calculating its impact on local vegetation – their hand-held PADD gives them the answer. But it’s only because the PADD is interfacing with the Enterprise; she’s doing the work.

Your app can do the same thing. The user asks your app to calculate the near-impossible. Then, they close your app while it is working! Who cares. Your app is processing in the cloud. The app is just a presenter. More and more apps are already in this paradigm. This is an inevitable shift in developer thinking. You can write an app that splits the atom, and runs efficiently on a phone or in a car! The cloud’s doing all the work.

2. Less diversity

Systems like Amazon’s Kindle, Google’s Android, Microsoft’s Windows, and Apple’s IOS provide rich user experiences spanning a portfolio of properties. Users love it. But these platforms assume one thing – you go “all in”. The less users diversify their technology the more happiness platforms can give them. All your music, all your movies, all your apps, all your contacts, all your email, all your Skype calls, everything in one place means more possibilities.

Note: you are likely thinking about privacy right now. Allow me to share a secret with you. Typical consumers, they aren’t thinking about privacy. So you can get it out of your head that somehow “privacy” detracts users from buying the latest toy or trying the latest service. It doesn’t. You can “scroogle” users in a new way every morning, but they will forgive you if your computer email syncs with their phone! It’s a moral high ground that simply doesn’t matter.

Remember when Apple’s ITunes meant your music could follow you anywhere? It wasn’t revolutionary, because it wasn’t new. But it was transformative because it drove users to change their thinking from silos of technology to systems spanning devices and people.

As Apple, Microsoft, and Google release better phones, watches, and televisions. As Apple, Microsoft, and Google beef up the usefulness of their online systems, backend storage, and social tooling. As Apple, Microsoft, and Google continue to give free services and incentives to anyone holding an account with them. As things continue, users will be pushed to commit.

Having your fingers in everything is sort of a developer’s dream. But when it comes to end users like my mom, she’s not interested in 3 or 4 accounts. She’s not interested in different looking, different feeling, different acting systems and devices. She wants consistency. She wants the illusion that the service knows her. And, she wants to believe that she will get more back the more she invests. All users want that. Heck, I want that.

As a result, things are going to change. You might have a Kindle, a Surface, an IPad, an Android Phone, an Apple TV, an Xbox, a Samsung watch, and plan on getting Google Glasses. But the problem is fundamental. They are all cool in their own right, but introduce a headache of non-interoperability.

Soon, (How soon? I do not know. Maybe it’s already happening) users are going to shun technology on platforms differing from where they have already invested in their profile. Just like ITunes used to lock users on the Apple platform (to users eternal suffering), it is becoming the integration of services and the resulting compound value that will lock users in the future. As technology gets more complicated, users will gravitate to this in an unspoken desire for simplification.

3. Code generation

Many developer activities are repetitive and redundant. Most developers can smell an opportunity for reusable code. But the inevitable shift in how programmers develop will be the rise of code generation to create more and more and more of the apps they are writing. From coding to code-figuring.

Code generation is nothing new. You provide the framework a well-structured set of instructions and it spits out volumes of repetitive, tested, reliable code. I step up to the plate to code something. It takes 100,000 lines of code to complete my task. But, I actually only write about 5,000 lines. Code generation does most of the work for me. Game over.

This is different than systems that code for you. When Captain Picard instructed the Enterprise computer to generate a pattern of evasive maneuvers to foil an enemy’s attack, the Enterprise computer obeys him. It translates English concepts into software subroutines. Code from nothing.

This type of code generation is different. It might also be inevitable. But the timeline for this must follow the also-inevitable accomplishment of machine thinking with the capability of understanding language, not just simple speech recognition like we have today. This is distant-future stuff.

The code generation I mean here, that is inevitable in the near-term, is the application of patterns and templates to accomplish repetitive and recurring tasks by using systems that take in human-configured data and spit out machine-ready code. Developers won’t be required to use it. But, developers that do will out-perform developers that don’t. Better, more consistent code is the result.

There are two wonderful examples of this.

First, T4 in Visual Studio. Many developers have already used the T4 templates in Visual Studio to point to their database, to their Entity Framework models, or to XML files; this generates clean, reliable code – saving them typing errors and the risk of straying from a consistent pattern.

In Visual Studio 2013, there is great feature to debug T4 templates. The ability to debug has never been easier. Just right-click your TT file and select “Debug T4 Template” to step into your script – it is right below “Run Custom Tool” which generates the code. That’s awesome to me.

Second, Microsoft Studios has already previewed Spark for Xbox One. I am not sure I should call it a game. It’s more like a game to make a game and then play the game you (or your friends) made. In a way, you are code-figuring a system that generates the logic obeying your design.

What’s different about Spark is that the diversity of the resulting games is an illusion created by the multiplicity of variations available to the designer. Instead of saying “Any game, go!” it’s subtly boxing users inside the constraints of the Spark world. Does that matter? Not for Spark; and, if you step back and look – this is approaching how the Enterprise could create subroutines for Captain Picard.

Picard didn’t use an Xbox controller, he used his voice. But, he also could not say anything he wanted – he had to work inside the parameters of what the Enterprise computer could actually do. Yes, that’s a big box to play in. Sure. But, Spark is an amazing real world example of how code-figuration is coming of age. Its box of constraints is small, but it’s just the beginning.

Is code-figuration development inevitable? It’s already here.

Have another idea of an inevitable thing? Tell me!

Best of luck!