State of Software Development: 2018 Open Research
This open research into the state of software development was performed December 1st to 20th 2018 under the title 2018 State of Software Development Survey. There was 162 respondents. The survey was announced my Twitter feed, and several LinkedIn discussion forums. |
The Survey Results
The aim of the survey was to explore how teams are approaching several important issues pertaining to software development. People were first asked if they were involved with a software development team and if so what was the dominant paradigm being followed. People who indicated they were following an agile, lean, or continuous delivery approach were asked several questions around how they were working that were applicable to those approaches. Those people, plus anyone who responded they were taking a serial/waterfall or ad-hoc approach were asked questions around team governance and who they are. For the sake of the discussion below, teams following an agile, lean, or continuous delivery (CD) appraoch will be referred to as “modern” teams.
Some findings include:
- Figure 1, summarizes the type of teams that people reported they were working on. It’s interesting that it’s pretty much an even split between project teams and long-standing (non-project) teams. This is across all types of teams. For modern teams, it was 54% long standing and 42% project teams.
- Teams following a modern approach on average spend 10.6 work days in initiation/Inception activities. 44% of teams spent 1 week or less doing so.
- Teams following a modern approach on average spend 6.3 work days to release into production. 63% of teams spend one day or less doing so.
- Figure 2 sumarizes responses to how long iterations/sprints are in practice. 87% of agile teams have iterations/sprints of two weeks or less. On average an iteration is 11 calendar days in length.
- On average, modern teams released internally every 9 calendar days and into production every 44 calendar days.
- Figure 3, summarizes how often modern teams release internally (into a testing or demo environment). 54% do so at least daily.
- Figure 4, summarizes how often modern teams release into produciton. 30% do so at least weekly, and 68% at least monthly.
Figure 1. The type of “software development” teams.
Figure 2. The length of iterations/sprints on agile teams.
Figure 3. How often do modern teams release internally?
Figure 4. How often do modern teams release into production?
Downloads
What You May Do With This Information
You may use this data as you see fit, but may not sell it in whole or in part. You may publish summaries of the findings, but if you do so you must reference the survey accordingly (include the name and the URL to this page). Feel free to contact me with questions. Better yet, if you publish, please let me know so I can link to your work.
Discussion of the Results
- 88% of respondents had 10 or more years of experience in IT, and over half had 20+ years. Everyone had at least 2 years IT experience.
- This survey suffers from the fundamental challenges faced by all surveys.
- I think the split between team types in Figure 1 is very interesting. It will be interesting to see how this trends over the next several years, I suspect that we’ll find a move away from project teams.
Links to Other Articles/Surveys
Why Share This Much Information?
I’m sharing the results, and in particular the source data, of my surveys for several reasons:
- Other people can do a much better job of analysis than I can. If they publish online, I am more than happy to include links to their articles/papers.
- Once I’ve published my column summarizing the data in DDJ, I really don’t have any reason not to share the information. Too many traditionalists out there like to use the “where’s the proof” question as an excuse not to adopt agile techniques. By providing some evidence that a wide range of organizations seem to be adopting these techniques maybe we can get them to rethink things a bit.
- I think that it’s a good thing to do and I invite others to do the same.