There was an interesting post on another site about programmer productivity and how to measure it. There was a lot of discussion on LOC (lines of code) or KLOC (thousands of lines of code) and there was pretty good agreement that it isn't a particularly good measure. My own opinion is measuring productivity is fundamentally very simple. You measure and reward what you want and you can also measure and penalize what you don't. The key is figuring out carefully what it is you want because I can guarantee you will get what you reward. I really believe fundamentally that productivity should be measured so you can make mid-course corrections. If you know what you just did hurt your productivity, make sure you don't do that again. But you may never know if it went up or down unless you do measure it. I will talk at length on this topic another day as I have a lot to say about it but for now, suffice it to say that the measure I use personally is "bug free functions." I will elaborate in another post on what constitutes a bug-free function but I bring this up because I will be comparing my own personal productivity in the coming months against data I collected in prior years. Since I have changed a lot of things, I expect the productivity will be much higher. However, I am most interested in the changes I've made recently because I think I am getting HUGE gains by using code generation.
So - I talked recently about an idea I had to use a build tool (FinalBuilder) to script a code generation process. Well I used it today for a few minutes - yes only for a few minutes. Why you ask? Because I was done in a few minutes! I had actually taken a database table, generated an ORM class by reading the schema and spitting out some XML, applied a template I wrote recently (XSL) to spit out a very nice looking Delphi class. It was a good test because it is a table with a large number of fields so there was a little bit of everything there. I then inherited from the class I generated, added some hand-crafted code, i.e., two method calls to do some custom processing. I was done. What I accomplished in minutes would have taken hours. It is also not the most fun type of programming. It would have involved typing and cut-and-paste and a lot of silly stuff that is very error-prone. So instead of doing that the rest of the day, I get to write about it instead - which I might add is very, very therapeutic. Writing about it also solidifies your own understanding. I'm sure you know exactly what I mean.
The thing about Code Gen is it is a process. Just like building an application is a process that merits a script to drive it, so is Code Gen and FinalBuilder is perfect for the job and up to it. I do know I'll be adding some custom actions to FinalBuilder to do some things but even that doesn't look too difficult. What I am really enjoying is knowing what I am doing is fruitful because the gains are so apparent. The gains are not 5% or 10%. They may well be >1000% type gains. If you can take a task that takes five hours and reduce it 5 minutes, well you've saved a lot of time. If you can generate 80% of your app that way, well think about the time to market that just went down A LOT.
No matter how you measure it, I am more productive. Yes, the computer wrote the methods. But I wrote the software to write the methods. So I get credit for all the lines of code, or in my case for all those bug-free functions that I just "wrote." I don't care how you measure it, with code gen vs. the old way, you are more productive - period. Henry Ford understood automation, economies of scale, and how vital a factor is this thing called productivity. It should always increase - it least that is my philosophy. Every so often, breakthroughs are made and productivity moves ahead by quantum leaps, not the baby steps that are more normal. Code generation is a quantum type leap of productivity.
I will be measuring this very closely with a couple of applications. I should be starting application #1 in a week or two at the latest.
Comments