Programmer by day tester by night - what do I really mean by that? Well, having looked at the presentations that came before me, I think there is a very logical connection to what some of the people that are working on testing we're seeing like Maurício and Manuel, but also to what Igor was just saying about estimation, so let's dive into the kitchen, because, actually, well if my slides would move... I actually like to use the kitchen as a parallel universe to the programming universe that we're typically working in as developers. So personally, I really love cooking, and I like to make intricate dishes and - and put them on the table, but as you can imagine, this part of the work in the kitchen I don't typically like that much. And I think a lot of people would agree with me, that this is really what you try to delay as much as possible, and well maybe you have a dishwasher, and it's not too bad, but, well it's definitely not my favorite part of the job. So if I were to ask you, how much time does making this beautiful dish really cost, and maybe somebody would say 30 minutes, and if I were to ask how much time you would spend on doing the dishes, that would probably be considerably longer than it takes you to cook. So from that point of view, there is a message coming in so i'm just going to see whether that's something for me... No... So from that perspective, we've been looking at how people perceive the time taken to do tasks that you enjoy, versus tasks that you might not enjoy so much. There's actually a term for that that's chronoception but also it's - it's kind of the shortened form of the chrono-perception the time it takes to do something.
And what we were really wondering in the studies that we've done is, how do people look at software testing, and how much time are they spending on software testing. So my slides move - we actually did - we created a tool a plug-in for some popular development environments. We unleashed that on 2442 developers from many countries, but the key thing is that by having this tool installed for several months, we were able to collect 150 person-years of development during the study. So this gives us a broad basis to really look at how people are doing testing. Now, during the installation we had this fancy wizard and we were asking people, do you do testing, do you do that in the IDE, do you do other types of testing, any other opinions that people might have on testing. So one of the key questions was how much time do you think you're spending time on engineering test code versus engineering what we call production code in the IDE. And the answers - the average answer over all the 2443 developers that installed the tool was about 50-50. So 49.5 percent of their time was spent on engineering test code and 50.5 percent was spent on engineering production code. Now there is something really strange going on here, because there is this really famous book - The Mythical Man Month from Frederick Brooks - and in that book it's written that testing takes approximately 50 percent of our time. So it's actually very strange that the book from - that was published at the end of the 1970s - actually premonitioned the results of this first question in our study. So maybe there is actually some folklore going on in our profession.
Now the key question obviously is that after observing these developers, after minimally five months and potentially even two years or more, what would be the answer? How much time would actually be spent on engineering test code? That is dramatically different from the estimations. One quarter of their time - of these developers - was spent on engineering test code in the IDE and 75 percent was spent on engineering the production code. Why is that? Well, these remain assumptions, but the fact that software testing is really a destructive activity, while engineering production code is actually something that you bring to life, something that you probably enjoy more, just like the cooking versus doing the dishes, could be a reason here why people overestimate their testing efforts.
But there is more to this study because we also looked at how people do test driven development, and this really touches upon what Davide was telling a few presentations before. So I think we all know what test driven development is - it's the core idea that you write your tests first and then implement parts of the production code so that your tests pass. And this really requires this cycle where you have a failing test, you make it pass, your refactor, and you continue doing that. So from the 574 developers, which is like just under 20 percent of the developers in our study, that claimed to do TDD, there were actually only 47 that really did TDD. Now you can say, well, maybe they did it outside of the observation - observation period, that could all well be, but I think the key message here is that a lot of people think they do it, but in practice they don't do it that often. Because even for those developers that we did observe that they were doing TDD they only did it in very specific cases, probably because it's not that easy to do.
So what does that really bring us to? Well, the first takeaway is what developers think they do or they estimate their efforts on, is typically not what they really do in practice. So the chronoception of software engineering tasks is really something that we need to be careful for. And secondly, maybe a plea is that we need to understand software engineering tasks better: how we do it, and also the effort that it takes to do them. And we need to have better tools to estimate how much time does it take to test, how much time does it really take to implement the feature. So my plea here is really to also use software analytics during developments to better understand what you and your team are doing and also create more reliable estimations.
So finally the two takeaways of my talk: the chrono perception - take into account that certain things take more or less time depending on certain factors in your personality. And a general plea to do more software analytics to become a better programmer. Thanks.