A brand new report from the Application Developers Alliance (and conducted by IDC) showcases some very encouraging news about the software development profession. A healthy 68% of today’s software developers have 5 or more years of experience, and 66% report they’re “energized” by their jobs. What’s exciting them? 44% said wearables and 38% said robotics.
Wondering where the tired, overworked, burned out developer is? Not here, apparently. “It is not surprising the vast majority of developers are gainfully employed freelancers by choice or at an organization by choice,” said Jake Ward, executive director and co-founder of the Application Developers Alliance. “It also doesn’t surprise us that the satisfaction level of professional coders is higher than the conventional wisdom might success. The reality is most working developers with 401ks and manageable commutes are happy to build really exciting products inside of a long term company.”
It’s no great revelation to hear that the favorite software development activity is coding – at 71% — but what might raise some eyebrows is that functional testing and bug tracking (traditionally what “testers” do) is popular with 62% of developers, roughly the same percentage as requirements and design at 61%.
And of course we all know it’s a mobile world. A hefty 87% of organizations where developers worked were involved in mobile development and 18% said they were pursuing a “mobile first” strategy.
What keeps developers up at night? Staying current with languages, frameworks and tools disturbed the slumber of 57%; other stressors included creating high quality code (43%), work/life balance (39%), overly demanding clients who “don’t get it” (37%) and finding work that utilizes a particular skill set (37%). If developers are stumped, they are overwhelmingly inclined to turn to the Internet for help (63%), showing an independent spirit, Ward said.
He is most encouraged, though, by the fact that a growing number of women are becoming developers. In fact, the percentage of brand new female developers hit 42% for the first time ever this year. “Our workforce is increasingly becoming egalitarian,” he said. “Developers are less and less male and it’s great to see that laid out and benchmarked.” Developers with one to five years of experience are 30% female, while the overall percentage of women in the profession is 25%.
Read the whole report for yourself, here (you’ll need to enter your email).
I’ve been talking to a lot of stressed out testers recently. These are people who take their profession seriously but don’t always think anyone else does, particularly when they’re told time and again that they need to learn how to code.
These aren’t folks who really want to be developers. As one said to me, “If I’d wanted to be a developer, I would have been. I want to be a tester.”
Is there a way for everyone to get along and get the job done? The answer might be found with mob programming, kind of like pair programming on steroids. Mob programming gathers 6 to 8 people in a room to work together to code, or perhaps even to test. Some, like Lisa Crispin, are calling it mob testing, and while she says she’s tried it, she’s not ready to talk about it yet. But Finland-based Maaret Pyhäjärvi, who calls herself a “collaborative software specialist with an emphasis on testing,” has tried mob testing and lived to tell about it.
On the one hand, she told me it brought her team together in a way she didn’t expect because they were all in a room together and you could actually see problem solving skills or time-saving shortcuts you had no idea existed before. The real advantage of mobbing, she said, is that no one had to explain anything because everyone experienced the same things.
That said, she did say it was difficult. Working in a mob “is a challenge when testers are not really programmers,” she explained. “They’re forced in to programming and my feeling is that some people are going to be more comfortable with that than others. This has the potential to be divisive.”
One of the challenges for testers is that you’re sitting close to the code and there’s a lot of “bored” downtime when the programmers are down in the code details. Testers are there showing support, but it can get tedious, she said. “I’m not certain if I enjoy this style of working in the long term,” she admitted. “For people with a testing background this can be very difficult for the first time because you’re really in to the code.” And she said the idea of taking a day and just working together can be a tough sell to management and developers as it can seem to be a waste of time.
Would mob testing/programming be the solution for your company? Let me know what you think!
The jaw-droppers came during an excellent (and packed!) talk given by Agile consultant Jutta Eckstein.
I am saving most of her talk to write about in more detail later, but she was speaking about the challenges of doing Agile in a distributed environment when teams (or parts of teams) are located in different places and/or different countries.
Ok, sure. We know that.
But did we know that there are actually other kinds of English than American or British or Australian? And that just because English is the international language of business doesn’t necessarily mean we’ll understand “Chinese English” or “Indian English”? And that you can actually take a class to become more familiar with some of these other versions of English? (And Ms. Eckstein makes a great case to do just that…she said native English speakers have told her they’re never worried about understanding English from non-native speakers until they hear it, and then many find it quite challenging. As she put it, “There are different Englishes out there.”)
Wow. Jaw dropped.
But she went further, to talk about how it can really pay off to research the country you’re working with, not in an icky, stereotyping way, but to understand general differences between cultures. She compared Germany and the US during her presentation using data from The Hofstede Center. This site is based on world famous research on cultural values and standards that make it easier to visualize differences between countries.
My jaw dropped, again, because it would never have occurred to me to look at a culture in this way simply to improve a multi-national work environment.
Great idea. We should all reach outside our comfort zones.
this is what I overheard on Day One of this very popular conference in Washington, D.C.:
“We submitted a paper and we heard back 20 days later. Normally you submit a paper and you hear back six months later and you’ve forgotten what you submitted. Here they’re even Aile in how they handle the conference.” – graduate student and speaker
“Ok, Agile failure already! They know how many women come to the Agile conference and they’re out of women’s t-shirts on the first morning? Really?” – Agile practitioner from a large technology company
“I have a really resistant team. They don’t want to change, or do any kind of project management. We’re making the same mistakes over and over again. Today I’m looking for little things I can bring back and suggest to them. We need work on team building.” – manager of a software development team that works primarily with the federal government
“At my company, I guess we’d be called “Scrum buts” because while our developers use agile principles, I admit the systems engineers, etc., work on requirements completely separately. They’re very resistant to change and I’m here looking for some ideas that might make it easier. It’s very hard to scale Agile at the enterprise level.” – manager of a software team that largely works with the Defense Department
“I really want to learn more about game theory and how it can be used to help make us more agile.” – Agile coach at a large technology company
“Any team of programmers, if given enough time, will justify a complete rewrite of the code.” – Luke Hohmann (paraphrasing a former colleage), Awesome Superproblems Keynote speaker
Get ready for new products, upgrades and features this week at Agile 2015. Here’s a brief round up of what you’ll see featured in booths at the show:
- ThoughtWorks’ Mingle Plus 2.0
Aimed at the enterprise-level Agile efforts, Mingle Plus 2.0 adds cross-project collaboration and program management to the core Mingle product. Developers can plan and track dependencies and the product is available on-site or in the cloud as a software as a service (SaaS) offering. Get more information.
A number of new features are available in VersionOne including TeamSync for Jira, unified DevOps automation, enterprise budgeting, TeamRoom Scorecards, and enhancements to the user interface, communities and CommitStream in TeamRooms. All four versions of the product – Team, Catalyst, Enterprise and Ultimate – are available now.
- Hansoft 9
This new version of Hansoft will provide developers with tighter integration of defect tracking, a new user interface, better contextualization, clear visuals and other collaborative tools. Also, the company will be giving “sneak peaks” of its newest product – codenamed Hansoft X – at its booth at Agile2015.
- QA Symphony
Designed for Agile testers, QA Symphony’s new qMap is a visual mapping solution that uses data from the company’s exploratory testing tool, qTest. qMap tracks and analyzes test results across systems and creates a “heat map” of the results.
And because no round up of Agile products is complete without some kind of game, PlanningPoker is a new (and free) digital card game that puts a fun spin on forecasting sprints and making estimations.
Is this your first time going to Agile2015? You’re not alone – it’s my first time too – but from what I understand this isn’t your mother’s tech conference.
So I asked Agile consultant and author Linda Rising, who’s speaking at the conference and is a veteran, for some advice for first-timers.
Don’t overthink it
If you’ve never been to an Agile conference, her best piece of advice is to just throw a dart (metaphorically of course) and go where it leads. Too much studying the schedule and planning out your time is kind of anti the whole Agile mindset, she said. “There is intense competition to speak here and all of the panels have been heavily vetted,” she explained. “You really can’t make a bad choice.”
Expand your horizons
Even if you’re a tester, don’t go to panels just about testing, she suggested. “Just go to one and then count on serendipity to get you where you need to be,” she said. The whole point of this conference of 2000 people is to have the “chance encounter” where you’ll learn something unexpected and meaningful.
Expect the unexpected
Because this is an Agile conference, it can seem a bit like a free for all to the uninitiated, she warned. But that’s kind of the point. “It’s in a big open space with people coming and going, someone’s coaching over there, someone’s joining a session late, someone’s leaving a session early,” she explained. “This is not a normal conference. Anybody can do anything and that’s kind of the idea.”
Get your game on
Games are a big part of the whole Agile experience so expect that in almost any session you attend there will be a period when a game is proposed. Part of the reason for that is to keep people engaged, Rising explained, and part of it is to tap in to our “right-brain creativity.” I’m not sure I have much/any right-brain creativity, but I guess I’ll find out soon enough.
You’ll want to download the app
Or, maybe you really shouldn’t download the conference app (here’s the link for the iphone version), Rising said. “All of that planning and scheduling – and an app – that just doesn’t seem very Agile to me. You should be agile and not over think this.”
Personally, I’m downloading the app (!) because I am paid to over think this. As for the rest of you newbies, I’d go with Linda’s advice.
Let me know if you’d like to meet up for an Agile chat – and I’d particularly like to meet other first timers.
Have you heard about the brand new hotel in Japan that is staffed exclusively by robots? If you’re lucky (and English-speaking), you’ll be welcomed at the front desk by a robotic dinosaur. Japanese speakers only get a humanoid robot, which is clearly their loss.
In this case, the move to automation may be a bit out there, but there’s a good business case to be made. Automation makes this hotel a bargain — guest rooms start at a mere $60, and top out at less than $160. And those robotic luggage handlers don’t need to be tipped.
So maybe it’s not so surprising to hear that enterprises, too, are pushing hard for automation, particularly in the testing arena.
But should they be? TechTarget contributors and testing consultants from Excelon Development — Matt Heusser and Justin Rohrman — met with me recently and this subject was on their minds. Apparently they’re getting a lot of calls from enterprises wanting to “automate the process.”
This isn’t a sign that enterprises are taking testing more seriously, Heusser said. It’s a sign they are in denial. “If you automate bad work, you’re going to end up with bad work done fast,” he said. “Automation is the meme of our age right now.”
The problem with the “let’s automate” bandwagon is that companies are treating the symptoms (testing is too slow) and not the underlying (and much more annoying) problems like the entire design process.
“In order to automate you have to look at what and how you are doing manually, first,” Heusser said. “You want to use automation to complement the human design efforts that work, not to replace them. The companies that have the most success with this think the entire process through and automate only where it makes sense.”
Think automation is the answer to your company’s problems? Or do you agree that the jump to automate might just make things more complicated? Or do you really just want to go to Japan?
I’m the new editor of SearchSoftwareQuality at TechTarget and I’d really like to hear what you think. I’m a veteran journalist who’s written about all kinds of technologies for more years than I’m comfortable admitting to and now I’m embracing software quality.
Email me and let me know what you think. Or what we should write about. Or your favorite thing about Japan.
The Boston Software Craftsmanship Meetup group met recently to play a couple of programming games. They were gracious enough to let me sit in as one of their own. The games were to demonstrate the value of pair programming and test-driven development (TDD). I already liked the idea of these techniques and after seeing them up close, I’m a big fan.
We started the night with a game of Pair Programming Musical Chairs. We split into pairs and got started on a simple problem using TDD. Then, at regular intervals a timer would go off and we would switch partners. One partner would stay with the code and the other partner would start in with a new partner on new code. Continued »
Red Hat Summit / Dev Nation 2015 fell pretty well in line with the theme everything old is new again. The three main themes repeated again and again were containers, DevOps and microservices. I think each of these three important trends is building on a well-established base of solid practice and technology. Continued »
For a journalist, an all-night hackathon can be a pretty intimidating undertaking. I was sure I’d be way over my head sitting with professional programmers as we built and programmed as Raspberry Pi at the Hack ‘Til Tomorrow: Hands-On IoT Hacknight event as part of Red Hat’s DevNation conference last night. I wasn’t completely wrong, but it was much easier to muddle through than I thought it would be. I learned a lot, gained a fair deal of confidence and even made new friends. Continued »