- A developer who completes a task quickly, but produces unreadable code without documentation
- A developer who completes a task quickly, but leaves it riddled with bugs
- A developer who takes twice as long as you'd hoped, but architects the system so that it can be expanded effortlessly in the future
- A developer who takes longer to complete a project so that he can train another developer along the way, so that in the future the two of them can work in parallel
- A developer who takes eons to get any of his assigned tasks done, but along the way creates tools and systems that make the entire team more efficient in the long-run
In all cases, the trade-off is between short-term and long-term productivity. I think most startups begin by focusing on short-term productivity, and as well they should: with the high rate of startup failure, there's no sense planning for long-term gains when the long-term might not exist. For large, established companies, focusing on long-term productivity is usually more important; they have the luxury of existing market share to buffer them from at least some competition, and they know they'll be able to reap the rewards of their patience. But for companies like us, somewhere between the worlds of the startup and the enterprise, where to walk the line is a lot less clear. And the trick becomes balancing each and every decision with the need to be nimble today and sustainable tomorrow.
And so as I try to figure out how to measure productivity, I find myself wondering if I'll even be able to define productivity in our current environment.
Since you started this blog, I've been thinking of things like this, things that can be traded off in favor of speed of implementation. But I hadn't considered the definition of "productivity" and the fact that it is not synonymous with speed of implementation. That's a good point.
ReplyDeleteHere are some things you mentioned that you might be giving up if all you care about is speed of implementation.
* Bug-free code
* Readable code
* Extensibile code
* Handing down of knowledge
* Creation of tools that make things easier later
Here are some you didn't mention that I've been thinking about:
* Learning about the code base
* Learning about new technologies
* Comments and documentation
* Code efficiency (I sacrifice this one regularly--I figure processors, disks, network, and memory will catch up with my slow code soon enough)
* Realizing or admitting that a small project is "the straw that is breaking the camel's back" and it's time to refactor a huge chunk of code (some very speedy coders never realize/admit this and just pile hack onto hack)
I remembered a couple more things that are sometimes sacrificed to make things go faster:
ReplyDelete* Teambuilding (Nerf gun battles in the middle of the day, etc.)
* Preventing burnout
Excellent points. I wonder if it's worth talking about things in terms of short-term and long-term productivity, to make clear that those two goals are often at odds with each other. It would also be interesting to try to predict long-term productivity by measuring at the end of each project those things that influence it: documentation, extensibility, lack of bugs, etc.
ReplyDelete