I know, I know, there's no such thing as a typical day, but I'm looking for averages. I've posted this discussion to many groups & have gotten an extraordinary response to it.
I've asked permission from the responders to use their comments in the article, but I feel that any paraphrasing I'd do would not preserve the character & helpful attitudes of the respondents, so I'm going to include the entire discussions from all the groups. Even though my comments in several of the groups are the same, I'm going to include them also to preserve the flow of the discussions.
The C++ Professionals Group contributed this:
Comments (30)
Let's say that "average" programmer usually able to write new code up to 6 hours a day, but after few weeks of such intensive work , productivity drops down... It is good time to give him few old bugs to fix or some new technology to learn... BTW, "bad" programmer will write code up to 8 hours a day and you will need add some more hours for rewriting or removing all his "products".
Thanks Michael. That agrees with my own experience. I'm wondering if there is a knowledge base out there with a large set of data on programming efficiency. Otherwise I'll be relying on the sample I get from responses such as yours. I've posted this discussion to multiple groups in hopes of increasing my sample size. I also agree on the burnout syndrome. We try to break up the monotony, but after a while even the switch to bug fixes gets old.
I would say, 4 to 5 hours in write code and up to 2 hours in requirement gathering/analysis/learning & design and 1 ~ 2 hours for phone calls / meetings in a day.
Thanks Mohammed, that means you are spending 6-7 hours/day in development work & 1-2 hours/day doing other things. Do you usually work an 8 hour day? If you do, could I average your hours to 6.5 hours/day spent doing development & 1.5 hours/day doing other things?
I concur with the previous responses of about 5 hours "coding" time per day max over time; you can push it higher for short periods. For more info, you m ay want to see if the Software Engineering Institute at Carnegie Mellon University (http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Esei%2Ecmu%2Eedu%2F&urlhash=5Uce&_t=tracking_disc ) has that sort of data. Good luck.
Thanks Steve. Good idea, I'll ask my contacts at SEI if they have data they can share.
John Phillips
Research Professional
McConnell's "Code Complete" has a lot of study references on this sort of thing, but generally I think they run close to where you are seeing already.
John
Amount of time spent coding in an 8 hour day isn't a necessarily a measure of efficiency, though, is it? It seems to be more a measure of activity or "busyness". It depends on how much you get done in the hours you spend coding. What takes some programmers 8 hours might take others only 1 hour.
What would be more valuable, IMO, would be some kind of velocity measurement, like the number of user stories (or requirements or use cases) implemented in X amount of hours.
Dan Hestand
Lead Software Systems Engineer at The MITRE Corporation
I'm going to go out on a limb and say that the answer depends on how you define 'programming.' If you mean the physical act of sitting in front of a screen pounding out code, then I suspect the answer is probably around 50% of a given day but can vary from day to day and probably averages out to 30% over a year's time. If instead, you mean the act of creating software, which includes meetings, requirements, documenting things, doing research, unit testing, debugging, talking to colleagues (on relevant things), answering emails, actual code writing, and even just sitting back with eyes closed working through solutions mentally, then I would suggest that the percentage is probably higher, say around 75-80% of most days and probably varies little from day to day.
COCOMO and other estimation methods assumed an average programmer could produce ~15 lines of executable code/day (at least several years back that was the assumption). Agile methods may actually deliver more but there is also non-coding overhead involved in those methods, too. I can manually write over 1000 lines/day but some days I may also rip out more than that and other days I may write nothing at all. Add the effect of massive amounts of code that can be automatically generated and the perceived productivity can vary widely depending on exactly what I'm doing. So I think the real answer lies in what your view of 'programming' consists.
Stanislaw Bartkowski
Software developer at IBM
As far as I know it is expected that tester spends 4 hours a day executing tests and this number is taken to plan and measure testing efficiency. The next 4 hours he/she spends talking, discussing, writing test cases, reviewing, verifying fixes etc.
With respect to developers this time is like 5/6 hours, meaning pure coding.
But as Dan noticed it depends heavily what you define by "testing" or "developing / programming".
Based on my personal experience it varies. Sometimes you are coding like a mad writing hundreds of lines of code but one has to remember it was preceded by days/weeks/months researching, analyzing, reading, discussing, designing, making proof of concepts etc.
Thanks all. I include requirements gathering & elucidation, design, coding, unit testing, code review, etc... all as part of the development time. For testers, I would include all the time spent on writing test cases, reviewing, verifying fixes etc.. & any discussion related to the tests the tester is working on. I'm not sure the software product makes that much difference to the percentage of time an average developer spends in development as opposed to non task related meetings, extraneous phone calls & e-mails, lost time due to interruptions, etc... Even defining programming broadly, I'm still getting responses indicating 6-6.5 hrs out of 8 seems to be the norm. I'm not making any judgements about this, I think that unless you get deep into the creative process & lose track of time, any development after the 75% mark may not be productive in any case.
William J Robblee
Owner at Asea Software LLC
My two cents. I like the estimate of 4-6 actual hours spent developing, exclusive of the aura of mundane tasks that go with coding, requirements, docs, test/debug, etc.. But the issue of efficiency depends on the task. Some days the code just seems to pour out and others in takes hours to get a small bit of code developed.
If I were a PM, I'd also take into account the state of the code after the day's work. Has it been vetted with a battery of automated unit tests, or merely "thrown over the wall" at the testing team? If the latter, it will likely require more work than if it was the former.
I'd like to add one other possible consideration. Sometimes the average may depend on position/role. Consider your generic "contractor" role - in some cases they are expected to simply sit and pound out code all day long. They are given a design and have to implement/test it. Their "other" tasks are greatly minimized. If you compare that to say a senior level programmer/analyst employee of the company, then they may have a lot more distractions that are part of their role. Reports to management, reviews for junior designers, code reviews for your contractors, etc.
In addition, I'd reconsider your 8 hour day. Once again, that may be appropriate for some roles, but, personally, a 9 hour day seems more realistic.
Some experts estimate that if a developer predicts that the job will take X days, you should double it, because the developer is assuming they will actually get to work the full X days, without interruption. I recommend "Peopleware" by DeMarco and Lister, and "The Mythical Man Month" by Brooks.
I can easily sit and code-test-debug for 40 hours a week for months indefinitely without burn out. That's because I enjoy it. For 2 to 3 months I can manage 50 hours a week. I'll refuse to even try more than 50. On the other hand, I consider myself lucky to be allowed to spend 30% of my time on the fun stuff.
I like your point about " I think that unless you get deep into the creative process & lose track of time ..." but I'd finish the sentence with "... it isn't really programming" or maybe "... it just isn't fun any more". :) My idea of a good day on the job is one where I am surprised to find out it is time to go home.
In India,with my experience i would rather say, It highly depends on company size (how big the company is in all respect). I stared with small level Indian IT company, where I used to write 8-10 hours coding and there unit testing was not that much inp.There I had never written any unit test stubs for my code. I never checked code coverage. Only if the testers finds any functional bug, then I had to fix that. So, bug fixing (re-writing code) was also very minimum.
But when I moved into kyocera, there I had to write code for about 5-6 hours daily,Including Unit test stubs. If I divide the entire time frame of development, it would come 30% for implementing feature, 40 -50 % covering negative scenarios and rest on writing Unit test stubs.
Hmmm. If you are looking for averages, you have to be specific about the length of time you are looking at. I agree with some of the others where there are days where you are cranking out code all day long and then there are days you never even enter the editor.
Just to throw another consideration into the mix. Imagine a company who wants to cut costs as much as possible, so they cut staff and pile additional responsibilities on the remaining few. For example, instead of just being a developer, you now have a full time job of being the QA department as well. (And no, I am not talking about the debugging you do on your own code.) Writing test plans, executing them, documenting the success or failure. Now throw on that maybe having to be part of a help desk and take problem calls. Throw on that maybe having to troubleshoot the network, be a DBA and a sysadmin, and document your progress for management. Now consider that many people still consider multi-tasking a good way to run things, so lets say you have multiple projects to manage/develop at the same time. Throw on that deadlines based on whimsy and not resources.
Days will become longer. . . productivity less. . .
A quick look at job postings will prove out my "fictional" company. Too many companies are looking for Superman because they don't want to pay for Clark, Lois and Jimmy. IT seems to be going in a direction that will ultimately produce burnout and less productivity.
Does this sound familiar or am I imagining things?
It does sound familiar. In fact, I think it's more the norm than the exception.
Dan Hestand
Lead Software Systems Engineer at The MITRE Corporation
It's interesting to me that while there is advocacy for "doing software right," there is little actual movement towards that in many organizations. I often wonder if the notion of time-to-market is part of the problem. I perceive that there are times when we (collective we) are told that if we don't hit the market at such and such a time, then we will have missed the window of opportunity. But if we hit that window with crap, then the window of opportunity might as well have not existed.
I agree with just about everything said so far. When I'm "in the zone", I can go for weeks pounding out code 12 hours a day (I usually work 12-15 hours/day anyway) and then have an entire week where I may not use the computer for anything other than web-surfing (research) and keeping up with emails. It doesn't mean I'm less productive, it's just that I'm productive in a different way.
One other thought on this topic; the efficiency of any developer is also highly dependent upon how confident that person is in their abilities and how closely aligned the task is with the person's abilities. Inefficiencies can arise because a developer may be working on something that they are not entirely comfortable with and will thus spend more time asking questions and trying to get some increase in confidence. These inefficiencies are natural since no single developer knows everything. They should however, be accounted for when planning and scheduling.
Comments (4)
Alec Clews
Experienced IT consultant focused on improving software process for agile business delivery
It depends on the individual and the circumstances. In my experience it can vary between 30 mins and 6 hours. I would suggest (simplistically) that the major factors are:
* Is there actually appropriate coding work to do? Are other tasks more relevant currently?
* Is there energy to do it?
* Are there the process and self discipline to be productive? (internal issues)
* Does the developer have the skills, support and tools to be productive? (external factors)
Notice that I use the world developer, not programmer. A developer does more than cut code all day -- and all 'programmers' should in fact be developers.
Thanks Alex, I include requirements gathering & ellucidation, design, coding, unit testing, code review, & research devoted to the task, etc... all as programming time. In my experience this comes to ~ 6 out of 8 hours per day on average.Do you do Scrum? If so, would you consider the 5 minute daily scrum as programming time or other?
longer term planning for larger projects generally assume 70% effective availability - 5.6 hours per day
Thanks Gary, I've attended a few of your webinars, especially on Scrum & agile & have gotten good information from all of them. I've posted this question to multiple groups & have gotten consensus for 70 - 80 percent of time devoted to development activities. I plan on posting an article on this topic since it has spawned large discussions in several groups. With Alec's & your permission, I may use some of this discussion in the article. Proper accreditation will be given to all.
Comments (5)
This depends a lot on the type of organization you're working for. In general it's always about getting the requirements and breaking them down into manageable parts. I think this takes up most of the time in the form of meetings and developing design documents. If the development team is using the same tools and libraries over and over again the coding process is probably streamlined and less complicated.
After the design phase of a project I can get about 7 hours of coding in, but I like working overtime because it's quiet after business hours so, it really doesn't matter.
Thanks James, I include requirements gathering & ellucidation, design, unit testing, code review, etc... all as part of the development time. The other time would be for non task related e-mail, phone calls, non task related meetings ( e.g. HR briefings, birthday celebrations, etc..), & any time not spent on task related activities. If your 7 hours is part of a day in which you work overtime, you probably still fit the 6-6.5 out of 8 hours which is the most common response.
There was a study published a few years back (can't remember where) that found that on average programmers only spend 35% of their time actually writing code. This is probably averaged between peak productivity times and design/roll out phases where little coding is being done.
Thanks David & James, you & all the responders in other groups have given me great food for thought. I'm going to post an article on this topic & I'd like permission ot use some of this discussion in it. I will of course give credit to every one who has been a contributor to this discussion.
Rakesh Sharma
Senior Software Engineer at Aricent
It depends a lot on type of work division, Like If all team members who are working in that project are working under same roof then probably the meeting and discussion time is less and if some are sitting at one office and other are at over-seas office, then alot of effort is consumed in telephonic and desktop sharing meetings.
Apart from this there are almost 40% of time in whole week wasted in e-mail, phone calls, non task related meetings ( e.g. HR briefings, birthday celebrations, etc..),
Comments (21)
You need to specify what type of programmers. Are these programmers doing work for clients or are they doing internal projects? Are they developing custom client applications or are they working on proprietary SaaS applications? What is the average size of hte project they are working on? How many other projects are in the project queue? Are they working as a team or individually? Is it new development of updates? If updates, is it updates to their own work or someone else's? How well documented is it? What technology is being used? How responsive is the client if it is client development?
These variables all make a huge difference in programmer productivity. I think it would be best if you described a detailed scenario or you won't get any accurate answers.
Wow. Thanks Dustin.
We develop shrink wrapped software in support of residential & light commercial component construction. We have both internal ( our Engineering Department) & external ( component manufacturing) customers. We have CAD, Engineering, Database & Production elements to the software.
Most developers are involved in both maintenance & new development projects, most of which include Input, Engineering, Database & Output specialists. The program is highly interactive & graphic. There is extensive user documentation, & many specifications documents. There's not much internal program documentation. We have a mix of very experienced programmers & newbies, ss well as a mix of new & legacy code.
We're mostly C++, but C# is a growing part of the program. The database has migrated from proprietary to Access to SQL Server.
Requests for changes to the program are usually sales & customer driven unless Building Code or Industry Standards change, which results in Engineering Department driven changes.
We have a huge backlog of both large & medium projects & smaller customer requests. So for developers, there's little or no down time.
I include requirements gathering & elucidation, design, testing, etc... all as part of the development time, not just coding, so I'm not sure the software product makes that much difference to the percentage of time an average developer spends in development as opposed to meetings, extraneous phone calls, lost time due to interruptions & such.
I find that client software development may require more hours than 8 hrs per day, but I'm not sure the percentage of time spent in development as opposed to other things is all that different for different kinds of software development. I could be wrong on that because I've worked mostly in Software Applications Development for the last 30+ years.
This is an impossible question because it really varies with the phase of the project. I would also say that the more time programmers get clear on what they are doing up front, the faster the actual programming and the less time it takes.
I think some people who have been around the computer industry for awhile may tend to think of the efficiencies of new languages such as C# as sort of magic. It isn't. First comes efficiency from not dealing with C++ things like memory allocation but the real efficiency comes from the large framework of objects that are there to use. Lego blocks if you will that need only be stuck together and not carved from scratch. The next efficiency comes from internal object reuse, objects created that solve a common problem in your enterprise and can extend the framework for further reuse.
This efficiency comes from knowing what is in that bag of already made lego blocks (objects) and time to define the new ones for your own business and document them well enough to be reused.
Code does not have to be documented the same way as in the old days. If there are good code standards followed then the code really can be self documenting to some degree. The test though is whether a developer of equal skill can pick up code someone else wrote and really comprehend it. I think documentation then shifts from flows to relationships more.
Efficiency is lost when there are changes that were not expected. This is especially unfortunate when they could have been expected, just nobody troubled themselves to think it through first.
I find that having an uninterrupted run to actually write code is important. It takes focus and thought and interruptions can force the developer to start the thought process again. An interrupt of a minute can have an effect of ten or twenty minutes for this reason. Also, I find I cause more bugs in relation to interrupts, something I forgot yet proceeded anyway.
What is really key is that the organization itself has to have the discipline to get the most efficiency from its developers. This means working the plan thoroughly in advance, providing the developers with a "clean well lighted place", not interrupting them when questions and insights can be stacked up for later and so forth.
Back to the original point, a great deal has to do with the project phase.
I concur whole heartedly with what Geoff is saying and would like to emphasize how important it is for the enterprise to extract the maximum from it's dev teams. In smaller "SWAT"-type teams where the architect/designer/developer takes care of the whole development process all the way from specification to installation, training and first-line support the development time for such teams are radically different from a team that only has software as an output. Once you add client support and context switching between multiple projects on a day one can find pure development time gets lost fast
Thanks all. I had forgotten the loss of time due to context switching. It's worse than interruptions because it affects 2 tasks instead of just one. I still feel that ~ 75% of a developer's time is spent in development, including requirements gathering, research, design, coding, unit testing, code review, etc... & the other 25% is spent in non task related activities. I've posted this to many groups & most of the responses fall close to this range for developers who are not wearing other hats. For the rest of us, the more responsibility you have, the less time is spent in pure development.
I would be interested to know what the ratio would be between "pure" devs and "multiple-hat-wearing" devs ..... I would think the ratio is slowly but surely edging upwards for the latter ...
Sam, this is also very true. I think there is a tendency to hire less competent and therefore presumably less competent developers. There is a cost for having developers in that they all to some extent have to intercommunicate. If there are too many finding their way or trying to understand, this becomes a drag on efficiency. Better to have fewer but really good and driven ones.
Ray,
Have you considered using agile within your development environment? I used to be rather skeptical about the agile/scrum process, but I am now a believer mainly because if it is implemented correctly, it puts a lot of requirements on the team as a whole and the team themselves deal with the productivity issues to ensure that they can meet their iteration goals, thus being efficient.
Note that efficiency doesn't necessarily mean that you pump out good code in the shortest amount of time. In some instances, you might be more efficient by spending more time on testing than coding, depending on where you're at in your development cycle. Agile should also compensate for your junior developers. (I prefer to use the term "junior" instead of "incompetent" because many of these developers don't know any better, whether they realize or not. Granted, there are incompetent developers, but these are the ones who should know better and don't which is what makes them incompetent.)
As @Ray mentioned, agile methods can increase productivity enormously. We practice Pair Programming and have done so for several years. I can confidently say that we get as close as is probably possible to 8 hours of pure programming per day. The developers work as a team on their tasks for the sprint and by working together (same workstation) they stay focused on the end goal. We also strictly limit developers to one project at a time to avoid any context switching cost.
Also I second the comment from @Geoff that great developers are the best. The productivity of a great developer can be 2-3x or more than a regular developer.
Agile means absolutely nothing at all if the organizations is not signed up to it (or whatever other process you choose). I am not skeptical about the agile process but it's cult like and modern buzz word nature helps to drive organizational development.
I believe that if any process is followed well and fully by the surrounding organization, it will work. There is much about Agile that is better but this fundamental need for the organization to not look as programmers as a bunch of people who do stuff that is the most crucial.
In my consulting practice I have also seen many organizations that will tell you that they are all doing agile but they confuse this with not planning or being flexible which it is not. So when someone tells me "we are agile" ... I have questions and I'm looking for a process definition.
Junior people are often not incompetent. Incompetent is a different word and I use it as it applies. Senior people can be incompetent.
Yes Jonathan ... in addition to the 2-3x more productive is the fact that a great developer though commanding the higher salary uses the same floor space, health insurance, computer equipment and other overhead as much as one that is a drag on the team. The business efficiencies are greater still.
Nothing is worse than sitting through a meeting where people who have no clue are going round and round about things that are not productive. At least having fewer people in the room will add to efficiency by reducing discussion time. I apologize for this rather cynical thought but it has some truth to it.
We are fairly agile. We follow the manifesto. We use more than 1 methodology but all are iterative. We tailor the methodology to the project.
I'm not implying that devoting 6-6.5hrs out of 8 to development efforts on average is good or bad, I'm just verifying that is is reality. I'm not looking at the quality of the code or the acceptability of the finished product, that's another discussion.
I'm just gathering statistics on development effort vs time available. We gather our own metrics here, it's just that senior management doesn't always realize that creative efforts can not be treated the same as mechanical production.
Our department metrics are right at 75%, but that includes all developers including the many hatters ( or is that mad hatters), which implies that for pure developers, the number is better than 75%. For us it's ~ 80% which gives 6.5 hrs / 8 hr day on average.
I must say that this is one of the most responsive groups, but this topic is gathering responses in a lot of the groups that are not solely devoted to jobs discussions, so there must be interest & need for data on this.
All the responses have been interesting & useful & much appreciated & show the willingness to contribute to the group. I'd also be interested in knowing how many shops gather data on this.
I'm not sure programming efficiency can reduced to numbers of hours spent coding. Over 30 years working on software I'd found on average that less than 10% of the time is spent coding. Most time (90%) goes on producing artificats (eg requirements documents, designs, tests) and meetings many of which take excessive periods of time.
Thanks to all of you, you & all the responders in other groups have given me great food for thought. I'm going to post an article on this topic & I'd like permission ot use some of this discussion in it. I will of course give credit to every one who has been a contributor to this discussion.
not a problem with me.
No problem with me either.
This comment was deleted by the author
I used to say a developer got 4 days work out of every 5, and a team leader got 3 out of 5. By assigning one of the team by rota to handle "interruptions" like requests for help from sales, support and engineering, we were able to maintain this pretty well. The person on "interruption duty" got around 1 day out of 5. We allocated 0.25 days out of 5 to "blue sky thinking" so that we had a forum to discuss and test our own research ideas, thus helping to keep focus for the rest of the week.
This was a team of 4 developers and 1 manager (me) working for a software house.
HI We spend about an hour or so documenting work for clients, ghostdoc takes care of some regular doc. However, the documentation created is used to better estimate task complexity and time required to complete. Posting questions and reporting progress on a co-wide chat facility encourages "volunteered" assistance of short duration, thus reducing the need for formal meets.
> On a typical 8 hour day, how many hours do programmers spend programming as opposed to other required/necessary activities.
It depends heavily on the specifics of your environment. The software process you're using, in particular, has a huge impact. In the companies I've worked with, the answer varies from about an hour a day to eight hours or more.
However, "efficiency" is much more than just what fraction of time developers spend programming. By using the right process and by approaching software problems in the right way, some developers can get five to ten times as much productive work done in a given amount of time as those who don't. In fact, this is precisely the trap that many companies fell into with offshoring: "inexpensive" offshore developers often end up putting in lots and lots of hours, but get very little done in the process.
My view is that it is a manager's responsibility to help ensure that their team is efficient -- and there are many aspects to that job. Things like: making sure the best tools are being used, establishing and maintaining enough communication while minimizing interrupts, coordinating ongoing training and mentoring, leveraging code reviews, establishing and maintaining a sound software process and selling it to upper management when needed, managing schedules and deliverables to maintain reasonable expectations from a developer perspective, establishing an environment that supports high-quality products, etc. All of those factors have a direct impact on developer efficiency.
Comments (19)
That's a bit like asking how long is a bit of string.
As a developer, I'd like to reply to your question, with one of my own...
As a project manager, how many times a day do you feel it's required to interrupt the programmers on your project, and asking them to give you status updates, time estimations and project progress analysis?
I ask this, beacuse I find that the amount of time I spend not coding (and please don't take this the wrong way) is usually the same as the amount of time I spend trying to meet the requirements of the project managers looking after the project, and if this time was less then I'd spend more time doing what I'm actually paid to do,
Thanks Peter. I'm a developer as well as a Project Manager & I understand the effects of adding to the programmers workload to provide for the PM's needs.
That said, how much time do you spend trying to satisfy the PM as opposed to working on your tasks?
I also understand that programming time is not just coding. There is design, requirements gathering & clarification, unit testing, code review & a score of other necessary activities the developers need to do in order to produce good code. All of this should be part of the 'Programming Time'.
BTW, on my own part, I find between 50 & 75% of my time is spent satisfying other peoples requirements. Of course as a PM, that's too small a percentage, & as a developer it's too large a percentage. Even worse, the constant interruptions make me take longer than necessary in order to get my mind back where it was before the interruption. But that's a topic for another discussion.
In all honesty Ray, at the moment it seems like ALL i'm trying to do is satisfy everyone else's requirements, however every project is different, and once I finish this one, then move onto the next, things may be different.
I can honestly say that I've never really found an average. In my previous capacity as a member of senior management team in a dev environment, I spent easily 98% of my time dealing with PM's, Meetings, Brain storming sessions and so on...
Previous to that as a senior engineer, I probably got away with 60 to 70%
At the moment, I'm wearing 10 different Hats, and for all wants and purposes I am the IT and Development department for the company I'm working with, so If it's not development, It's maintaining the systems, or being a DBA admin.
As an example, I'm easily a week behind with my development efforts beacuse of having to deal with database and server issues, and not the PM is on my back beacuse the software is a week late, so I try to devote time to the software, but he keeps asking for status and when will I make the lost week back up, he can't understand why it takes so long to catch up... so at the moment I'm 100% away from the actual dev work, when in actual fact it should be the other way round.
I guess what I'm trying to say in a round about way, is it varies from day to day, and I don't actually believe you can put a figure on it.
My condolences. You are in the same boat as me. I think we're bad examples to get average figures from. I've posted to other groups which are composed of mostly C++ or C# programmers & have gotten some good responses. It seems like for them they get ~6-6.5 hours out of 8 for development activities. For people who wear more hats, the numbers are all over the place. Here we actually track hours spent in development vs other things, so I can get average results. It may not hold for any particular week, but over a longer period it's a good predictor of available time.
We track both efficiency on available time & efficiency on estimates. Over a large enough number of tasks we can get a pretty good handle on the conversion of effort to schedule.
It's certainly a subject worth addressing, I would hazard a guess that a lot of the more senior devs in this group have the same issues.
Out in Qatar the company I was with actually put all of it's IT teams through an IT governance course, with an emphasis on "Improving communications with the business unit" , the incident that Kick started it all was one of the internal dev teams actually kicking a project manager out of the office and banning him from coming back in. In the 2 days he was banned, they got a huge amount of work done but refused to do reports/analysis etc and so the "business managers" felt it necessary to "Address the serious problem of IT not understanding the business needs" :-(
What you may want to do Ray, is set up a small website with a questionnaire on, then asking a cross selection of PM's, business managers, devs, admins etc to all contribute to the questionnaire, then lets see what the graphs reveal.
I'd say there's way more to this subject than just efficiency and average percentages.
I agree, there's lots more to the topic. The impetus for my request is upper level management's desire to 'improve efficiency'. From what I can ascertain, we're above average in 'efficiency', mostly from protecting strictly development resources from as many interruptions as possible. Have you implemented Scrum? Would you consider the daily scrum as development time or other?
You can probably read that as any combination of the following facts Ray :
1) Why is your dev team a loss rather than a profit
2) Why doesn't IT make any money for the company
3) Why does IT cost us so much to run
4) how can we make IT do more but for less money
5) how can we make IT staff less technical, and more Business orientated
Can you see a common theme here ;-)
I'd consider anything that's NOT time spent in development, to be taking my team away from what they get paid for.
ROTFLOL. Thanks Peter, I needed that.
Anytime ;-)
On a serious note however, those where questions that where pushed at us on the aforementioned IT governance course.
I'll give you a slightly different perspective - not answering how much time is spent but how much productive time might be spent writing code.
Before I began writing code I spent a long time writing copy. What I discovered was that if I was really focused, after about six continuous hours, I had pretty much reached my limit. Have had much the same experience when writing code.
Needless to say, it's easy to do the mindless stuff forever but when a high level of concentration is involved, at some point performance drops off dramatically.
Have asked other programmers about the caffine-driven 14 hour-a-day programming thing. Typical response has been that they wouldn't want to have to be the ones to fix the code the marathon programmers had written.
Thus, a certain portion of the day not whacking keys might actually be a good thing.
My problem time-wise is that too often it seems I spend more time doing "research" (trying to figure out how to do stuff) than actually writing lines of working code.
12 hours straight is a good day. To be fair, once you get in the zone low level design and coding intertwine so seamlessly that I'd be hard pressed to distinguish how much of that time is spent typing away on a Microsoft Natural Ergonomic keyboard (you do have one of these right? :). These days I don't do much coding without doing low level design. I basically consider low-level design and coding to be a unitary activity.
Usually only happens after the non-coding issues have been taken care of and it's time to get down to brass tacks. On days where I'm not so fortunate it will vary - anywhere from 0 - 8 hours.
Greg Robinson
Systems Design Analyst at Science Applications International Corporation (SAIC)
When I was a PM, I considered a productive day as 6 hours from my devs towards development tasks and 2 hours for all the other "stuff".
he he hehe..
here i come to spoil the party..
PMs should NOT be interrupting developers continuesly with questions about status of tasks, projects et al.
all of this could/should be available for the PM via an ALM system (TFS anyone??)..
it takes literally 2-3 minutes per feature to update the status in there and saves hrs and hrs and hrs per week..
if you're in an environment where the PM is constantly badgering you for updates and information look at it as an opportunity to educate...introduce processes that takes care of this. it's a good indication that the PM is not getting access to this information, which in reality should be readily available.
We hardly see our PM on this project - at least not the developers - the team leads+ (eg. project team) do speak to him on a weekly basis or if something comes up, other than that, he can do his work on another floor entirely without causing the interruptions..
Chris Snyder
Senior .NET Engineer/Lead/Architect
Not to get another argument started here, but, as a developer, I've always felt that dealing with the processes, PM requests, meetings, etc, are all PART of my job, not taking away from it. In my experience, it's not just a matter of efficiency (removing meetings, etc), but also understanding that these things are part of our jobs, and that they need to be considered in the estimates.
That having been said, I estimate 6.5 hours of development work, 1.5 hours of "communication".
Very interesting discussion. I want to add another factor to this topic. Imagine, you have a line of tasks and performing them one by one with all these interruptions and fun that were described before. Here we can put another word: "multi-tasking". Hell? What is the real % of 'efficiency' here? Seems like you producing solutions, making reports, tracking a lot of things around, implementing, developing, testing. Do any body believe that there is perfect multi-tasking performer in a software - development world? For me it is like a horse run with broken legs and unsatisfied customers, who came to see a performance.
From another point of view, project statistics and project tasks play together. Keep a balance is the trick. And of course after all of these we can smile on such questions like why we put so much overtime sometimes on very clear subject.
Welcome to a software development world.
@Brian, nah your not spoiling the party... I distinctly remember someone mocking the same PM I'm on about when I was telling you about him on MSN...
Does the phrase "Bad PM.... Baaaaaddd PM, go sit in the corner..." mean anything to you :-D
As a developer at a consulting firm, I often find myself spread even more thin as I frequently have multiple projects & clients I'm trying to satisfy, each with their own PM.
As developers, we all know this happens, but the hard part is finding a good way to measure those distractions vs productivity, and also to see how long it takes to get restarted on your dev work.
Recently, I've been focusing more on personal-productivity and found the tool Rescue Time ( http://www.linkedin.com/redirect?url=http%3A%2F%2Fbit%2Ely%2F2ZGngp&urlhash=o1ON&_t=tracking_disc ) to be useful to help gain visibility of what I'm actually doing all day. It tracks what apps you are using and graphs them over time so you can see when you spend more time in MS Outlook vs. VisualStudio or other dev tools. Its pretty flexible around how you configure the priority and productivity implied by each application, and even lets you say which websites are considered "productive" vs. "distractions".
This is good for those who work in front of a PC all day, but its still hard to quantify the gaps when I'm away from my PC at meetings and such. However, its very interesting to see how my "productive time" takes 15-30 minutes to ramp up again after each meeting or other distraction.
Another similar tool I have used in the past is TimeSnapper (timesnapper.com I think) which lacks the reporting, but actually takes screenshots of your desktop so you can replay it later to see what you were spending your time on.
I hope this helps.
(no I dont work for these companies or own stock, I just like their products)
Thanks to all of you & all the responders in other groups. You have given me great food for thought. I'm going to post an article on this topic & I'd like permission ot use some of this discussion in it. I will of course give credit to every one who has been a contributor to this discussion.
I have no problems Ray, in fact let me know when your done, and I'll add a link to my blog at http://www.linkedin.com/redirect?url=http%3A%2F%2Fcid-4515677bdf99b35f%2Espaces%2Elive%2Ecom%2Fdefault%2Easpx&urlhash=gWz0&_t=tracking_disc
![Brian H. Madsen [MVP]](http://media.linkedin.com/mpr/mpr/shrink_40_40/p/2/000/026/12a/30446e7.jpg){kind=small}
Comments (8)
Matt Palmer
Technical Architect
I'm not sure that is a useful metric to ask for. If you're interrupting a programmer all the time, even if you add it all up and discover, for example, they're doing 5 hours a day, they won't be doing good programming.
The thing about programming is you have to give programmers continuous time to get "into the zone". Also, sometimes a programmer needs to do something else when faced with a difficult problem, to let the brain subconsciously work it out.
IMHO, better questions to ask might be "how many days do I give a programmer non-interrupted time to program in", and "how many days per week/month do I need to allocate to other essential tasks". At the very least, if regular meetings or other tasks need to occur more regularly, they need to be at the start or end of a day, week or month, and not interrupting concentration.
You can do the math to get the daily figure from those stats, if you still feel that this provides any useful information.
Brenda Gail Hatcher
Technology Consultant at Cobb Systems Group
Do you define efficiency in terms of the amount of code produced? How do you factor in the quality and effectiveness of the code?
Thanks Matt & Brenda. I include requirements gathering & ellucidation, design, unit testing, code review, etc... all as part of the development time. The other time would be for non task related e-mail, phone calls, non task related meetings ( e.g. HR briefings, birthday celebrations, etc..), & any time not spent on task related activities. Our metrics give 6-6.5 hrs per 8 hr day on average. I'm not saying this is good or bad, just seeing if this is normal. I've posted this to many groups & it seems fairly consistent across the board.
Would you count the daily scrum as development time or other? I count it as development time, but some of my developers would probably count it as other.
We also track LOC. Quality metrics are based on the amount of rework. That belongs to a separate discussion.
Matt Palmer
Technical Architect
I guess if you got 8 hours a day, that would be entirely unrealistic (other things have to happen), and someone wasn't telling the whole truth! If you were getting only 4 hours a day, you might be in trouble - more time spent not developing than developing.
That somewhere in the middle of those two is normal doesn't surprise me. I guess I still don't know what value you gain from that knowledge - you are getting "average" efficiency - i.e. you aren't absolutely awful, and you aren't unrealistically brilliant. If the figure was 5.8, or 6.8, instead of 6-6.5 would that make any difference to anything?
Incidentally, I also believe tracking LOC is a fairly useless way to measure programming activity. Bad programmers often produce lots of code where better programmers produce less. Great programmers can even remove code! And conversely, lazy programmers may write very little and motivated ones may churn out lots of code. Knowing how many LOCs were produced (or removed) doesn't really tell you very much!
I would be very interested to hear what use you make of these metrics. Is it to reassure senior management that they are getting value, or to drive changes to the environment, or some other reason?
Brenda Gail Hatcher
Technology Consultant at Cobb Systems Group
How do you know that a developer is producing effective code? Is that where quality metrics come in? What metrics would you use and how would you incorporate them to arrive at an "effective" designation?
Sorry, I always have too many questions :-)
We measure efficiency on payroll & efficiency on estimates of effort. The product of the two for each developer gives us a good way to predict duration, using the theory of large numbers.
We measure quality on hours of rework compared to hours of initial effort, & on customer acceptance based on usage & help desk calls.
Matt Palmer
Technical Architect
Ray,
I'm still not entirely clear on how the efficiency measures work. By payroll, do you mean the pay level of each developer? By estimates of effort, do you mean the number of development hours each day?
I'm reasonably sure I understand your quality measures, and they seem pretty good to me.
It's actually payroll hours, not $. Effort is the number of hours logged by the programmers on their tasks. This is compared to their estimate of the number of hours they think it will take them to complete the task. On any single task, the numbers are meaningless, but when averaged over scores of tasks, their efficiency on estimation can be obtained. Multiplying the number of hours logged vs the number of hours available ( payroll hours) gives the payroll efficiency. The product of the 2 is the efficiency of the programmer. We can then multiply that times the estimated effort of all that programmers tasks for the project & come up with a duration. Each programmer has his/her own efficiency numbers on both payroll hours & on estimation. Again, you need large numbers of tasks to arrive at a useful set of numbers.
Comments (11)
This depends a lot on how well the organization protects programmer time. A big component is interruptions -- not just the time spent on the interruption, but the fact that each interruption means that the programmer will require an additional 15 or more minutes of wasted time after the interruption to get back his concentration. One 15-minute interruption per hour will cut productivity in half. Good environments allow programmers to have 2-hour blocks of uninterrupted time. Add to that the wasted time in weekly and daily status meetings -- most status meetings ask each programmer, one by one, their status, meaning while one programmer is reporting his status, the rest are all having their time wasted. Clueful managers/PMs get their status into from emailed or online forms; the really clueful ones simply look at their team's Continuous Integration web page to see what features have been committed and passed units tests. Clueful PMs also protect their programmers from other tasks -- we know now that the concept of knowledge workers shared between projects causes more inefficiency than it saves.
So, depending on environment, I've seen anywhere from as much as 7 hours per day to as low as 3 hours per day of productive work.
Also, recognize that programmers as a group have an unusually large range of productivity. The most productive workers in other professions might be 2X or 3X more productive than average. Good programmers are 10-15X (or higher) more productive than the average programmer. (For example, I was at one Fortune-100 project where a team of 10 programmers, who were selected as the enterprise's best programmers, were more productive (over 2 years) than 200+ programmers at the same site working on other parts of the same project.) And many of those 200+ programmers were only 0.1X productive. So, hiring practices will hugely affect your human resource allocation estimates.
There is also the question of whether you are doing waterfall or some form of iterative methodology, like Agile. If you have 1-week or 2-week sprints, instead of wasteful multi-hour weekly status meetings you'll get status at the end of each sprint. Old-school weekly status meetings and "let's get everyone together so we can review and revise the requirements" meetings are replaced by weekly meetings with customers to demo the sprint's finished work, and collect and bid on Use Cases (User Stories) for the new sprint. Any daily and ad hoc meetings are replaced by the 10-minute morning stand-up.
(In general, I've given up on PMI's waterfall-based approach when it comes to managing software development projects -- there is just no way to get even 60% of requirements *accurately* nailed down before coding starts, because customers don't start to understand many of their own requirements until they get a demo of working code. The idea is to accept that scope changes are inevitable in software development, and to identify and make them as early as possible while they are cheap, rather than waiting to get feedback only at the very end when it's much more expensive to make changes.)
-david
Thanks David. We are fairly agile. We follow the manifesto. We use more than 1 methodology but all are iterative. We tailor the methodology to the project.
I'm not implying that devoting 6-6.5hrs out of 8 to development efforts on average is good or bad, I'm just verifying that is is reality. I'm not looking at the quality of the code or the acceptability of the finished product, that's another discussion.
Steve Blais
Solutions Architect at Parkson International and Information Technology and Services Consultant
Kent Beck and Ron Jeffries talk about the "perfect programmer day" or some other nomenclature. It is used for calculating velocity in agile methods, especially XP. The idea is to figure out how much time a developer can spend devoted to programming or designing or testing without interruption, or as Tom DeMarco calls it, the "flow". Does the average programmer have two hours a day in collateral duties? Does the team spend an hour a day in team-building chatter? Are some of the developers maintaining other systems while working on the new stuff?
There are two approaches: have the Scrum Master or Coach or whatever block all the interruptions to increase the average programmer day and therefore increase velocity and capacity. This is one of the ostensible goals of the Scrum Master - remove obstacles. Or, reduce the average time to accommodate the interruptions, distractions, co-lateral duties, and context switching time.
Years before agile when we did bidding to the US Federal government for software development projects we bid based on hours expended to create the product and then factored it over the calendar to project the due date. After subtracting out all the government allowable "down time" including bathroom, meals, etc. the average programmer put in just under six hours in an eight hour day. The average production of lines of tested, documented code per programmer in the Federal government at that time was 2000 lines of code/ year.
Tom Gilb and others suggest estimating the job and then subtracting 20% from every programmer's normal work day.
Bottom line: if you estimate jobs, especially in the agile environment, assuming you'll get 8 full hours a day out of everyone, you'll always have items left on the sprint backlog at the end of the sprint.
Thanks Steve, I wouldn't argue with Kent Beck, Ron Jeffries or Tom Glib, just out of respect, regardless of the fact that I agree with them on this issue. All I'm saying is it seems that even with protection from interruptions, there will still be something that takes up 20-25% of the time, even if it's just the need to think about something else for a while. We're human beings, not robots, & we can't be 'in the flow' all the time.
Steve Blais
Solutions Architect at Parkson International and Information Technology and Services Consultant
All too true. We rarely put in eight full hours of consistent productive work. Especially those of us in the "knowledge" industries. The concern for productivity has two purposes. It's either a management control issue where management is measuring against some benchmark - an 8 hour "productive" day, or a completed quantity of work for that 8 hour "productive" day, or it's a measure to make or verify estimates of work to be done. In the former case the team is in trouble when management sets the bar to 8 hours "productivity" because it usually means more real hours in the office or at work. The issue in this case is setting expectations of what can be done in that "8 hour day". Unfortunately we in IT, especially in programming, have for a long time performed heroic efforts to get work done by unrealistic deadlines, primarily because we love the challenge and the technology so we're willing to work 16 hour days because it's enjoyable. Those days are long past. But the expectations of management have not changed. So many times we are the victims of our own doing, and the expectations have to be reset for what can be done in an "8 hour day".
The second issue is more in our control. As programmers and nerds we are always overly optimistic and believe we can do more than the clock allows. That is the source of the standard procedure to add 20% or 50% to any programmer's estimate. This is where the 6 hours actual production in an 8 hour day comes into play. This is where the programmers and other technicians have to realize that they are human beings, not robots, and they realistically won't get eight hours in the flow, even with a top-notch manager who protects them from corporate interruptions and handles all obstacles.
A long early AM response that says I agree with you totally.
You hit it right on the head. We are getting pressure from upper level management to increase 'efficiency', even though from all the metrics I can find, we're extremely efficient.
Steve Blais
Solutions Architect at Parkson International and Information Technology and Services Consultant
How about shorter sprints or iterations?
It's not the sprint or iteration length that seems ot be the problem. I think it's that we have an extremely large legacy code base, which makes maintenance take up so much of our effort & which makes new development take longer. They want more with less, & are not willing to spend time refactoring without an immediate measurable benefit. We are sufferning the 'Tyrany of the Urgent".
Steve Blais
Solutions Architect at Parkson International and Information Technology and Services Consultant
My sympathies. Been there. There are some numbers someplace - check the agile websites like agile alliance - that show some solid cost benefit down the line to refactoring, i.e. ability to make changes and add new functionality faster, etc. Maybe some solid numbers might help reallocate expectations.
Thanks Steve, you & David & the responders in other gourps have given me great food for thought. I'm going to post an article on this topic & I'd like permission ot use some of this discussion in it. I will of course give credit to every one who has been a contributor to this discussion.
Jim Volkman {LION}
Data Analyst/Active Job Seeker (1,300+)
I'm not a true programmer but I've done some programming and have worked with many programmers over the years. I agree with all of David's points.
Thanks to everyone who has contributed to this set of discussions. I've arrived at four major points from all this:
- 70-80% efficiency is the norm. We are human beings, not robots.
- Increased hours decreases productivity. We are human beings, not robots.
- Estimated Effort can give Expected Duration. Statistics like those we have been discussing can lead to reliable estimates of duration. ( Please note that estimated effort should be a 3 point estimate, so that PERT or a modified PERT, can give an expected estimate of effort).
- Special Interest Groups are composed of knowledgeable, giving people.
No comments:
Post a Comment