How Much Programming Capacity Do You Have?

January 31, 2009

In my last post, I championed both feature prioritization and cost/benefit analysis as essential ingredients in achieving software results, with results defined as generating the greatest possible value for the investment in programmer time. But just how much “programmer time” does your organization really posses?

More often than not, during tight economic times – like what we are experiencing today – many companies not only cut costs (and typically this means people), but they also focus their attention in two seemingly contradictory ways:

1. “Doing more with less.”
2. Asking for more innovation and creativity from their employees.

Can software projects meet these two demands? You can – if you understand your true programming capacity in relation to your planning.

My experience is that most software projects are trying to do too much with the staff that they have. Instead of “doing more with less,” I feel that your motto should be: “Decrease time spent on low-value work and increase time spent on high-value work.” Yes, it’s a bit of a qualifier, but I advocate concentrating your efforts on performing more high-value work with the reduced staff that you have in order to improve results.

Ask yourself the following questions: How good is your organization about meeting project schedules? Are you hitting your dates with quality code? Are your programmers contributing in innovative and creative ways? Do your users feel that they are receiving value from the software that you deliver? If you are achieving all of these things, congratulations!

One common complaint that is often voiced with software projects is that developers are optimistic when it comes to estimating, but they aren’t the only ones guilty of this. I’ve seen entire organizations believe in schedules that they really shouldn’t. This ultimately leads into heads-down, aggressive programming and testing, with no time left over for anything but the essentials. Innovation and creativity take a back seat to the schedule.

The main problem is that many people believe that they have more programming capacity than they really do. Consider how project schedules are typically created. Many times, programming estimates are provided in days or hours. Do you schedule – and subsequently plan and bank on – eight productive hours per day, per programmer? I hope not! At my company, we recognized that interruptions and general “administrivia” will get in the way. At one point we attempted to use six-hour days as our “ideal developer day” for planning purposes, but this didn’t work out.

One simple reality is that there are hours in a day, and then there are productive hours. This isn’t just a programmer problem. It surfaces in any white-collar work. While your actual experience may vary, mine has demonstrated that four genuinely productive programming hours per day is the norm. Why? Because there is more to programming than coding; things like thinking and designing come into play. I’m interested to hear what your thoughts are.

Another problem stems from the abuse of the word “estimate.” Unless the same person is writing same application that they wrote last week, estimates should be viewed as an approximation, a ballpark. There is a uniqueness to every development project that makes defining exactly how long it will take to deliver a feature (or set of features) difficult to determine with great precision.

While this can be mitigated by ensuring that the requirements are very precise and that sufficient time to design the feature(s) has been provided, the tendency is to short-change this process and hold programmers accountable for meeting their “commitments.” This situation is in part why Agile development has taken root.

Also consider the following: If you want programmers to contribute in creative and innovative ways, they need time to keep up with technology, to understand the task at hand, and to think about and collaborate with others in applying technology. If people are pulling out all of the stops to meet aggressive deadlines, there won’t be any think time available.

I have another data point related to the scarcity of available programming – specifically the amount of programming that you should expect – that I find extremely interesting: Lines of code per day. No, I am not attempting to measure productivity! This is all about pointing out the scarceness of programming resources.

An industry example is Microsoft Vista. From what I have read, Vista comprises approximately 50 million lines of code. Reports seem to vary on this, but the typical programmer on Vista is said to have produced an average of about 8-20 lines of code per day, with a maximum reaching 50 lines of code per day. Using 230 working days per year as an average, we’re talking about 4,600 lines of code per year, per typical programmer (if you use the figure of 20 lines of code per day). I’ve seen other estimates that put the average lines of code per programmer on Vista nearer to 5 lines of code per day, or about 1,150 lines of code per year, per programmer.

If these numbers sound low to you, take a hard look at the realities in your company. And remember that there is more to programming than just producing code; For example, the problem domain needs to be understood and design work has to take place. Poorly-designed code that does not meet the business need will result in waste and more defects that must be fixed before the software is deemed usable. (Consider the knocks Vista has taken in the marketplace.)

