Diving into the World of Agile Methods

I think it's time for me to abandon the general small talk and get to some serious business. So, from now on, I'll try to stick to more software-related things.

Today I attended a lecture on software processes by Professor Inkeri Verkamo. The highlight of the lecture was a short comparison between agile and traditional processes. The view on agile process was based on Alistair Cockburn's Learning from Agile Development (CrossTalk, Oct & Nov 2002). Although my knowledge of agile methods is very, very limited, this short introduction offered little I didn't already know.

However, one of the important features was the presence of slight criticism of agile methods. (I'm eager to see Markus considering the alleged pros and cons of agile methods he heard at JAOO 2005.) Cockburn's views were considered to be quite objective, but some of their shortcomings were also mentioned. It is usually said that agile methods are more flexible than the traditional ones and can adjust well to processes of different size. However, most of the examples that are often given involve a programming team of 2-4 people. It's not obvious if the same methods apply to a group of 30-40 developers as well. It's also often said that agile processes don't tie developers' hands but let them use their skills better than the traditional processes. This is probably true, but it also implies that agile methods - using Verkamo's words - "rely heavily on the excellence of the developers". I know from my own experience that a novice programmer is more a burden than an asset when teamed up with experienced "gurus". Pair programming might in theory solve this problem, but sometimes the skill gap between the developers can just be too big.

Agile processes may very well address these things and I sincerely hope I find it to do so. Still, a good student should always challenge the things she is told. The Agile Manifesto should not be seen as the new Holy Bible, but be taken with criticism. No matter what option a software developer chooses, she should always be able to justify the choice to herself and others - and "The others told me so" is never a valid justification.

On Ambition(s)

I believe one of the most important qualities that make a person successful is her ambition. At the worst, ambition can make people lack empathy and only think their own good. However, ambition can also be strongly linked to one's will to succeed without harming others. In such cases it can be a valuable asset to its possessor.

I think there are two kinds of ambition: long-term and short-term. When using the word, people usually think about long-term ambition; I think it's what makes people want to become something. This is a very common feature in people. For example, many dream about becoming rock stars or corporate officers and making loads of money and appealing to large crowds. This kind of ambition is not only equivalent to dreaming, but may actually be a driving force to one's goal.

However, in my opinion, most people lack short-term ambition. I think this is what makes one do every small task as well as one can. Instead of just dreaming of a better future and having distant visions of how to achieve it, the ones with short-term ambition take determined steps toward that future by doing everything they do with premeditated precision. Using biblical expressions, I believe these people are truly the ones who shall inherit the Earth.

So, what does this mean in terms of, for example, software development? This is closely related to the commonly known Broken Window Theory which I already mentioned in my first post; instead of waiting for that beautiful future with a decent software product in one's hands one should start making one's current software project that product - because future is built on what is done right now.

On Motivation and Choices

In my previous post I wrote a few words about motivation and motivating oneself in a job that has started to seem like something one doesn't want to do. I also wrote that one of the options in a situation like this is to try to change one's current environment. However, the best way to stay happy is to avoid jobs like this for good.

Obviously this is easier said than done, but you must remember that your responsibility to yourself should weigh more than your responsibility to others. What I'm trying to say is that you should always keep in mind that it's your own life you are living. Sometimes it's good to listen to other people's advice, but not always. There's also a difference between what seems to be (or became) useful to learn and what seems like fun and interesting to learn.

Life isn't always fun. Sometimes you should look really far to understand which option you should choose now. However, choosing something you don't like doing but expect to pay off later may prove to be a mistake. If that option turns out to be really demotivating, you might end up learning nothing. And doing nothing is always worse than doing something you really love - regardless of how much it pays or how happy it will make your parents.