First Randori Session in Helsinki

I participated the first randori coding dojo session in Helsinki today. In short: it was fun.

It was really great to see other people in action, making decisions using TDD with people they had never met before. The discussion was really interesting. This was also one of the most controversial things about the randori session - I think the audience was suggesting a bit too much on the implementation side, but on the other hand, that way all of us perhaps got to hear more views on the problems that we would have otherwise. So, it's hard to say whether the future sessions need to be more disciplined or not. Either way, I'm definitely going to join them.

Thanks again to all the guilty parties (Markus, Pekka, Lasse)!

Being Agile on Project Level

One of the reasons I started this blog was to keep track of the steps I'm taking while moving from cowboy coding to agile development. I figured that people who are considering the same transition later might be able to find some pointers here.

Now, to fulfill the latter purpose, instead of writing something ignorant about using XP on project scale, I'll just let the more competent writers take the stage.

First, a very good newsgroup message by Robert C. Martin (in comp.software.extreme-programming). Second, a blog post by James Grenning (on ButUncleBob.com).

I have nothing to add.

The World Doesn't Want Me to Code

I've been busy this week. It culminated today, when I spent the whole "working" day doing another school assignment. I slept only a couple of hours last night, trying to finish the task in time. I couldn't make it, and when I realized I would miss the deadline, I laid back a bit. Leaving my laptop on standby I spent two hours elsewhere. When I came back, the machine had crashed and failed to reboot.

So, there I was, staring at a laptop with a (probably) broken hard drive. The code I was working on was (and is) probably gone for good. After the first hour (or two, or three) I am finally starting to realize this isn't the end of the World... just the end of the coding spree I really would have needed.

Note to self: Learn to make "big" decisions faster

I had a nasty problem at work. I was asked to add some functionality to old code that took the contents of a set of data and transferred them to another data set, changing the data to different form according to given criteria. What I was supposed to do was to include some previously excluded data in the transfer. It doesn't sound that difficult, but when the function that does the actual transfer has 7-10 different branches doing different things (according to the given transformation criteria) and nobody seems to have any idea how it does what it eventually does, the task becomes rather challenging.

My big mistake was to try to include my own additional code to the method (actually, the language only has functions, but it's easier to understand this using Java terms), so that the source data set could be read only once. I ended up banging my head against a wall for 5-6 days trying to understand how the old code works. This Frankenstein of a code was about 250-350 lines of code, with loads of if-clauses, loops and boolean flags. I tried debugging and running the transfer with a couple of outputs to track down the general idea of the existing code. I guess I made some progress, but just couldn't make the bloody thing work as a whole.

Finally I decided it's better to leave the monster in its cage and work around the problem in another way. So I added the new parts of the transfer only after the existing part had already been executed. The fix was ready to be tested in about 15 minutes.

You might be able to imagine how stupid I felt. This solution forces the program to go through the source data set twice, but since it's always pretty small and there are no database queries involved, the decrease in efficiency is probably too small for a human eye to even notice. The only thing with which I can defend my stubbornness to include the new functionality inside the existing code, is the logic that these things are closely related/connected and should be done together. I still think such logic has its place in designing such additions to existing functionality. However, if the options are to spend more than a week fighting a losing battle or doing the desired addition in less than an hour, it's probably justifiable to choose the latter option.

Heads down - at last!

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)...

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.

Personal Responsibility

If you start losing your motivation at work, it's easy to blame the conditions: low pay, boring tasks, low-quality products (both the ones you are making and the ones you are using) or your boss and colleagues' lack of respect for you. You can moan about this all and yearn for change, and still stay passive and pessimistic. This is the biggest mistake you can make. You can, of course, find another job and hope everything turns out to be better. However, you might find yourself in exactly the same situation again pretty soon.

Dave Thomas said in an interview that "To motivate yourself and keep yourself committed, you need to have pride in what you're doing." I think this is absolutely true. I believe the most important thing you should remember is that you can affect your surroundings. So, instead of finding a perfect workplace, you could try making your current workplace one.

Don't live with broken windows. Finding another job might seem like an easy way out. But choosing the easy way seldom makes one proud. Pride comes from making things change for the better. So if something really gets on your nerves, try to change it instead of escaping it. This could not only make your own life easier, but it might also prove your bosses that you're a valuable asset to your employer.

For example, if your employer doesn't seem to find continuous testing of software important, try introducing the benefits of test-driven development to them. This should help both your conscience and your employer.

Then again, sometimes employers are not willing to spend valuable time training their staff to use new methods. They might rather stick to old habits, however inefficient they may be. In cases like this, you should remember that sometimes pride comes from making big decisions that cause a lot of changes. Like going for that another job.