Apps optimize

Long-term technology trends developers need to know

Justin James highlights some factors developers should consider when making tech decisions about languages, Web Services, databases, and more.

The landscape of technologies that developers deal with is constantly shifting. Here are some of the most important long-term trends you need to be aware of and should take into account when you make technology decisions.

Languages

The .NET and Java ecosystems are taking a lot of ideas from Ruby, JavaScript, Python, and other similar systems -- and for good reason. Those open source systems are moving much faster because of the way they are governed. A lot of the best ideas in development right now are coming from those projects. Does this mean that .NET and Java are headed for the scrap heap? No way. Those languages will continue to be thought leaders, and a small minority of developers will work with them and influence the greater community.

These languages will never go into a strong mainstream position because they lack the features and toolsets that allow companies with anyone other than "A players" to feel comfortable with them. Companies recognize there is a fair amount of mediocre talent in their ranks, and these languages depend upon "process" (like unit testing) to deliver good results, especially when working in a team, and companies can't trust their teams to follow process. So instead, they need to sledgehammer them with tools that enforce artificial restrictions. Everything from strong typing to centralized version control is oriented around forcing bad developers to do the things good developers are able to do on their own. I do not see this changing any time soon.

Unless you are in an environment that is friendly to systems like Python and Ruby, you should expect to use .NET and Java for the long term.

Web Services

Web Services will continue to make progress as a tool for real work. SOAP and REST have positive and negative attributes, and neither is the "final answer" to the Web Service protocol situation. It seems likely that at some point a standard will come out that will combine the best attributes of SOAP and REST. Until then, you need to support both most likely, because REST and JSON are too useful to applications that deal with a Web browser to ignore, and SOAP has too many enterprise features and too much enterprise adoption to wish it away.

Databases

The NoSQL movement has made some advances, but at the end of the day, traditional relational database management systems (RDBMSs) make too much sense in far too many scenarios for NoSQL to replace them for most developers. Is there an opportunity for some developers to cut the cord from RDBMSs? Absolutely. But those developers are going to be working on very specific applications that lend themselves well to the NoSQL model.

I am glad that excellent NoSQL options exist, but I am doubtful they will be able to capture a lot of mindshare any time soon.

Front-end technology

HTML is here to stay. HTML is not a great format at a technical level for a lot of the work folks are doing with it, though it has matured to a very usable point. In the last several years (thanks to jQuery and similar frameworks), HTML has surpassed the UI potential of native applications at the price point of "free." Yes, there are ways to do better than HTML with native applications, but not if you are looking only at free components.

Once you get over your sense of technical correctness (it took me a long time), HTML is a perfectly usable system for creating applications. And while I cannot point out any individual native system as "better" in one way or the other, given a choice between HTML's compromises and learning three, four, or more front-end systems, most developers will choose HTML.

It takes a big budget to hire enough folks to cover the spectrum of Windows (now Classic and Modern), Android, iOS, Mac, and Web. Good luck finding a non-HTML tool that can handle all of those scenarios.

Mobile development

I am grateful I didn't bet my career on mobile development, because I don't know what tomorrow holds. Let's look at the list of mobile players in the last 15 years, in roughly chronological order:

  • Palm
  • RIM/BlackBerry
  • Microsoft (Windows CE)
  • Nokia/Symbian
  • Microsoft (Windows Mobile)
  • Apple
  • Google/Android
  • Amazon/Android
  • Samsung/Android
  • Microsoft (Windows 8, Windows Phone 8)

I include Android three times because Amazon and Samsung are trying to carve out their own Android ecosystem. Microsoft makes the list three times with different iterations of its mobile operating systems. The mobile market is a merciless meat grinder, a never-ending battle for vendors, consumers, and developers. From month to month, you cannot count on a device being available for sale, thanks to legal injunctions.

There are no obvious trends in mobile other than "progress." When Apple launched the iPhone, it looked like tightly controlled ecosystems made perfect sense. Now Android is cleaning house with a pretty open ecosystem. There is no rhyme or reason to the mobile market, and it is tough waters for developers to navigate.

J.Ja

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.

11 comments
RMSx32767
RMSx32767

"Everything from strong typing to centralized version control is oriented around forcing bad developers to do the things good developers are able to do on their own." Spoken like a truly pretentious "real programmer". True craftsmen can do lots of things on their own but are smart enough, confident enough, and comfortable enough to enjoy working with the best features and toolsets available because they understand the PURPOSE of their job is to produce code that accomplishes a task.

Tony Hopkinson
Tony Hopkinson

The only trend I've noticed is the constant drive by business is to use productivty enhancing tools / languages / techniques etc and replace competent people with less competent ones and get as much as they used to out of the role. All is else is post decision justification from vested interests.

DrMDodd
DrMDodd

