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,
SDG
jco
Posts
7 comments:
As a fellow programmer i could certainly understand the frustration of having junior programmers imposed upon you in an unfamiliar/uncomfortable style of paired programming.
Though as a user of agile methods for many years, i must say that paired programming is just one aspect of one (namely Extreme Programming or XP) of several different agile methodologies, and not the most comfortable, in my opinion.
Agile itself is just an idea or aspiration to improve lives of the programmers and deliver the results in the most efficient and effective manner under often or constantly changing requirements.
If you'd have time to explore what is meant by it, perhaps you may subscribe to the idea yourself. A good starting point is a short treatise called Agile Manifesto, http://agilemanifesto.org, after that look into Scrum method or others, if XP is not to your liking.
Alex
Expanding on my experience with agile, the best aspect of it was ability to deliver something to users in regular intervals (iterations in agile parlance), concentrating first on items most critical to them. The quality aspect of it comes from regular refactoring and redesign of the code to accommodate the latest understanding of the requirements and preferable architecture based on them. There is also no months long design stage, only a relatively short stage sufficient to start on the first few iterations for the requirements known - it's naturally flexible "how short" to produce good quality code.
Hi Owen,
A colleague of mine sent me the link to your blog since I am the only Agile developer in my company. I have been practicing Scrum for years now and I have to admit that I have heard your story many times.
Please excuse my prejudice, but "people like you" are the reason for the strange (and most of the time wrong) perception people have about Agile development methodologies.
First of all, Peer or Pair Programming (a junior and senior programmer working together in fornt of a computer) is NOT Agile Development. Let me stress this:
Pair Programming != Agile Development!
It is merely a very small part of an Agile Development methodology called XP - eXtreme Programming. There are multiple other methodologies that are considered Agile, amongst which you have Scrum, my personal choice.
The example you use in your blog is like saying that you hate cars because you had to manually wind down the window all the time when you had to use one.
Personally, I think that Pair Programming is a great tool to get juniors up to speed quickly. But it needs to be implemented with care: a session of more than two hours is extremely exhausting for both the senior and the junior and I strongly advise against it. However, twice a week a session of an hour or two and you will see how quickly the junior improves (given that it is proper Pair Programming and the senior actually has an interest in passing on information. I have seen the opposite a LOT).
Please do me and yourself a favor and do a google or wiki search for "Scrum" or - even better - go talk to some people who have experience with this technique (or join a newsgroup). You will see that there is much more to it than just "sitting in front of a computer together" and that a proper Scrum team will always outperform a regular development team. (There you have it: generalities! :)
Good luck and hopefully you will be lucky enough to work in a proper Agile environment at some point.
Che
Ahem, I think I need to learn to read:
"Hi JAMES" I meant to say... :)
Che
Che et al:
You are quite right: Pair Programming != Agile Development, even though it PP is part of AD. Unfortunately, that is how some of my clients have described it in the past and I am reluctant to try and change their thinking on that part. EXtreme Programming, of which paired programming is a part, was to be the main focus that discussion so I will try and change the title of the discussion to "EXTREME Programming : Paired Programming" which should make it far more accurate.
BTW, I did lose a potential client (a very large client) who did not understand that there are some who can NOT do productive work under those circumstances. At one time I worked in an environment with some individuals who (before the days of Extreme Programming) worked in a "pod" arrangement - meaning low walls and four to a "pod". In order for me to work there I had to wear a baseball cap pulled down low and put up visual blocks to keep from being disturbed and put on my headphones with loud music to block out their continual conversation. It didn't matter; when they wanted to ask some trivial, silly question they would throw wads of paper over on my keyboard to get my attention. Most rude.
It has been shown that if you are working on a problem that requires a hight level of concentration that small disturbances such as that will cost you, at the least, about 20 minutes. Considering that these clowns (the only name that is appropriate to their behavior) did that kind of thing two or three times an hour, it was almost impossible to do any productive work during the day - I did my work after 5:00 and before 9:00.
SO! All that to say this: Some of us work on problems where we don't need a junior person to teach - teaching is done in the class room or OJT. I usually work on problems that require more thought than code and the LAST thing that I want is to have my performance dragged down by having to explain simple details to a junior person.
I took a cursory look at Scrum. Not bad. But even the Scrum Wikipedia pages seem to confuse Agile Programming and Extreme Programming (your distinction, not mine) and they do point out that Agile / Extreme is not applicable in some (most to my way of thinking) cases.
Now, in agreement: Well documented requirements (and rulebased requirements are not necessarily the same as normal IT requirements) are absolutely necessary. Tasks assignments are necessary. Project managers are a necessity and a blessing. But PLEASE don't team me up with a junior person looking to "learn how it's done." That is training and I do that only within the confines of a classroom where it can take two days to show how to take a 30 minute process from step to step to step to step to reach a final conclusion.
I once taught the old "Monkey and Bananas" problem on a Saturday (back in about 2000) to a class (using JRules) to show how information flows, how an Agenda Table works, truth tables, etc. and how all of these change with each iteration, or firing, of the rules. This is something really basic. But, by noon most of the class found something that that they just HAD to do that afternoon.
And thanks for changing my salutation to James rather than Owen. :-)
SDG
jco
Hi James (hey, I got it right the first time! :),
Thank you for your answer, this is going to be a long discussion if we don't watch out, since we have a fundamentally different way of looking at software development, I think.
If I look at your post, two things stand out to me.
The first is the standard issue that I have seen in many Software Developers over the years, including myself: the "my way or the highway" approach.
In my experience, there are many, many different kinds of developers. They all require you to use a different approach when leading them or trying to teach them something. And they all have their very unique way of focused work!
I have worked with developers that could only work with headphones playing death metal, I have met developers that would only work in bursts of 30 minutes and then walk around for another 30 (yet still get the same work done as everybody else, it was a miracle).
And, of course, I have worked with people who need quiet rooms with carpet to dampen foot steps.
The point is, you have to be open and accept that there are different ways of getting work done for different people. This is your way, and it is a good way if it works for you, but I feel that you are using the propaganda approach to try to push your way through as THE way.
And in line with that, there are people who most enjoy teaching juniors (be it through PP or lecture) and who still get their work done because it is "their way" of doing it. I like to think of myself as one of these people. :)
The second thing that stands out in your post is that there still seems to be some confusion about what Agile Development is. Agile Development does not state "well documented" requirements a necessity. It states well DEFINED requirements a necessity. AD, and I am talking Scrum here because that is my area of expertise, does definitely NOT need task assignments. As a matter of fact, I am very strongly opposed to task assignments - in my experience, they alienate you from the work you are doing. Developers simply don't feel like they are working for a common goal and a common product if they are simply given bite-sized chunks of the whole thing. Additionally, who else but the developer knows what they are good at and what problem they think they can solve in a certain amount of time? Let the team be self managed and self organized and you will be astonished at how much work it can get done.
On PM's: I have worked with very bad ones, I have worked with one very good one and a few decent ones. Agile PM's are still hard to find and the ones who claim that they are, usually are not. A GOOD PM's is a blessing, because he will let the team work in their self managed way, uninterrupted and will support the team and join standup and sprint meetings. Bad or even so-so PM's will -in my experience - stand in the way of development and the team by forcing the team to think and work in patterns that might not be suited for it.
Again, good luck with your Agile future - have a look at http://www.scrumalliance.org/ if you would like to learn more about Scrum. Trust me: I have worked in a high performing team once and it was an incredible experience. :)
All the best,
Che
P.S.: Disclaimer: All the statements about Scrum are true if you do proper Scrum and if you DO HAVE a good Scrum Master. I have worked for soooo many companies who claimed that thy were doing Scrum while they were definitely NOT doing anything close to Scrum.
Implement Scrum properly, with support from management and the whole company, get a good Scrum Master and you will see how powerful this approach is...
Che:
I've been doing some more thinking about this and I now think that eXtreme Programming might be a good idea to bring young developers "up to speed" but you can't do this 8 hours a day. It would drive the senior developer crazy and production would fall out the bottom of the bucket.
Rather, the Sr/Jr arrangement could be used for a couple of hours each day as an OJT arrangement where the Sr Developer would assign something for the Jr Developer to do for the next meeting. So, what would be wrong with that approach?
If the Sr Developer assigned the Jr Developer to go read a book (just a few chapters) on a particular subject then, to my way of thinking, that would be acceptable. However, Jr Developers (from my own experience) don't like to read books and articles unless it is something of their own choosing.
I think that at my time of life (over 50... WAY over 50) that I don't need to take my time to work with only one Jr Developer. I would much prefer to work with several of them at once but only for an hour or two each day and I would cover some of the more arcane aspects of rulebased programming. So, what do you think of that approach?
SDG
jco
Post a Comment