Tuesday, June 30, 2009
Recently I've been thinking that I need another blog - one that I would use just to vent and blow off steam at the stupidity of some of the things that we do as programmers. One of those is something called "Agile Programming" where two programmers work on one computer, both at the same time; one writing, one watching and commenting. This was all hyped up a couple of years ago that, in my own opinion, was to help the "less developed" programmers ramp up quicker by being teamed with a more experienced programmer. (Surely you wouldn't put two of the newbies together, would you?)
Anyway, the sheer though of having to explain everything that I do to a newbie who hasn't taken the time to read the first book on rulebase theory, has forgotten everything that he/she might ever have known about statistics, has never had an accounting course in their life and reads only blogs like this for information (OK, they don't even read blogs any more; they just listen to "tweets" and such) sends me into tremors of sheer terror. Don't get me wrong; there is a place for training. But that place is NOT when you are behind schedule (aren't you always?) and you need to get something "done" by the end of the day/week/month.
So, when do the newbies get training from the old timers? When those things are scheduled for (maybe) an hour or two each day or each week. When the trainer can have time to properly present the complete thought process that goes behind each precept of a programming paradigm. When the logic of a though process is presented in a proper methodology rather than a series of "Why" statements followed by an answer that is intended to just shut the other person up rather than teach. This is because you are trying actually to THINK through a laborious process. When done in this manner, sometimes learning takes place. Hopefully.
At our last Java MUG meeting the speaker was pointing out the time that it took to build an idea or a process in your head and that, if interrupted by various things, how long it would take to get back on track. It was actually very revealing. Without intending to do so, he proved my point. Once you are interrupted you can not just turn around and pick up where you left off. Depending on how long was the interruption time and for what reason, it could easily take 15 or 20 minutes to get back to that level of concentration and/or that step in the workflow process.
Which is why I take the phone off the hook, shut the door to my office and put my headphones on when I am trying to concentrate and work on something that requires that level of focus and thought. BTW, during the meeting I did ask if anyone had ever done Agile Programming. Only two guys raised their hands and only one thought that it was a good idea to do programming in that manner. BUT, he did qualify that it was only effective for about four hours a day. According to him, productivity and quality of programming went (way?) up when Agile programming was used. That tells me that the problem "might" have been way too many newbies who needed to improve their programming skills. But, that's probably just my prejudices talking.
When did I personally use Agile Programming? Only two clients have ever tried to force me to do that. One was for a major insurance company in the USA and the other was in the UK. At the USA company it came down to either I would have to leave or they would have lower their expectations of what I was doing. After my rebellion all of the other senior consultants did the same thing and the whole idea was thrown out.
The client in the UK kept sending me really low-paid technicians hired from 4th-world countries who didn't have the foggiest idea of how to use a rulebase nor what was the thought process. I was working as an emloyee at that time for a major BRMS vendor and, at first, they resisted. But when the 4th-world vendor sent two or three of their techies to school and became a partner, then I was asked to reconsider. I told them the same thing; I could do that but production would suffer if I had to stop and explain every little thing to a newbie. Besides, I was not being paid to train personnel outside of my company. If they needed more training then they could go to the vendor-provided school for more advanced courses. They didn't and neither did I.
So, did I ever try it and have it fail? Nope. My clients wanted me working on rulebase problems 100% of the time and were not willing to pay me my normal rate to train a newbie; not even one of their own employees.
Comments to this blog are always welcome. Even when you believe in something as silly as Agile Programming and how it can improve the quality and quantity of programming code. I would ask only that if you do think Agile Programming is a good thing that you tell us of your personal experience and how it helped the quality and quantity of the programming code. And be specific; not that the programming was "better" but how this "better" was measured with and without Agile Programming. What benchmarks did you or your company use that would help guide the rest of us in measuring the "quality and quantity" of the programming code. And if you believe, as I do, that Agile Programming is for really strange people then tell us why in very specific term and in reference to personal experience. Thanks,