Where did JavaME that powers billions of devices feature on the list of mobile developments?

YetAnotherBob
YetAnotherBob

The review is generally good, but, the Author missed something. Programming in Python allows for the finished product to be compiled in either Java or the Microsoft version .Net. I believe that the same is true for Ruby. That means that even if I am in a shop that is tied to a Java code mess, I can program new stuff in Python, which was designed as a language to be readable and maintainable. Further in the future, I expect to see more and more programming done with HTML5 and JavaScript. While not an ideal platform, it has the advantage of 'run anywhere'. Too bad the documentation part is not great. But, poorly documented code can be created in any language.

maszsam
maszsam

Then you realize that all you really need is client side, server side and a way store and retrive data. If you are a free lancer like me, then using propriatray software is cost prohibitive. I started programing in the early '60s. I have seen so many flavors of the day dry up and blow away. I actually got out of the trade for a few years during the time when the popular joke was "buy today and it's obsolete tomorrow" as that seemed like a fools game to me. Things are quite stable now. The most efficient way to produce results on new projects from my prespective is Open Source, road tested, web approved software.

vjv.mabaso
vjv.mabaso

So basically Yukihiro "Matz" Matsumoto is cooler and smarter than Bill Gates,James Gosling, Mike Sheridan, and Patrick Naughton... lol, kwaaa! Meanwhile... The only languages I can genuinely say I am comfortable with are.... wait for it... "C# and Java". -No wonder the I.Q test I wrote listed me as "average intelligence"... *sigh*

nervouscat
nervouscat

I agree with the part about tools being necessary for Java and .NET to maintain popularity. However, I'm not sure I agree with the lowest common denominator factor that the sheer numbers of mediocre programmers drives Java and .NET. Enterprise development at large I.T. organizations may not be as cutting edge as it used to be as the technology matured. I started in Java in the late 1990s after a decade of programming in C and C++. It was a natural progression to Java. I have stayed in Java through countless I.T. organizations who tend to hire me based on what I did recently (which was always Java web development). I remember 10 years ago people using Enterprise Java Beans just for the sake of Enterprise Java Beans. Were these EJB developers mediocre? EJB was a bloated framework with a huge learning curve. Yet any project manager at the time thought this EJB technology was the best thing since sliced bread and accepted it as a defacto standard. Sometimes it's the tool/framework and not the developer that is mediocre. It also depends on the company culture - I.T. organziations are not going to have the most interesting stuff to work on compared to working at software companies and startups. Not all of us get to work on clouds, mobile apps and other cool stuff. Instead, we just maintain the infrastructure of Java and .NET because it has existed so long and has become part of the legacy, just like the COBOL programmers from decades ago. The more tools for Java the better. I used to write my own tools in the beginning as a C programmer, and the older I got the more I like using off the shelf tools. I'm nearly 50 years old and still programming in my chosen profession (recovered from multiple layoffs in the last decade). I'm not mediocre - if I was I would have been weeded out or changed careers years ago. I probably will remain a Java programmer until I retire, and I am ok with that.

atoms
atoms

Wow. I've never heard it put so bluntly or succinctly before - that the reason we are still plagued with Java and .NET is because the general talent pool is not smart (or resourceful or whatever) enough to use the more fun and interesting languages and frameworks. Thanks for shedding some light on what was previously a mystery to me. I could not understand why anyone would intentionally chose to use .NET or Java. Now it makes a lot more sense.

Tony Hopkinson
Tony Hopkinson

Though his use of strong typing instead of static typing raised an eyebrow. What is undeniable, is while strong statically typed languages were designed to address the manifest weaknesses of weakly typed languages including increasing the productivity of competent developers, commercial developers saw a "better" way. Instead of making the competent more productive, you could make much cheaper incompetents less un-productive... As for dynamic versus static typing, it's not a free lunch. How many times have we seen code bases in traditionally statically typed environments even if they started well, even if they were done with TDD, get mired in technical debt before version 1b got released (often before version 0 to be honest..) The good thing about dynamically typed environments isn't what they can do, it's what they can't. Tell you, you've done something stupid at compile time. For that you need tests, and for tests you need good design practices. Most of those lovely shortcuts, bodges, can you justs, just one more changes, bugs that are features, and fix it next versions, gone. So while I might miss some aspects of .net, as I still on occasion some aspects of unmanaged code and indeed even straight procedural. I'm really looking forward to being able to saying to the business heads, we either do it right, or not at all. All the waffle about "up-skilling" and new and blah, as nothing to competent developers, compared to changes it will force on business in commercial software development. Perhaps a better article would be long term technology trends businesses need to know. Course first we'll have to explain some fundamental principles. So paragraph 1. Long. As in not short, after the next period/quarter/year end report, spans accrual of bonus and or promotion. ..