16

How can I track that I'm developing software more or less productive than the previous days?

10

8 Answers 8

19

There's a simple answer: you can't. And moreover, you shouldn't.

You want to measure your own productivity, but you can generalize: how can you measure productivity of programmers? First of all you have to define what you mean for "productivity": amount of code produced? Amount of design (or specification) implemented? Number of issues fixed? Quality of produced code? (Yes, quality is a productivity counter, you can produce a lot of bad code or few good code, what has been more productive?). All these values can hardly be mapped to a daily base, and any attempt to track daily productivity is dangerous for the project, for the company, and for the programmer.

My advice is to clearly define what you mean as "productivity", then define a measure unit, and apply it on a weekly and monthly base.

7

I'd say the best way to measure your productivity is to set a goal each day for what you want to have done that day, and if you complete it, consider it productive. It's a fairly subjective measure, but you'll most likely find it much more rewarding than an objective one.

2

Both suggestions below can be roughly adopted for your need, but in both cases you need to do estimates in advance and then analyze them ad hoc (and honestly, I'm not sure if there is another effective way how to measure this, I agree with TheLQ that lines of code per time period aren't usable at all).

Agile development methodologies
Although I'm not sure how effectively it can be applied to a single developer scenario, some of the principles used in Agile can prove useful in what you aim to accomplish. Agile works in cycles in which developer(s) aim to implement stories (tasks) which are scored (in points) based on implementation complexity at the start of a development cycle, and then analyzed at the end of each cycle. This allows to determine the velocity, i.e. the number of points which a developer or a team can complete within a single development cycle.

If the way you work allows you to adopt some of the principles and organize your work in cycles, you can use the velocity per development cycle metric to track your efficiency. Note that cycles usually last 2-3 weeks, however you should be able to shorten them when using this for yourself only. It all comes down to if you can adopt such a methodology in your environment.

Evidence Based Scheduling
Even though it's primarily meant for improving estimates, you should be able to use it effectively to track decreasing trends in productivity.

2

Agree with Lorenzo, define the productivity.

I also did this: 1. Break down all the tasks (high level or low level break down). 2. Estimate the working hours for each task (don't forget to set delay buffer for each task). 3. Finish the task. 4. Review back each of task and see if you are productive enough or not.

2

Here's a meaningful and accurate measure of productivity that involves taking multiple Evidence-based scheduling snapshots:

Once you've gathered a few days' worth of statistics, run your Monte Carlo simulation, and observe the graph, which should look like this:

enter image description here

Then do one more day's worth of work, and run the simulation again. If you were productive that day, the graph should change something like this:

enter image description here

Most importantly, if you were product on that day, the ship date probability on any given date should increase since when you last ran the simulation before that day of work. If it decreases, then you were less productive on that day.

Of course, the accuracy of EBS increases with time and experience, so that can be another reason for the change in the ship date probability value. That's why you want to start doing this at least after a few days worth of sampled work. Even without that, though, if you were significantly more productive on one day or another, the probability should increase quite noticeably.

2

Counting lines of code is an imperfect measurement as it offers no insight into the quality of the code but can be used to determine general productivity. Depending on what language you use there are different tools that will count lines of code for you but I've requested that BitBucket, a Git Repository, add productivity related statistics.

https://bitbucket.org/site/master/issue/4307/feature-request-contributor-statistics

1
  • 3
    as long as you used LOC as a personal measure (you are the only one you are measuring, and you are the only one using the measure) many of its drawback become moot.
    – Jay Elston
    Dec 6, 2012 at 2:22
1

Measure the time it takes from you sit down at your computer in the morning until you do any non-work-related activity, such as 9gag, facebook, reddit, etc. Your productivity that day is proportional to that number.

0

Assume for a moment that being productive is managing your time such that you are utilizing all of your working time to work towards completion of your tasks, and that anything that contributes to wasted time - I.e.: time spent not completing your tasks - is non-productive.

About the only thing that you can really do is to log your time when engaged in various activities throughout your day. Time boxing is a technique used for various purposes, but would suit this effort to log your activity during a day. Spend 15 minutes on a timer simply doing some task. If the task is something you are supposed to be working on, your time was productive. If you found yourself editing your blog, reading a news paper, or daydreaming about that nice girl in accounting, then your time was probably unproductive. Add up your minutes at the end of the day and you'll get a feel for how productive you are...

But there's a catch! What do you do about those other minutes... you know, taking a 5 minute break, going to lunch, having your boss interrupt you to tell you about that big fish he didn't catch on his last fishing trip? Log all of that too. Time spent on a break isn't wasted if it contributes to your mental health and well-being... just so long as you aren't taking a 5 minute break every 10-15 minutes!! As to the rest, interruptions, dealing with other work related issues.. all of this can be tracked.

You can of course find yourself obsessing over this sort of stuff, and god help you if the boss is one of those people who sees you time-boxing and uses that to justify reasons to pile on more work, or criticize your efforts. You see, the problem with obsession over the productive hours is that you can be working for an entire day, and still end up getting nothing of actual relevance done. Some days you can be writing code like it was butter melting right out of your brain, and onto that sandwich that you call your screen... while other days you can have a serious mental block as you try 357 different ways to do the same thing, only to watch it fail. Many would say continuous "failures" can be unproductive, and that in itself isn't going to be helped no matter how much you time box and log your hours during the day.

The other way to look at it is to simply set yourself a number of goals, to complete during a day and a week, and then work towards completing them. If you actually achieve your goals, you can argue that you've been productive, and if you don't achieve your goals, you may need to understand why you didn't meet them, and decide if you were or weren't productive based on the actual reasons for missing your goals. Ultimately, if you deliver working code when it's needed, and if you can get your tests to pass, and a task completed, then you've been productive. Measurements will only be of value if there is a legitimate reason for analyzing them statistically later on.

Not the answer you're looking for? Browse other questions tagged or ask your own question.