To summarize, programming is a complex, detailed undertaking that requires a lot of planning, designing, and old-fashioned thinking. Programmers need to be working on those projects that provide the highest possible value, period. And don’t waste their time, there is so little available to waste!


poecide said...

One problem with estimating time required to do a project or a portion of a project is that your time may not be entirely your own. At my job, when I estimated the work for the current sprint (we're working toward using scrum but not completely there yet), I did not realize that there would be twice as many meetings in January as previous months, because the new year involved bringing new people up to speed on various projects.

I'm being somewhat productive but not at writing code. How do you measure that?

Which brings up another point: When measuring productivity, do you factor in test coverage? Testing takes more time but gives better, more stable code in the end. Most programmers don't much like, testing, though and may feel pressured to churn out production code - so they can show the boss progress - at the expense of testing. How do you deal with such considerations?

January 31, 2009 at 2:04 PM
Dave Moran said...

Good questions!

I believe that measuring productivity in a software/white-collar environment is extraordinarily difficult, and the title of this blog is Software Results for this very reason. Productivity is certainly desirable, but the real goal is to achieve results. You can get very bogged down in measuring “productivity” – particularly since the case can always be made that your organization or situation is different, or that there are extenuating circumstances affecting a particular productivity metric.

Organizations, teams, and individuals all have goals, and there are key performance indicators (KPIs) that impact the contribution(s) being made. Activities such as more meetings to bring new people up to speed are difficult to measure, and affect the “productivity metric” of coding, at least in the short term. However, you are contributing towards the desired short-term result of enabling more people able to produce (presumably more) later.

My take is that you are making a valued team contribution at the expense of your immediate, personal coding “productivity,” but the long-term effect will be greater team productivity and better long-term results. Measuring your communication and collaboration skills (which affects how well you are performing in getting others up to speed) would be what I would consider examining as a key performance indicator, and regard this as a valuable contribution towards the desired result.

Productivity measures, no! Assessing performance and contributions, yes!

January 31, 2009 at 3:12 PM
Dave Moran said...

I re-reading the questions posted, I realized that I did not respond to the question about testing…

I agree, most programmers don’t like testing and feel pressured to turn out code. From my standpoint, testing is vital to ensure that the code is doing what it is supposed to do, and that includes the specific functionality desired, ensuring conformance to performance and security requirements, as well as checking for fault-tolerant characteristics. (Who wants a blue screen of death?)

The definition of productivity is important here. I’ve seen (and heard others complain) that some teams are regarded as “high-performing” because they meet their dates, without regard for the fact those same teams end up fixing the software for months after the “end” date. Other teams that deliver a little later (let’s say one month), but with high quality are conversely regarded as less productive. Productive to me means quality delivery, allowing a team to move on to other work – and contributing more – versus fixing up code that was classified as “done.”

“Done” is when users can reliably use the software, that it provides the value they expected, and that the project team is able to move on and produce something else. Measuring productivity (contributions, not things like lines of code) on a longer scale should help.

January 31, 2009 at 5:41 PM
M. Ali Nasim said...

Results and Value is the key!

I think it also needs to be seen from the light of Business-IT integration perspective, and how the line between the two has blurred. The more challenging your industry, the smarter and more business-savvy your programmers need to be. I like to think of my developers as more like business professionals trying to solve business problems. I strongly believe that every white-collar (IT or otherwise) within your organization should be viewed as a business professional who should try adding business value to the organizational objectives. Its only the tools that differ. A Finance guy might be using more of Excel while a programmer might be using more of Visual Studio, but if they all can see themselves as an integrated whole trying to work towards the same goal of maximizing value - then things start to fall in the right perspective.

Will you ever measure a Finance guy's KPI by how quickly he punches data on the excel sheet OR how precisely and correctly he analyses and reports that data? OR will a Creative writer's performance be measured by how fast he/she can type the new marketing brochure OR how killer (and valuable) his/her creative idea is? So, in many cases now 'less is more' (less mundane work is more value). Less lines of code per day might actually mean more productive code adding key value. Less number of use-cases implemented per-day might mean that the programmer instead of working the easy but unuseful ones, really worked at the ones which added more and immediate value.

Thats where Agile mind-set makes all the difference. A cross-pollinated team of IT and Business professionals all having an agile mindset can solve business problems and add value at a pace that could've never been imagined with a different way of working. I would emphasize here that agile is not just a development methodology - its a holistic business philosophy which requires a paradigm shift - not just among developers but throughout the organization.

Just imagine the benefit of having a programmer who can see eye-to-eye with your Finance Manager and reverse-engineer his fat n ugly budgeting excel sheet to construct an ERD diagram and design a budgeting process and use-cases? Now reverse the scenario - imagine your Finance Manager is tech-savvy enough to review the ERD that the programmer created and validate the design to make sure nothing from his budgeting data-structure got missed! A couple of hours of meeting of these 2 strong and agile-minded business professionals and whoa - you've created a value which otherwise would've taken multiple requirement workshops!

So all in all I believe your assessment is spot on! Looking forward to hearing more from you.

February 2, 2009 at 5:55 PM
svil said...


one common mistake of the management is to require results - and each level of management understands this differently - but not invest enough time to actualy say what is expected. And then lower levels start "dereferencing void * pointers", i.e. are being left on their imagination/interpretation. And then one day MrBigBoss sits, looks, and says: "u have not done anything" (after 12man-years invested). i had that just 8 months ago. it was... interesting. it happened that there wasn't a business-looking project plan to his taste...

on the other side, contributing towards overall group success sure hits your own productivity (or u start working 16/24... which hits you worse, just later)... i had these last year for long time, teaching 2ppl at once, while being project's-lead-and-everything.
but i find this similar to "fixing something that works to help something that does not". there's one article about it:

Although i've a cult for efficiency myself, recent years i have found myself frequently doing above "spending", as looking from higher perspective it's a long-term investment. And it really works - as long u have judged right the people u invest in. Which is the hardest thing.

same goes for testing, config mngmt etc "routine" things... they are always left for later but they might as well help a lot with other stuff, like finding holes in requirements - thus removing (or adding) some big part of the job. i guess the extreme end here is test-driven development.


February 3, 2009 at 3:45 PM
Anh Nam said...

Dịch vụ chuyển phát nhanh ở tphcm ngày ngày càng phát triển góp phần nâng cao dịch vụ mua bán đặc biệt mua bán online. Nên các chuyển phát nhanh hcm luôn được phát triển nâng cao nhu cầu phục vụ công ty doanh nghiệp. Dịch vụ chuyển phát nhanh của Công ty Proship đã được nhiều tổ chức, doanh nghiệp, cá nhân yêu mến, tin cậy và hợp tác lâu dài. Trong quá trình xây dựng và phát triển, chúng tôi công ty chuyển phát nhanh tại tphcm là hiện thân cho tinh thần trách nhiệm và trung thực, dịch vụ chu đáo và nhanh chóng. Tại thị trường Tphcm, Proship được đánh giá là một trong những Công ty Chuyển phát nhanh làm ăn có hiệu quả, uy tín, có sức phát triển và dành được nhiều cảm mến. Chuyên cung cấp các dịch vụ chuyển hàng đi sài gòn .Ngoài dịch vụ nhanh chóng, chu đáo và giá cả hợp lý thì Proship cũng có nhiều chương trình khuyến mãi cho các khách hàng tại Sài Gòn. Nên nếu bạn là cá nhân hay công ty doanh nghiệp đang có nhu cầu sử dụng dịch vụ chuyển phát nhanh sài gòn hãy liên hệ với chúng tôi công ty Proship. Với những uy tín vốn có của doanh nghiệp, chuyển phát Proship nhận vận chuyển các loại hàng hóa và bưu phẩm theo yêu cầu của khách hàng. Với thời gian 1 ngày duy nhất cho quá trình vận chuyển hàng từ các tỉnh thành trên cả nước và chuyển phát nhanh tại sài gòn , chúng tôi sẽ nhận hàng của quý khách tại văn phòng hoặc tại nhà riêng, công ty sau đó sẽ kết nối vào Đà Nẵng và phát tận tay người nhận theo địa chỉ ghi trên bưu kiện.

October 22, 2015 at 12:23 AM

Post a Comment