Yesterday I finally jumped into the trenches. I'm doing a small school assignment that should get help me improve my own software process. The assignment is based on PSP. However, I decided it's a good chance to concentrate on something completely different (heh). So, when I started actually coding the first assignment - a simple LOC counter - I tried to stick to TDD as well as I could.
And I can tell you, I haven't been that excited in months, or probably years. After struggling a bit with creating a new project in Eclipse (and setting some keyboard preferences and the like) I dived head-first to the world of agile development. (Ok, I know this sounds a bit over-the-top, but that's exactly what I felt like then!)
Of course I had thought about the assignment already a few weeks ago, but now I wanted to stick to the crucial basics of XP: do the simplest things first, implement only the things that you have to. So I started by writing a test that asks a method (that I had not, of course, even started writing yet) how many lines of logical code an empty line (or string) has. Naturally the assertion compared the method call to zero. I tried running the test before I any actual code ready. And it failed - woohoo! Next I wrote a simple, one-line method that compares a given string to an empty string, and if they're equal, returns zero. I actually ran into problems right away, because I had used the default package for the test and now included the actual code in a real package, so I had to move the test to that package, too (which meant creating a new package in test/src directory and moving the source file under that one). Even though the mistake was quite stupid, all I could feel was excitement about learning! I had not written any (serious) Java in a couple of months, so it felt really good to "get on the road" again.
And so I went on. I added a test with one line feed and ran the test, which failed. Then fixed the actual method to trim the given string before doing its comparisons, and again, the tests passed. And step by step, I added functionality to the method, always writing the corresponding tests first: not counting a single comment line, counting several statements on a single line as several lines of code etc.
Although I spent only a couple of hours doing the assignment before I had to do other things, the work really took off fast. And I can't wait to get my hands on it again (hopefully today)...
Monday, October 31, 2005
Friday, September 30, 2005
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.
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.
Thursday, September 29, 2005
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.
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.
Subscribe to:
Posts (Atom)