It’s 3pm. Do you know where you dev team is?
Using data from over 1000 respondents in a still-in-progess (cough, cough) survey about what makes developers tick, we are trying to hack into the core of the developer work week.
(FYI - Part 2 – Developer Stress, was released February 7th and features commentary from Diabolical Developer Martijn Verburg, so check that one out too!)
Among lots of other information that we unearthed from the depths of the coding den, we wanted to introduce these 3 interesting findings, and get some running commentary from Lincoln Baxter III, Senior Software Engineer at Red Hat (JBoss Forge), founder of OCPsoft, and opensource author / advocate / speaker:
- Finding #1: Devs spend less time writing code than you might think. The median is 15 hours, programmers spend about 3 hours each work day writing code.
- Finding #2: Devs spend more time on non-development activities than you might think. For each coding hour, devs spend nearly 30min in meetings, reporting, writing emails and dealing with timesheets (7 hours to 15 hours)
- Finding #3: Devs spend more time fighting fires than building solutions
Disclaimer: As with any type of research undertaking, here are a couple of disclaimers: a) This survey is still in progress, and these findings are only preliminary at this point. b) We asked respondents to estimate the time they spend doing activities, so 100% accuracy is not guaranteed. c) Not only developers responded, but also architects, QA folks and system admins, so averages may reflect this too.
How do Developers spend their work week?
Check out this breakdown of what devs spend their time doing (the top 3 time-consuming activities are marked):
Here are a breakdown of the categories a bit more. We tried to get everything a dev might do during the week, so if you can think of anything we missed, it would be cool to hear about that.
- Writing Code (programming, coding, hacking away)
- Overhead (Building, Deploying, Hardware, Software)
- Communication (Meetings, Chats, Teleconferences, etc)
- Problem-Solving (Debugging, Profiling, Performance Tuning)
- Firefighting (Crashes, Slowdowns, Security, etc)
- QA (Manual & Automatic Testing, Code Reviews)
- Strategy (Architecture, Refactoring, Thinking)
- Process (Bureaucracy, Reporting, Time-keeping, etc)
- Procrastination (slashdot.org, reddit.com,. Twitter, Facebook)
We can see that actually writing code is still the dominant activity of the day, but by no means a majority by itself. There is a distinction between “writing code” and “coding”; “Coding” includes writing code + problem solving, QA, strategy etc.
If we assume a 45-hour work week (9 hours per day, incl. lunch and breaks), developers spend 1/3 of their entire work week producing code.
Is this considered too little, just right or even too much? Let us know what you think in the survey, give your comments below and check out our Extended Interview with Lincoln Baxter III below.
**Next up :: Developer Productivity Report – Part 2: Developer Stress**
Extended Interview with Guest Geek Lincoln Baxter III
ZT: Hey Lincoln, thanks for joining us.
LB3: Glad to be here.
ZT: Can I ask….does it say “The Third” on your passport?
LB3: No, just the Roman Numerals.
ZT: Darn. Anyway, what do you think about Finding #1: Devs spend less time writing code than you think? I mean, according to this, devs spend less than 3 hours each work day writing code?
LB3: To be perfectly honest – and I’m always perfectly honest – I’m not surprised one bit. The biggest drain on productivity is the constant interruptions to our concentration; that can be co-workers, running a build, running tests to check your work, meetings.
It can take up to 25 minutes to regain your focus once you’ve been distracted from your original task#, and if like me, you consider “writing code” to be the task that developers should be focus on, then the size of other pieces in your pie chart begin to make a lot of sense.
Think of a brain as if it were a computer. There is waste every time a computer shifts from one activity to another (called a context switch,) a very expensive operation. But computers are better at this than we are because once the switch is complete they can immediately resume where they left off; we are not so efficient.
When considering context switching, builds and everything else considered “Overhead” are the biggest distractions from writing code. Even though this piece of the pie is only responsible for 4.63 hours of a developer’s week, in reality, the true impact of this problem is much greater.
Once you add in all of the other distractions of the workplace, I’m impressed anyone gets work done at all. Every re-deployment is going to cost you an extra 25 minutes of wasted focus, in addition to the deployment cost itself.
ZT: Alright, on to Finding #2: Devs spend more time on non-development activities than you might think. Based on these numbers, for every 1 hour devs spend writing code, they spend over 30 minutes in meetings, reporting, writing emails and dealing with timesheets (8.25 hours to 14.75 hours). Has it always been like this, or is this something new coming as more IT shops join forces with large enterprise and corporate parents?
LB3: In a desperate attempt to measure and estimate the work that programmers do, we try more and stranger ways to try to gain some kind of understanding. Think about it – in every other type of engineering field, we perform estimates up front, send out quotes, sign a contract, and work follows.
When writing software, however, try as we might, we still have difficulty with this process. Why? Because writing software today has very little to do with engineering.
The cognitive requirements for programming (software engineering) are much more akin to those of composing music, or painting a picture than they are to building a bridge or installing a drainage culvert. The common misconception about us “geeks” is that we are boring, uncreative and dull, but if that’s true then Mozart, Beethoven, and Daft Punk are just as dull.
So why do we insist on measuring software development as if it were an engineering science? We can apply these statistics to bridge building because we have built bridges for thousands of years, and the laws of physics have not changed since then. The laws of computing, however, change daily, and we cannot possibly hope to measure the same way.
This is why the Agile software methodology has had so much success, because unlike when building a bridge, the type and amount of work changes frequently in software development. Agile focuses less on measuring how much work on a task has been completed, but instead how much work remains, and how that relates to how much work can be done during the project timeline.
In fact, at OCPsoft we’re working on a new open-source agile project management called SocialPM, which is being designed specifically for the purpose of creating as few distractions as are necessary, while helping teams stay organized and keep more accurate schedules in an environment prone to change. (You know, to keep managers happy.)
Traditional estimation techniques, they’ve got no hope until we have more standard practices for software development. Let’s give our guys a break eh? Stop with the time-sheets.
ZT: Cool. Ok, so now to our last finding. Finding #3: Devs spend more time fixing problems than creating solutions. Let’s pretend the non-coding, non-communicating part of the dev day could be split into two parts–Firefighting and Building. Firefighting includes emergencies plus problem solving like debugging and performance tuning. Building includes code reviews and tests, plus strategic planning, daydreaming, refactoring and thinking over architecture.If we break down the work day into parts where devs are spending time actively solving problems or working towards creating solutions, devs spend more time putting out fires.
- Firefighting – Median 7 hours per week
- Building – Median 6 hours per week
If we use science, we can see that Firefighting consumes 16% more time per week than Building. What can you see from this?
LB3: To be quite frank, we’re all lazy, and not nearly as smart as we think we are. With the level of complexity in today’s software steadily on the rise, with layers upon layers of software depending on software, there’s no hope for us to understand every possible condition or scenario, and thus there is a huge lack of real testing in our field.
- #1 – Writing a test.
- #2 – Running that test.
We have hugely complex builds that are not properly modularized, and certainly not very testable because how can you test without a database? How can you test without real business logic?If you don’t have automated builds and automated test suites that run in a reasonable amount of time (a few seconds or minutes,) then you are going to spend a good amount of your time running builds and trying to write and run tests; not to mention, you may not see the real issue until you deploy the software to a production environment, because mocks can never hope to replicate a real system.
In terms of Java, we’re seeing new advances in the field of testing – namely a project from JBoss called Arquillian, which allows us to automate the deployment of real tests to a real environment in which all services are available. The fact that you have access to your database, business services, and more is why “Don’t mock me,” is the Arquillian slogan.
If there’s one thing that surprises me about this statistic, it’s that we don’t spend more time fighting fires, because without a good automated build and a solid suite of real tests, we’re going to have problems.