Sunday, December 14, 2008
How fast can you write code?
I am a dinosaur and one of the last remaining enterprise architect's on the planet that still knows how to write code...
I remember earlier in my career when I worked with folks in India in the last 90s, I would sometimes throw in the towel in frustration and simply write code myself instead of bothering to explain requirements and/or quality long distance. On more than one occasion, I would put my ego aside and just tell them to put their name on my code in order to move things along.
In the days of old, I used to pride myself on how fast I could write code and it was my own way of measuring my own productivity. Today, I have concluded that it is a poor measure, but it's not completely worthless. The level of productivity I achieved in these cases is clearly a lot higher than I normally achieve. I think it's important to point out that in the last two cases I had a very good idea of exactly how all the code should be written. You can write code very fast when you know what you're doing.
The rest of the world that attempts to measure this same notion has different starting points where some just measure the raw act of writing, while others at least count the time required to get a clean compile. Others still go one step further and count time including debugging vs sweeping things under the rug.
Peak programmer output is much greater than average programmer output. One conclusion that can be drawn from this is that the actual process of coding doesn't dominate development time. One implication of this conclusion is that writing more code won't necessarily slow you down much. This is one reason prototyping can pay off so much. You can spend a lot of time writing prototype code and then lose very little when you throw it away and start over from scratch. You can regain the functionality implemented in the prototype far more quickly than when you wrote the prototype because you are now programming (at least partially) in a problem space that you have just explored. This is exactly the kind of circumstance that one can achieve maximum productivity in.
So in one sense I am suggesting that writing a lot of mediocre code quickly is often a good idea, but I am also suggesting that you then fix it, refactor it, rewrite it, or start over from scratch as appropriate to get good code...
| | View blog reactionsI remember earlier in my career when I worked with folks in India in the last 90s, I would sometimes throw in the towel in frustration and simply write code myself instead of bothering to explain requirements and/or quality long distance. On more than one occasion, I would put my ego aside and just tell them to put their name on my code in order to move things along.
In the days of old, I used to pride myself on how fast I could write code and it was my own way of measuring my own productivity. Today, I have concluded that it is a poor measure, but it's not completely worthless. The level of productivity I achieved in these cases is clearly a lot higher than I normally achieve. I think it's important to point out that in the last two cases I had a very good idea of exactly how all the code should be written. You can write code very fast when you know what you're doing.
The rest of the world that attempts to measure this same notion has different starting points where some just measure the raw act of writing, while others at least count the time required to get a clean compile. Others still go one step further and count time including debugging vs sweeping things under the rug.
Peak programmer output is much greater than average programmer output. One conclusion that can be drawn from this is that the actual process of coding doesn't dominate development time. One implication of this conclusion is that writing more code won't necessarily slow you down much. This is one reason prototyping can pay off so much. You can spend a lot of time writing prototype code and then lose very little when you throw it away and start over from scratch. You can regain the functionality implemented in the prototype far more quickly than when you wrote the prototype because you are now programming (at least partially) in a problem space that you have just explored. This is exactly the kind of circumstance that one can achieve maximum productivity in.
So in one sense I am suggesting that writing a lot of mediocre code quickly is often a good idea, but I am also suggesting that you then fix it, refactor it, rewrite it, or start over from scratch as appropriate to get good code...
