Agile Question: Where is the satisfaction?
One thing that Agile promotes is the use of pair programming and, by extension, the idea that the code does not belong to anyone person, instead, it belongs to the group as a whole. I have a question regarding this; put simply, where does the satisfaction come from?
When I create software on my own, I get satisfaction from the code that i create. The more I put into the code, the more the code becomes mine and the more satisfaction I get from what I am creating. But if I am changing pair programming partners several times a week (or day) and am working on different bits of code throughout the day–none of which belongs to me–where does my satisfaction come from? Also, how do I know that I am doing a good job?
I have seen this come up in blog posts around the net (I just don’t have any links to prove it) and have seen solutions such as, “I go home and create code and get my satisfaction from it”. I am not sure that this is a very long lasting solution.
On the other hand, I have seen programmers, who get too attached to their code, take any suggestion of change to that code very personally. I have seen programmers get very upset when other people suggest there might be a bug in their code. “I programmed that component, what do you mean there’s a bug, it’s perfect, I programmed it myself!” I am sure that if everyone was honest, we have all responded this way at sometime when told of a bug in our code. I guess this is one thing that pair programming is trying to stop.
Agile development methodologies are good to have sparingly. Where do you get the satisfaction from? Well hopefully from working with really intelligent people. The company I work for has scrum meetings all the time, however, the actual agile development slacks. We use pair programming sparingly when one developer is stuck on a particular problem that is slowing down the our weekly sprint. We also use a lot of continuous integration via CruiseControl, which makes life very easy.
If you can’t find the satisfaction in the people you work with then hopefully your project (code) is innovative/simplistic and solves a particular problem which you feel is important. And if that fails, then yes, working on your own pet project should give you some satisfaction. I don’t see the industry adopting agile development methodologies very well at least from what I’ve seen.
Personal satisfaction can also come from using new technologies that are of particular interest to you, … that is if you are lucky enough to be in that sort of a position.
These are all points that I thought of after I published the blog entry. I guess personal satisfaction comes from working with a smart, intelligent team and from creating software. Although I may not own anyone part of the code, I still own all of the code and the final product that is produced.
One other question that I had that was not mentioned in the article was a fear that doing pair programming can turn a group of developers into toasters. By this I mean that they are simply viewed as an assembly line for code production and not as individual developers. Or, put a little softer, as a single unit instead of as individual developers with different skills and/or aptitudes. This may be a problem not with pair programming or Agile but with management.
That’s a good point that you bring up. I can see that happening particularly if the managers themselves haven’t gone up the chain of ranks from developer to manager. Because our managers can likely also be ITM graduates. It also depends on how the company is structured. Our VP is in direct contact with the developer’s managers and everything seems to go through him. So the control there is more stringent. The VP is also in direct contact with the clients which is advantageous but, I would say the managers who have a developer background, rather than a business background, would probably be able to better gauge efforts and time frames better. Then the question becomes what makes a good manager? But I see your point; treating them like an assembly line takes away the human factor and makes it seem that providing the pair of developers with new requirements and changes would almost seem to imply that they will always get the job done on time.