Software developers can seem like a breed apart. They’re so very keen and precise in their psychological makeup that they make an excellent stereotype. But they also share very common features with the average person. Developers have to be very detail-oriented, very literal, and pretty intelligent to be able to write software in the first place. Logic is paramount and they share a passion for their craft that rises above the desire for more money. On the other hand, they are typically married, middle-aged and have children, and most likely a mortgage.
The typical developer is a married, middle-aged male who has 2 to 3 children. Males have dominated the work force for as long Evans Data has been charting this (2001) and during that time they have accounted for anywhere from 84% to 94% of the workforce. The number of male developers is currently at a low, and perhaps more females will be taking up programming – we will have to see. Currently just 14% are female.
Age is another interesting demographic. While globally he is doing an excellent job of not aging, in North America, where the median age of a software developer is now 36, he is getting younger and has been for the last three years. Age demographics shift depending on how many older people leave the work force as well as how many younger ones enter the profession. Notice in the chart below how North American developers eight years ago were by far the oldest compared to other regions. Note how developers in the Asia Pacific region were much younger. However this started to change in North America in 2008, and we’ve seen a steady downturn ever since. Of course 2008 and 2009 marked the start of the great recession in the U.S. Workforces downsized and older developers went into retirement either voluntarily or not. At the same time the popularity of mobile devices blossomed, capturing the imagination of younger people who began writing apps for sale through app stores or on their own. The result was a dramatic demographic shift.
While those developers in Asia are slowly getting older due to a relatively new workforce that is now starting to age, they are still nominally younger than in other regions. But with the North American developers now getting younger, the global developer ages are converging.
In direct contrast to outdated stereotypes, developers tend to be family men; 71% are married and only 3% are divorced. While there are different ways to measure marriage and divorce since both are events in time as well as conditions, a 3% divorce rate is very unusual, considering that some projections for the general population in the US are more like 40% divorced. So, all told, developers are not the lonely, antisocial nerds that were portrayed in earlier years, nor are they free-wheeling socialites. In fact, almost two-thirds of them have between one and three children, while 32% are childless.
Another hallmark of software developers is that they are well-educated. Programming doesn’t happen often without a lot of training and the recession only served to make more developers get advanced degrees. Eighty-eight percent of them have college degrees, about four in ten have Master’s, and another 5% have doctoral degrees. They are smart, detail-oriented and very literal, and logical.
Developers seldom start coding because they are driven by monetary goals. They are attracted to the development process itself and would not switch careers even for a significant increase in their salaries. They worry most about their platforms or tools losing relevance to the ever-changing software environment, though as they get older they start to worry about their skills becoming irrelevant.
They think of themselves, quite rightly, as being more logical than intuitive, but they also think of themselves as being moderately extroverted – not the introverted caricature we know from movies.
One of the benefits to a population with such well defined characteristics is that they can make a very cohesive community. Developer Relations professionals who put together communities for some of the largest software vendors know of the challenges of building a developer program to support, nurture and grow a developer community. At Evans Data, we’ve also been studying this for years. Putting a program together is not rocket science. There are various elements that everyone knows a program should have, but running that program and shaping it to best fit the needs and desires of your developers is truly an art.
We’ve pulled together a short white paper with advice gleaned from years of primary research on what NOT to do in a developer program. It’s a quick read with advice built on survey research from the developers themselves.
We’re back from our 9th annual Developer Relations conference in Redwood City. This was the best one ever with great speakers, attendees and events. It’s a conference focused exclusively on professionals who run developer relations programs. And while that’s still a small group, every year the conference seems to be getting more dynamic and is attracting new people from companies everywhere.
And that includes companies from industries you’d never expect – which was what struck me most about the conference this year. Because any company that has a platform or even an API that they want developers in their industry to adopt needs a developer relations program. It’s necessary to make developers aware of your technology, to recruit them to use it, and then to maintain and grow the community – and those are the vital functions of a developer program. As software permeates everything around us, so do the number and type of companies that need to set up these services. Which means that the developer relations professional is now becoming a more and more valued member of the technical team and companies are realizing the importance of that function.
This is definitely an exciting space to be in and it’ll be fascinating to watch it mature and grow.
Just back from IBM’s Pulse. That’s a conference traditionally focused on Tivoli, but IBM has re-invented itself and now there’s less focus on products than across the board IBM solutions. That means there’s a new security group, a new mobility group and a lot of cross polination between all the groups. In this spirit DevOps was a featured topic. IBM has focused tools in their Rational portfolio to address the integration and coordination between development and operations and has a very good story to tell. Let’s hope it gets told in all the right circles.
The reason I say that is that I was included in a group discussion about DevOps, consisting of analysts who usually cover IT, but not necessarily actual development, and it was a very confusing and disjointed conversation. While there was plenty of talk about IT functions and debate about the business value of services, very little related to DevOps as I could determine, which led me to think that a very major problem with DevOps is that developers and IT Operations don’t really speak the same language. As long as DevOps remains in the philosophical debate arena, I don’t think we’ll have much luck getting Development and Operations to truly understand each other and most effectively work together because some big communication problems exist. Not only do the motivations of each group subtly diverge but so do their means of expression.
Which brings me back to the tools. In its IBM SmartCloud Continuous Delivery product, IBM builds on the Jazz framework to incorporate means for specifying deployment environments to both development and QA and then implement those environments throughout the development lifecycle. Having QA aligned with both development and operations is key to creating a smooth DevOps implementation and the IBM tools suite does just that. Continuous input is also received from the end-users and feeds back into the cycle to shape newer revisions. IBM has created a well organized and effective tool framework for collaboration between Development and Operations with these products. And it is tools that lay the framework for DevOps. Without them the movement is just so much talk – and talk that is not universally meaningful.
How many times have we heard strategic product planners, product managers, CIOs and CTOs (along with stock traders) lament that they wish they could see into the future? Wouldn’t our jobs be easier if we knew which technology trends were going to work and which were going to flop? Well, in fact, we can.
Software developers portray the future of technology all the time. As the earliest possible adopters they not only portend the future but actually drive it. If developers adopt a technology it will flourish. If they ignore or abandon one, that technology will fail. We have seen this over and over again in our regularly updated developer surveys. Trends shown by developers are inevitably borne out later in the general industry.
Consider: development for Android surpassed Apple iOS in early 2011, but phone shipments for Android didn’t catch up and pass Apple’s phone until about a year later. And when future intentions of the developers were factored in we could see that Android would eventually prevail back in mid-2010.
Another example was HTML5, which took off among developers six to nine months before the popular trade media realized it and started hyping the technology. Readers of our syndicated surveys were already on board with tools fully developed when demand became apparent.
We can see demographic changes too. The age of developers in North America took a dramatic downward shift in late 2008 and their age has been falling ever since, but it’s only recently that some of the larger players in the industry have noticed this and the real implications this demographic shift will have not only on brand loyalty but also on the type of technologies that are adopted in the future.
Developers drive technology adoption and that’s why it’s possible to tell the future by studying their current actions and intentions. It’s fascinating watching this play out, and looking forward into the coming year, it’s clear that there will indeed be some shifts that may surprise quite a few of the pundits that look only at IT implmentations.
Every now and then in the world of market research someone does a survey of their users and then tries to pretend that the results can be projected out to the general universe. It doesn’t happen very often, because most people can see the flaws in that logic with a just a glance. However, it’s happened again and this time the results are being promoted as being descriptive of mobile developers at large. So, let’s see what’s wrong with that.
One, while user surveys are great for finding out what your user base thinks of your programs or products or what they’d like to see changed or added to your product mix, they can’t be used to project what people outside your user base thinks.
Appcelerator makes a platform for creating web based mobile apps and they have versions for iPhone, Android, and have promised future support for Blackberry. So, this limits the survey sample to mobile developers targeting one of the two platforms currently supported. It further limits the sample to web developers most likely wishing to support both platforms, and those who are willing to use the Titanium SDK instead of a more common technology like JQuery. And, of course, it limits the sample to developers who have some interest in the Appcelerator product line (a characteristic which I’m afraid is not universal) and have taken the action of visiting their web site.
Already we can see that huge groups of mobile developers have been excluded from the possible survey sample. If you’re going to eliminate developers working natively on a mobile platforms, developers working on platforms other than iOS and Android, developers devoted exclusively to one platform with no need for Titanium, Windows developers, etc etc – in short, every one except those interested in a specific framework for web development (Titanium) on one of two OS’s then you are surveying a very particular subgroup and you are NOT conducting a survey that can be projected onto the larger universe of mobile developers.
Another problem with this particular survey is that they offered entry into a drawing for an iPad as the incentive to complete the survey. In that way they biased their user survey towards developers who are interested in and who want an iPad. Bad practice, even for a user survey.
I guess we shouldn’t blame Appcelerator for this misleading report – after all they aren’t a market research company and may not know any better, though IDC should. My guess is this is just another marketing gimic to generate leads (they require your phone number for the download). We’ve seen more and more of that from IDC recently and that’s sad for those of us in the industry who take market research seriously.
The best news of the week last week came from IBM and their launch of a whole suite of new and improved tools addressing the engineering lifecycle of the growing number of interactions between the software, mechanical, and electrical components of a plethora of devices that have only just begun to populate our planet but that very soon will be ubiquitous.
Think about your car for example. Modern cars can have over 15 million lines of software code embedded in their mechanisms that make them respond to our needs without any interaction from us. There are sensors, and SOCs, and embedded systems throughout. Commercial trucking firms use sensors in tires that let them know when it’s the optimal time to change or replace them. Water utilities use software to embedded in devices to monitor and adjust water levels and flows to optimize a city’s water supply. All these things use software and all that software needs tools.
IBM has just released a stunning addition to the tools that are available for the increasingly common embedded systems that run our world. Expanding on the Rational and Telelogic lines, they have created a powerful toolset that enhances the software development lifecycle across the product development cycle with a new Rational Engineering Lifecycle Manager, Next Generation DOORS tool and Deployment Planning services. In addition, Rhapsody and RSA have been enhanced with Design Manager 4.0. In addition, IBM has whole suites of tools directed towards specific industries to extend the lifecycle from conception through implementation in specific industry applications.
For years IBM has been focused on the Smarter Planet and has been predicting the time when all of the objects in our lives will be “smart” enough to react to changes and conditions and to interact with us. That focus is now being paid off in spades – the future is within sight and its a lot like IBM’s Smarter Planet.
After measuring the demographics of software developers worldwide for fifteen years, we at Evans Data have a lot of solid trending data on who exactly developers are including their gender, education, experience, marital status and age. And while demographics have never been my personal favorite among the topics we cover (I much prefer technology adoption), I have to admit that recent changes in developers’ regional age profiles are very interesting.
What’s happening is that developers in the APAC region, who have been the youngest for years, are aging. There’s no surprise there as the software industry is new in Asia relative to other parts of the world, and all we’re seeing is the early adopters now becoming older. They’re still younger than other regions since there are still many new developers entering the field, but overall the profile is gaining some maturity. In the EMEA region, we still see a relatively youthful population because the population of developers is shifting towards Eastern European nations and Russia. Although the entire region is still relatively young, the western European developers are definitely aging.
But North America is a very cohesive and homogenous population and what’s remarkable is that in North America developers in the last couple of years have reversed their perennial aging and are actually getting younger!. This is significant because it demonstrates a basic change in the dynamic of the developer population. For most of the last fifteen years North American developers have been the oldest in the world. Software started in North America and practitioners have remained in the work force. North American developers continued to get older until 2008 when they reached a peak median age of 46 (the median age being the middle age where half are older and half are younger). Today, just two years later, the median age is 38.
So what happened? We can have two powerful forces at work in the last two years that would shape the developer population and predict this result. The first is the rise of social computing and applications and mobile apps. All of these are very fresh new paradigms which have a great appeal to younger people. There’s no longer a need to spend years in corporate America working your way up through the ranks to become a development manager. Quite the contrary, young developers can now develop and sell their own apps without the benefits of a formal distribution channel and they can develop programs that are geared for a younger audience. The other thing that happened was a large recession. In recession, the highest paid employees (unless they’re rock stars) are often let go first and that often equates to the oldest ones who have been in the firm the longest time getting small raises over the years until they’re now attractive layoff targets. They’re also the ones who can best be offered retirement buyouts. So we have lost a lot of older developers to recession while at the same time adding more youthful developers – anxious to make their mark in the exciting new world of social and/or mobile. That equals demographic shift.