More than half of app developers are living in “app poverty”: making less than $500 a month from their apps.
We’ve produced an infographic which looks at insights such as this from The Evolving State of Mobile Commerce, a report published by VisionMobile in collaboration with Braintree.
Here are some more of the insights about app developers that are featured in the infographic:
Half of M-commerce developers are using the App store
Operators are still bankers in the Middle East and Africa
The new Developer Economics Infographic is out! The most global developer survey so far has reached over 16,500 developers from 145 countries. Have a look at the findings and let us know where you stand in the global ecosystem. Bonus: hear it from our survey prize winners!
Developer Survey: Developer Economics Q2 2016
Interested in more findings? Check out our more recent reports, here.
Welcome to the full rundown of the Developer Economics: Developer Tools Benchmarking (April-May 2016) prize winners. Below you’ll find a table comprised of both the email addresses and countries of all the people that won (the emails are obfuscated for security reasons).
Winners have already been notified by email – if you recognise the email fragment as yours and we haven’t contacted you, please drop us an email at survey@visionmobile.com
Improving ourselves by listening to what you have to say is one of our top priorities so don’t forget to complete the short feedback form we have prepared for you. Our aim is to improve our offering by identifying your interests so we cannot stress enough how important your contribution is!
“… However, when we talked with web developers, they still struggled with using Windows as their primary devbox.”
The above quote is from Kevin Gallo, the VP of Windows Dev platform, and was delivered around mark 0:38 of his presentation in Microsoft’s Build 2016 keynote. He then continued with the observation that “… many of them have workflows which rely on open source command line tools, scripts and frameworks”, and finished with a slide that his audience was – at first – slightly unsure on how excited to get about: Bash is coming to Windows.
Screenshot #1: Kevin Gallo’s slide from Build 2016 announcing Bash coming to Windows
If you let the video play for another 7 seconds, you’ll also catch a glimpse of Gallo’s audience. You can see the emotions depicted on their faces form a picture that explains perfectly the complex (and sometimes tumultuous) relationship of Microsoft with Linux and the Open Source world. Three persons are smiling excitedly and beginning to slow clap (the ones that suddenly realise how much easier managing their OS stack or scripting their Windows environment will become). You then have the classic cautious indifference of the majority of developers that wait to see whether this is “worth getting excited about”. Finally, you can also detect some unguarded annoyance from the fanboy crowd (“Seriously? I have to sit and hear about Bash? What’s wrong with PowerShell?”).
Personally, I belong to the first group. Despite working with open source technologies since the beginning of my professional career back in 2003, I’ve never managed to move away from Windows. To this effect, when I saw Rich Turner and Russ Alexander casually doing a apt-get install git on Windows to install git, I was excited. A lot.
But until the functionality showcased in the video above is mature and stable enough to be rolled out, I’ll continue using my current workflow which has served me faithfully since 2011: And that is bash on Windows (To be precise: A more “cut down” version of Bash. Read on for details).
The challenge: Production-strength command line workflow in Windows.
One might argue that Windows was never meant to be “driven” from the command line.
Microsoft tried to mitigate this back in 2006 by rolling out PowerShell, a shell and scripting language that gives users full access to their whole Windows environment. For Windows devs this was a great extra tool but for all other developers it was still not enough to lure them away from the power and versatility they found on the Linux command line.
Add to this the strongly opinionated naming conventions and approaches that PowerShell inherited from the .NET Framework (did you know that cd is but an alias to the “proper” command which is Get-ChildItem? That’s camelcase _and_ a dash that autocompletes with tab even if you type it in lowercase. Strange stuff) and you can see why it’s really hard for e.g. a PHP developer to consider it for his dev workflow.
When every single blogpost or article or tutorial written about a subject, e.g. “how to rebase branches in git”, includes instructions and screenshots that clearly demonstrate the flow in a Linux shell, it’s only natural for the developer to assume that this is the correct way of doing things.
Towards a solution: Install Git for Windows
For my frontend-with-a-bit-of-PHP-but-from-a-Windows-OS workflow I always relied on certain “battle proven” tools. WinSCP was the weapon of choice when files needed to be moved from one place to another (either via FTP, SFTP, SCP or even rSync). Putty allowed me to connect via SSH to all my dev boxes. TortoiseGIt ensured that I could use git directly from my Windows explorer interface.
The first “lightbulb / aha” moment for me occurred when I installed Git for Windows after being prompted to “try it out on the command line” by a colleague.
One of the steps of the install wizard prompts you to choose “How would you like to use Git from the command line?”:
Screenshot #2: Choosing how to use Git for Windows
… and it mentioned “Bash”!
Installation completes and suddenly I get a shell in Windows that looks suspiciously similar to what I’m used to in Linux or iOS installations:
Screenshot #3: MinTTY terminal emulator window
Bash in Windows: How it works
Kudos? To the awesome devs that worked to bring Git to windows – https://git-for-windows.github.io/.
In essence the installer sets up a unix-like shell environment (MinGW – “Minimalist GNU for Windows”) which – very roughly speaking – creates the needed Unix layer that shells like Bash can run onto.
A terminal emulator called MinTTY is also installed (shown in screenshot #3 above) which is a Windows program that runs the Bash shell which in turn enables you to use quite a good subset of the Linux commands needed for an open source dev workflow.
Looks are important
… especially if you are an ex-designer-turned-frontend-developer. Going from the black and white severity of cmd.exe (where you could not even resize the window to the dimensions you wanted) to MinTTY definitely boosted my “developer happiness” feeling:
Screenshot #4: MinTTY terminal emulator window
In the above example, I manually mapped the colours from the famous Solarized colour theme to the default 16 ANSI colours. For the font I chose the crystal clear Consolas font set at 12 point, although I’ve recently been experimenting with Adobe’s Source Code Pro as an alternative.
The MinTTY window can be resized to any dimension of your choosing. You can also use the same shortcuts as you use in the browser to resize the text on the fly (CTRL+plus, CTRL+minus or CTRL+mouse wheel). Finally you can launch as many instances of MinTTY as you want, enabling you to lay out a series of windows into your codebase and file structure, exactly as it suits you:
Screenshot #5: Multiple instances running at the same time at different dimensions and font-size
I can now do {{thing}} from the command line
The list below demonstrates just a small subset of the stuff you can do with Bash in Windows that I found particularly useful and / or helpful.
Git
No more “download and unzip”. Git clone any repo of your choosing in any directory in your filesystem. The handy “GIT Bash here…” shortcut that appears when you right click any folder is particularly useful here.
Linux command line
MinGW supports a subset of the various commands and programs available in Linux, things like awk, sed, grep, find are all here, ready to be used. Shortcuts are also available (CTRL+U, CTRL+K for inline editing, CTRL+R to lookup on Bash history etc) as well as piping and redirection.
SSH
OpenSSH works right out of the box. Set up your keys by using ssh-keygen (exactly the same way you would do in a Linux box) and then connect to any of your machines. You can also setup an ssh-agent (exactly the way Beanstalk or Github or Bitbucket explain in their online tutorials) to ensure you don’t retype your password all the time. Of course ftp and scp are available as well.
Vim
No more notepad++ for me. After I went through the steep-as-mount-Everest learning curve I found out that vim was the best tool for quick text edits (I’ve strongly resisted the urge to play with emacs. We’ll see).
Bash scripting
The very first bash script I experimented with (and use constantly nowadays) is z: https://github.com/rupa/z. I no longer rely on lengthy cd statements such as:
cd /some_directory/nesting/nested/my_work
But rather do a:
z my_work
… and I’m immediately taken to the directory I want.
“You should really switch to {{enter Linux distro name here}}”
Indeed. But even if I do so, there is still a vast number of devs out there who still need / have to work with Windows. One year ago, Isaac Schlueter (co-founder and CEO of the Node Package Manager – NPM) had this to say:
If you want devs using your code, this matters
Until WSL is out … Bash in Windows
The soon-to-be-released Windows Subsystem for Linux is a brilliant (and much-needed) step forward in making the Windows environment a first-class citizen for open source development workflows.Nevertheless, there is no need to wait for Microsoft to make WSL available to everyone.
I’ve been using Bash in Windows – in my daily workflow – for the last 5 years and it’s working like a charm.
If you want to do the same, simply install Git for Windows.
Have you ever asked yourselves what would it be like if there were only 100 developers in the world? Well even if you haven’t, we are sure we have just made you think about it.
Based on our Developer Economics survey that reaches 30,000+ devs per year, across mobile, IoT, cloud, desktop, AR/VR, machine learning , we designed a very interesting Infographic illustrating this scenario.
How many men and women would this world include ?
Which continent would be the most populated ?
How many would be Pros and how many Hobbyists ?
How experienced are developers in this world?
What is the most popular coding language?
If there were just 100 developers in the world, then:
Integrated Development Environments have evolved to solve every problem a developer can have, but in recent years we’ve seen a scaling back of capabilities as developers embrace more-basic options. At VisionMobile our latest developer survey is (amongst other things) trying to find out why, though we do have some ideas on the subject.
When I first programmed a computer I was lambasted, and very nearly ejected from the school computer club, for not having written my program out on paper before arrival. Computer time was too precious to spend composing lines of code. Minutes at the keyboard should be spent entering pre-written programs; not making them up as one went along.
Needless to say that was a very long time ago. These days program composition is done using a screen (or several) with working code being thrown together in what looks suspiciously like a process of trial-and-error. The modern Integrated Development Environments won’t let a compiler crash for want of a missing semicolon, or the use of the Queen’s English (“colour”? Really? ).
A modern IDE will spot variables using the wrong case, and APIs which haven’t been imported, reducing the development time and making life easier for the developer – but, if modern IDEs are so great, why do so many developers choose not to use them?
Vi, Emacs, Notepad++, and Sublime, all make regular appearances in developer toolkits, despite the existence of fully-featured alternatives. You might be a savant mnemonic who’s only outlets are Street Fighter II and programming in Vi, but for most humans a menu structure and “compile” button are essentials.
Microsoft’s Visual Studio is still the standard by which others are measured, though at $499 it’s not the cheapest option which may put some people off. Eclipse provides almost as much utility for a lot less money (none at all), and Visual Studio Code (Microsoft’s free code editor) is now at version 1, and also free. A licence for Sublime Text, on the other hand, will cost you $70 – so the choice is not really about money.
We know that developers increasingly work across platforms, languages, and sectors, and this may provide an answer. Visual Studio can do it all, creating applications for mobile devices, embedded technology, and cloudy servers, but so can Notepad++, and with less effort, and better support.
Take the support site for the Adafruit Trinket (a $7 prototyping board), which provides a step-by-step guide to creating applications using the Arduino IDE, so when I want to program a Trinket then that’s what I use. I’m sure that I could use Visual Studio, and it would be pretty and probably reduce my development time, but it would take effort to get it configured and I don’t spend enough time programming the Trinket to make it worthwhile.
Similarly – if I’m knocking out some Python I’ll boot up IDLE, and when I need a bit of HTML I’ll use Notepad++. These are not the best tools available, but they are the default tools and will work with every library, plugin, and extension available. If I programmed Python every day then I’d find a better tool (or perhaps a better job), but I’m too lazy to muck about getting a proper IDE configured and will make do with what’s available.
Thanks to a dot.com development career I’ve no time for debuggers or unit testing (testing is what users are for) which makes these bare-bones tools ideal for me, but what we at VisionMobile would like to know is why you choose one IDE over another, and how many you’re using on a daily basis.
Which Integrated Development Environments are you using?
When you complete our 11th Developer Economics survey you won’t just be asked which IDE you like to use, but also what you use it for, and why you like to use it. We’ll break down the data, and share information on who is using what, and why.
We’re not just collecting data on how developers create software. We’re collecting data on how developers would like to create software, and what stands in their way. If you have 12 minutes to spare then do join us in finding out.
At VisionMobile, we believe in the people behind the numbers. While it’s important to understand numbers, trends and segments, it’s equally important to understand the people who buy our products and services. This developer profile is one in a series designed to help us get to know some of the people behind the statistics.
Job title and company:
Founder, Independent Consultant at Carrera Group
Country/Area:
Florida, United States
Development Focus:
Enterprise software expert for hire. “I like doing independent work,” he explains, “there’s no enterprise baggage.. You’re there to do a job, to solve a difficult problem, to help clients through something.” There’s where he likes to focus: on fixing problems and doing so outside of a company’s culture. He continues, “I know we’re not going to rewrite this whole thing: I’m here to do one specific thing and provide some development help or architectural advice to help get you out of a jam. For six months, I can help with this antiquated technology.”
He works across multiple technologies, but focuses on the healthcare industry.
Languages used:
Kastroulis counsels against getting too caught up in language or platform fanaticism. He recommends using the best tool for a given job. That said, his go-to technologies include JavaScript (Node.js), Microsoft .Net, C, Python, and a “tiny bit” of Java.
Favorite project built recently:
Kastroulis reports how he enjoys working on new projects with new challenges. His favorite project was building a high performance column-store database kernel. Another recent project was an electronic prescribing and ER discharge application for both the web and iOS devices.
Favorite tools:
As do many developers, Kastroulis prefers to use the appropriate toolset for the project – and to choose toolsets he’s most familiar with. Enterprise developers may not have that flexibility, but independent developers often do. His favorite toolset is Visual Studio Code, which works across platforms. He also uses node.js and a lot of JetBrains tools (especially for C and Python). On a Mac he uses Sublime Text and command-line tools. Of course, for source code management he uses GitHub and Git on the command line. “I’ve worked with Amazon Web Services (AWS) and Heroku, but Azure is my cloud host of choice,” he adds. “Azure is easier to work with and it’s HIPAA compliant.”
Best developer-related advice you would give to another developer
While it’s hard to predict the future, Kastroulis advises developers to “get an idea of where the world is headed and try to get there first.” He concedes that you may not always be right, “but follow your gut.” Take advantage of industry knowledge, and take advantage of the expertise you gain focusing in your industry (healthcare, financial, and so on).
That might sound odd, but it’s one of many conclusions drawn from our biannual study, and presented on developer experience in our (free) State of the Developer Nation report.
The report draws on data from the world’s-biggest survey of those working in software. During the latest wave we reached more than 21,000 developers, and found that they have less experience than they did a year ago.
Not individually of course. There’s no memory loss involved here. What happens is that the developer community is growing, and new programmers inevitably bring down the average level of experience. This has serious implications for the future of the industry.
If we take mobile developers, who are typical, we can see that right now 40% of them have been developing software for more than six years, but a year ago that proportion was 43%. At the other end of the spectrum we have 17% of developers with less than a year under their belt, up from 14% this time last year.
That pattern is repeated across all sectors, even IoT (which is so nascent it often bucks the trends). While a good proportion of developers have built up their skills over time, we are going to have to adjust to a world where more software is being created by developers with less hands-on experience, and understand the implications of that trend.
One of those implication is a shift in the popularity of certain programming languages over their more-traditional brethren. This time we’re focusing in on the last six months, but if we again look at mobile developers we can see them embracing scripting languages, at the cost of Java and the various forms of C. Objective C takes the biggest hit, assaulted by Apple’s new wonderkid Swift on one side, and the (JavaScript powered) cross-platform toolkits on the other. Objective C is dropping fast, while C/C++ has a gentle decline and C# is just about holding its mindshare (thanks to Xamarin, which compiles C# to Android and is now a Microsoft property).
On the cloud the trend is less pronounced, but still evident. Java is growing, but so are all the other languages. PHP… C#… Python… in fact all the top languages have gained mindshare as cloud developers become increasingly polyglot while giving up on some of the niche dialects.
One area on the rise, across all the sectors, is the use of visual tools for software development. These drag-‘n-drop environments are often looked down upon by “proper” programmers, who respect the digital hierarchy (where Assembler is king, dialects of C make up the court, Java is left outside the room, and scripting languages aren’t permitted into the palace). These visual tools are still only used by a minority (25% of mobile developers, 19% of cloud) and fewer still rely on them as a primary tool (5% across mobile and cloud) but that proportion is growing steadily, and relentlessly.
The fact is that there aren’t enough low-level programmers to go around, and most applications don’t need them. Visual tools, and scripting languages, are good enough for the vast majority of applications in any sector. That applies across consumer and enterprise markets, as users of all kinds start creating apps with a few clicks. However, there is a question about how long can we consider those users to be software developers, and the tools they use to be designed for software development.
“If This Then That” (IFTTT.com) is a marvellous tool, enabling anyone to create “recipes” where an event (“this”) triggers an action (“that”). An incoming email can trigger the (Philips Hue) lights to flash red three times, making the owner feel like Batman while simultaneously aggravating his whole family.
IFTTT users can chain recipes together, creating actions that seed multiple events, loop back on themselves, and even branch based on inputs. At some point we have to accept that the IFTTT user has become a software developer, or that IFTTT shows us what the future of software development might look like.
Not all applications will be written that way of course. Lower-level languages will still be needed to plumb the functionality together, but there will come a time when the vast majority of applications will be created by developers with no software development experience at all.
Developer Experience trends
That day is a long way off, but with every year it gets a little closer and our data shows that process is in action. You can see more by downloading our State of the Developer Nation report, or talking to us about custom reports looking at the developer community, while there still is one.
How is cloud and desktop developers landscape evolving? We’ve prepared an infographic with some key insights that can help you better understand the cloud and desktop development, based on our recent report focusing on the topic. Here are some of the key insights:
49% of developers are working professionally across both cloud and desktop
41% of desktop developers are creating applications which never leave the browser
54% of cloud developers who use advertising are making less than $500/month
Check out the Cloud and Desktop Developers infographic for more insights:
Developers struggling to get noticed on the app stores, or hoping to capitalise on the growth of enterprise messaging, are looking to a new way to reach their users – via a chat interface. The logic of reaching users where they spend the most time seems sound, and that is clearly in messaging apps. Does the typical consumer or business user really want to be taken back to the days of the command line interface though? Is this the next big market, or will it just be a trendy niche? [tweetable]Natural Language Processing (NLP) technology seems to be the key to mass market adoption[/tweetable]. Can that interface scale across thousands or millions of apps, or will it be dominated by a few key players and use cases?
An old idea
[tweetable]Chat bots – apps that communicate via a textual, conversational interface are nothing new[/tweetable]. A convincing conversational computer program has been a goal of artificial intelligence research since Alan Turing proposed his famous test in 1950. As long as there have been chat-rooms, including the bulletin board systems that dominated the Internet before the invention and adoption of the web, there have been chat bots. Even commercial scale and conversational access to internet services are far from recent developments. The SmarterChild bot on AOL Instant Messenger and MSN Messenger (now Windows Live Messenger) had 10 million active users and processed 1 billion messages per day. It provided access to news, weather, sports, a personal assistant, calculator etc.
New scale & changing habits
Why the renewed excitement in chat bots? Two reasons – mobile messaging scale and enterprise messaging growth. Third party mobile messaging apps are rapidly heading towards 2 billion active users globally. These apps are typically the most used on any mobile device. Following the model of Asian messaging apps WeChat and LINE, the owners of other messaging apps want to turn them into platforms. At the same time, Slack is attempting to create a platform out of their enterprise messaging product. [tweetable]The impressive growth of Slack in the enterprise, where people are actually happy to pay for software[/tweetable], means a lot of entrepreneurs would like to ride their coattails to success. There are two separate markets here, with a common interface and some common technology.
Better technology for smarter chat bots
It’s the improvement in that common technology, particularly for NLP, that leads many people to think it might be different this time. Conversational interfaces might finally be able to deliver a great experience. However, there are some tradeoffs here for developers. One appealing aspect of a textual interface is that it can be much less effort to develop than a mobile app UI. Unfortunately NLP research has been disproportionately focused on English so far – the technology isn’t as good in other languages, so these interfaces automatically have a more limited audience. The more sophisticated the NLP, the more work involved in developing the interface. Using a 3rd party NLP service can significantly reduce this effort but also removes a key source of differentiation if your product is only a chat bot. Without NLP a bot is either focused on a very specific task or only for power users – mass market consumers aren’t going to want to memorise a lot of specific command syntax. At the other end of the NLP sophistication spectrum, is it going to be viable trying to compete with the likes of Google and Facebook as the best way to access mass market services?
Will Facebook own the consumer market?
Telegram’s bot platform might seem interesting as it reduces the need for NLP (and typing) with dynamic custom keyboards but their reach is a tiny fraction of the likes of Facebook Messenger or WhatsApp. Unfortunately [tweetable]Facebook doesn’t have a good record as a developer platform provider[/tweetable], which they managed to prove again recently, if such a reminder were needed, by announcing they’re shutting down Parse after promising developers their backends were in safe hands. Indeed chat bots on the big consumer messaging platforms may have some success at first but it’s likely to be the platform owners that take the lion’s share of the revenue in the end. These platforms will probably be great for businesses to reduce marketing and customer support costs with chat bots and they’ll be paying Facebook (and possibly others) for the privilege of talking to their customers in this way. There are probably also good opportunities for smaller developers to help companies build these bots.
An opportunity to differentiate enterprise services
The enterprise opportunity is different. As a growing number of companies reduce their email usage and build workflows around chat in apps like Slack and HipChat, the most natural way to access some premium services will be through chat (at least for some use cases). For example, when discussing past sales, or future sales projections, it would be much more natural to ask an accounting, or forecasting SaaS tool to give you a chart for the relevant period than to switch away to another application to look that up. However, as with most of the obvious examples you could imagine, it’s unlikely that these services would operate entirely through a chat interface. It doesn’t make much sense to enter all of your accounting data via chat or build your sales forecasting model that way. As such, chat bots become just one of many interfaces to a cloud service. There are opportunities for new services to get discovered, or existing services to gain market share, by being early to support chat interfaces but 100% chat-based is unlikely to be a giant new market.
Evolution not revolution
In most cases, consumer or enterprise, conversational interfaces are just another channel. Much like mobile apps are just another channel for many services. They can be a channel that increases convenience or reduces friction for some key use cases. This also follows mobile but their increased convenience and usability lead to a massive increase in total use. The change messaging platforms will bring is nowhere near the same scale as the shift to mobile. The things that were really interesting on mobile were the ones that couldn’t be done, or were too inconvenient to bother with on desktop platforms. What new possibilities do conversational interfaces bring on mobile platforms? What mass market use cases haven’t already been tried (and widely under-used) by Apple with Siri? The most interesting areas are probably those that involve some element of discovery – when you don’t know which app to go to – or embrace the asynchronous nature of messaging. That said, how do you discover a new chat bot to help if you don’t know what you’re looking for? What business models would work for a purely conversational interface? The chat bots may be on the rise, but it’s likely this is more of an evolutionary step than a revolutionary one.
