Tuukka Turunen

Internet of Things: Why Tools Matter?

Published Thursday September 15th, 2016
7 Comments on Internet of Things: Why Tools Matter?
Posted in Biz Circuit, Embedded, Internet of Things

With the Internet of Things (IoT) transformation, it’s obvious that the amount of connected devices in the world is increasing rapidly. Everywhere around our daily lives we all use more and more of them. In addition to being connected, more devices get equipped with a touch screen and a graphical user interface. We have all seen this around us and many Qt users are also deeply involved in creating software for these devices. To bring in some numbers, the Gartner group has estimated that the amount of connected devices will grow to a whopping 20.7 billion by 2020 (and some predict even higher growth, up to 30 billion devices).

Not only is the number of devices growing, but the complexity and amount of software is also increasing rapidly. For example, today’s passenger car can have over 100M lines of code, and this is expected to triple in the future as the functionality of automotive software increases. Cars are on the high side of complexity, but even the simplest connected devices need a lot of software to be able to handle the requirements for connectivity, security and to match the growing usability expectations of consumers.

Here is how the estimated growth of connected devices looks in a line graph:


What is inside these devices? What kind of software drives the connected devices? What kind of skills are needed to build these? It is estimated that 95% of today’s embedded systems are created with C/C++, and that this is not significantly changing in the foreseeable future. Then, on the other hand, according to a study there were 4.4M C++ developers and 1,9M C developers in 2015 in the World. An older study by IDC from 2001, shows that the number of C++ developers was estimated to be 3M back then. This means the number of C++ developers has been growing steadily around 3% per year and is expected to continue with a similar trend – or at least within a similar range.

So, a visualization of C++ developer growth provides the following graph:

The estimated number of devices, most of which will be done with C and C++, is already growing with much faster pace than the amount of C++ developers and the growth is expected to get even higher. Due to the increased complexity of functionality, the amount of software needed in the devices is also growing. Although some of the new devices will be very simple in functionality, on average the devices get more and more complex to meet consumers’ requirements.

Now, comparing these two trends together gives us an interesting paradox: How can the few millions of C++ developers match the requirement to build the dozens of billions of connected devices in the future?

Putting these two graphs together, we can clearly visualize the paradox (and a possible solution):



So how does this add up? Do we expect a 2020 C++ developer to write 20 times more code than a decade ago? That does not work. Even if all the C++ developers would focus into embedded, with no one creating and maintaining software for desktop and mobile applications, there still may not be enough developers. C++ developers can’t be easily trained from other professionals – programming is a skill that takes years to learn and not everyone can master.

So, Something needs to be done to facilitate two things: Enabling the C++ developers to be more productive and also helping the non-C++ developers to create the devices.

Therefore, the approach for creating embedded software needs to be adapted to the new situation. The only way to cope with the growth is to have good tools for embedded device creation and to increase the reuse of software. It is no longer viable to re-invent the wheel for each product – the scarce programming resources have to be targeted into differentiating functionality. Organizations will have to prioritize and focus into where they add value the most – anything that can be reused should not be created inhouse. Using tools and frameworks like Qt is the only viable approach to create the envisioned devices. The old Qt tagline: “Code less. Create more. Deploy Everywhere” is more relevant today than it has ever been. Qt has a solid track record from embedded, desktop and mobile development, making the creation of applications easy in any platform and also across multiple platforms.

It is likely that even reuse of software assets is not enough. It is also necessary to increase productivity of the C++ developers and to extend the personnel creating the software beyond the ones who master C++. Using the widely renowned and well-documented Qt API functionality and excellent development tools, C++ developers are more productive than before. Qt also provides an easy-to-use declarative QML language and visual design tools for user interface creation, growing the amount of people who can create software for embedded beyond the C++ developers. There are already over million developers familiar with Qt, and new developers across the world are taking it into use every day.

With the QML language, visual UI design tools and functionality for embedded devices does not mandate C++ skills for every developer in the team. It will still be necessary to have core C/C++ developers when making embedded devices, but others can help as well. Using Qt allows both non-C++ developers to create some of the needed functionality and the C++ developers to be more productive.

To increase developer productivity and to extend the developer base, Qt offers otherwise unseen ease of embedded development. Qt provides many of the common development boards supported out of the box, one click deployment to target device, built-in device emulator, on target debugger, performance analyzer, visual UI designer and many more tools in the integrated development environment. With the integrated tools and extensive API functionality, developing with Qt is unlike traditional embedded development. Qt makes embedded development almost as easy as creation of desktop or mobile applications.

The future is written with Qt.

To learn more about the latest developments of Qt, join us at the Qt World Summit October 18-20th 2016 in San Francisco, USA.

We’re also hosting an online panel discussion with industry experts around IoT and software in general September 27th. Register today for the webinar for an interesting fireside chat!

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Biz Circuit, Embedded, Internet of Things



Very good article. Very interesting.

john says:

I fear that qt’s qml is heading in the wrong direction,

Today, web’s javascript is going to webassembly, which want use c++ and other language to replace javascript for
strong type and high efficiency,

But qt’s qml is going to the opposite direction, use javascript to replace c++, it is weak type and low efficiency, this is wrong.

Qml is not so good for ui too, because it is not a standard, other system will not use it, so it will die, just like wpf.

I think html5(front end) + c++(back end, can be compiled to webassembly) is a more right direction than qml+javascript.


@John: WebAssembly is certainly interesting, but in my opinion it is not the best approach for embedded systems UI currently. Many of the systems do not have enough resources (processor, memory, energy) to run HTML5.

john says:

Thanks for your reply.

What i think that we needn’t a complete HTML5 browser, because we only use html5’s custom-element syntax https://www.w3.org/TR/custom-elements/,
every qt widget define a html5’s custom-element, needn’t any other html5 element, every qt widget draw on html5 canvas, so we only use qt to simulation html5 canvas.

If after several years webassembly finish DOM api, then every qt widget can draw on html5 canvas directly, then the same front-end(html5) and same back-end(c++, complie to webassembly) can run on web and local. we can reusing most front-end and back-end code.

Of course, what i say it is too not mature, too simple, but there’s a good aspect:front-end(html5) and back-end(c++) are all standards, will not die quickly, and needn’t rewrite software again and again.


Jake Petroules Jake Petroules says:

Tuukka, you misunderstand what WebAssembly actually is. It has nothing to do with HTML5 whatsoever, nor is it really even related to the web or web browsers. The major browsers vendors want to include it as a component within IE/Chrome/Safari/Firefox and it will be able to integrate with the “web platform”, but WebAssembly itself is entirely separate. I think it could actually be an excellent solution for embedded devices exactly because of the reason you stated – many systems do not have enough resources (processor, memory, energy) to run an HTML5 browser.

See https://github.com/WebAssembly/design/blob/master/NonWeb.md for a more complete explanation.

Kambiz says:

@John: JavaScript has not replaced with C++ !

You can mix C++ and Qml together, qml can be powerful and useful in the future, because you can mix it with C++, Js and HTML.

Of course, don’t forget that QML’s performance is better than HTML5.

tham says:

Using QWidget and qml in my daily life, qml works well and ease to pick up, imho it is easier to use than html5. Although qml is a neat tool to create simple ui on mobile, I always miss the compile time warning and errors generated by c++ compiler.

In large project, compile time checking like c++ provided is a time saver, it would be better if qml can give user another choice than js which support strong type, compile time checking when the users want to write some simple logic directly in the qml document.

Commenting closed.

Get started today with Qt Download now