The latest expert opinions, articles, and guides for the Java professional.
Part 1: You and the Data
Show me the Data!
We’re all geeks here and we all love to get our hands dirty in raw data. The good news is, you’re reading the right report! In this section we’ll show you the raw data in graphical form and describe what we can see with a good dose of opinion thrown in. As we described earlier, there will be no pivoting or comparisons at this stage, but be patient, we’ll get to that in the later parts of the report.
We start by profiling the people who filled out the survey, then the application, the organization they work with, the processes they follow… Ok breathe… then the tools they use, the kinds of issues they see, the issues that are fixed… still with me? Almost there… what kind of impact they have and how successful their testing is. Phew, we made it! It sounds like a lot to get through, so grab a coffee/tea/beer/water/drink of choice and let’s get started!
The respondent, aka you!
As we’d expect, the vast majority of those who responded to our survey labeled themselves software developers, as shown in figure 1.1. A further 27% sit in the Architect/Team Lead/Project Manager category. This constitutes well over 90% of those who responded, so we can rest assured that we’re talking to the techies! Interestingly, only 1.54% of those who responded were dedicated performance engineers, which either means there are very few performance engineers out there, or that perhaps we didn’t penetrate that specific market with the survey. It’s often difficult to get a survey out to an audience without experiencing bias, and this could be a result of bias from our market reach.
As you’d expect, the vast majority of applications are going to be web applications, shown in figure 1.2 as taking over 70% of the audience. Desktop applications come in at a little over 11% with batch and mobile at just over 6% and 3.5% respectively. In the “Other” column, respondents mentioned other applications such as middleware or application servers. So we can now picture our typical respondent as a software developer who develops a web application. Should we name him/her? How about Sam? Actually, it’s probably better in the long run that we don’t get too attached to them, so we’ll continue calling them the respondent.
Another facet of an application which is extremely important to understand is its complexity. The graph in figure 1.3 displays how many screens or views the applications have. This will give us a very rough guide as to how complex and large an application is. OK, it’s not ideal, but it’s the best and simplest question we could think of which showed us size and complexity without individual opinion or bias. You’ll notice that the majority lay between 10-100, with over 55% of respondents going with that option. The average number of screens is 118.
Let’s find out where our average respondent works. w We can start to understand the average organization a little better by understanding how big the teams that develop, test and support the application are. Figure 1.4 shows the distribution of people working on their application from design and development through to deployment and support. The average is 21.27 people. Remember, this is the arithmetic mean. There isn’t 0.27 of a person trying their best to develop an application using two of their available fingers and 3 toes on their one good leg! With over half of our respondents (55%) stating they work for a team of less than 9 people and 83% of respondents stating they work in a team of less than 25, it’s safe to say that the teams are mostly small. There will always be outliers which pull the average up as organizations turn enterprise, but these are the minority cases for this survey.
Next, we turn to responsibility. We can see straight away from figure 1.5 that as far as responsibility goes, the clear winner sits with the development teams. The data shows that at just over 55%, the most likely person to be responsible for performance testing is whoever wrote that piece of code. This could be for a couple of reasons. Perhaps we really do live in an agile world and the engineer who develops the code fully tests it – functionally, as well as for performance. Another possibility is that there isn’t any process at all. This would mean that performance testing is just dumped on the poor developer who has little support or knowledge about performance testing, so ultimately ignores it. While we all wish that would not be the case, it does creep into mind. Operations, Performance Teams and QA take up similar slices, as well as the answer ”Nobody” at around 11-14%.
The eagle-eyed among you will have seen that our numbers don’t add up to 100% in figure 1.5. Well, you’re right, but the reason is due to the question being multiple choice rather than a n00b and rookie Excel oversight. We now want to see how many respondents state that there are multiple groups responsible for performance. It turns out that often multiple teams are responsible, as shown in figure 1.6. While just over half of the respondents state they’re only one team responsible for performance – the other half state two or more teams share responsibility for it. In fact, the average shows that 1.71 teams will be responsible for performance testing, with the majority of those who state responsibility is shared, doing it across two to three teams.
No comments yet.
Leave a comment