Error-Driven Development

Concentrating on the Errors

2008-04-02T12:46:00.000+03:00

Yesterday I again attended the monthly Agile Dinner here in Helsinki. I almost skipped the event due to other engagements but finally decided to go. I'm happy that I did, and want to thank everyone else who was there.

We again discussed a wide variety of topics, ranging from how tidy our rooms are to the familiar Mac-Linux-Windows battle. I found the discussion about the psychological side of decision making etc. to be particularly interesting.

Choosing to do things the way one has seen them done before successfully can definitely became a subliminal decision. This kind of "muscle memory" can be a great advantage and save one from stopping to think for choices when there is actually only one way to do things correctly (or at least efficiently). Then again, I believe this fights the "thinking outside of the box" attitude in a sense. Of course learning such a way should only happen when that way of doing this has proven to be good. Still, I think never questioning "the one and only way to do things" prevents improvement of methods (or processes, if you will) from ever happening.

Another - yet somewhat related issue - is having a strong opinion on or getting used to the way things should be or look like. Take code formatting, for example. Using opening braces based on the C convention (brace on its own line) in Java code can sometimes disturb me so much that I simply have to fix it before I can start really reading the code and finding out what it does. This applies to whitespace also, even more so. Not to mention importing classes one never uses etc. (I could go on for quite a bit here...) Luckily I can fix these "anomalies" in code using reformatting commands in my IDE in half a second. Still, it raises the question whether one should be such a fundamentalist when it comes to code formatting if it actually prevents one from seeing "beneath the surface" and concentrating on the what the code does.

These are of course not programming related issues only. Like I said yesterday, I know people (and might be one) who can be absolutely unable to concentrate on the semantics of some text if there are many punctuation or grammar errors. So, the errors can be the only thing one sees. I think it's clear that numerous errors will make the text unreadable for almost everyone except the person who wrote it, but the number or severity of (e.g. spelling) errors people can tolerate varies tremendously.

I wonder whether it's after all a good thing to be a purist in these issues.

Iterative Art

2007-06-01T22:25:00.000+03:00

After watching a movie or listening to a song, I have sometimes heard people say how they could improve the existing work of art we have just enjoyed. And I believe they could be right, when the definition of quality is theirs to decide. This is the case especially if they could have the talent of the original artist at their disposal.

However, if they faced an empty canvas or had a reel of empty frames, I think very few of them would be able to create (or ask for) the same result. So, the best way to achieve the most pleasing result (at least from the viewpoint of the customer - artistic visions aside) would probably be to let the parties take turns to do their part: the customer would first describe what she wants, then the artist would make a first sketch, after which the customer could ask for modifications or just let the artist continue in the current direction, etc. And I have no doubt that this was the way that even well-recognized artists worked when they were paid for making portraits of wealthy people.

I have often compared programming to painting or other (visual) art skills. Even though some artists might find the comparison quite offending, I believe we face the same challenge in filling an empty canvas, although the result of programmers' work may be a little more functional in nature. Thinking about the process described above, I guess we can have something else in common, too...

A New Beginning

2006-11-05T22:45:00.000+02:00

The first couple of weeks in my new job have been really nice. The atmosphere is really relaxed, yet ambitious and supportive. Also the people have been nice, so I've settled in very well.

Agile methodologies have also found some fertile ground there, before and after my arrival. To my (pleasant) surprise, my second working day included a presentation about JUnit to everyone who was interested. There was also interest in going to the recent Agile Seminar. It was made clear that attending the 3-hour seminar would count as working hours. This was a really good sign, helping me to feel that the company wants to support its workers' learning. There were four or five of us who eventually attended the seminar.

I also had a talk with the colleague that gave the JUnit presentation and asked him to join the next Coding Dojo. Only one or two days later the next dojo invitation was announced, so the timing was perfect. We went there together and talked a little about giving an internal dojo session at our workplace later. I believe the TDD knowledge level is not sufficient yet for a full-blown randori, so we might start with a lecture-like approach.

I'm actually feeling really busy nowadays at work. Not because of the workload (which is actually really decent) but because I'm eager to participate in everything that helps us get our processes better.

Changes

2006-10-06T21:38:00.000+03:00

My mission to introduce automated testing at work is now finished. It is far from complete, but today was my last day there. In a couple of days I'll be working for another employer.

It seems I managed to plant a seed of interest in testing; some (now past) colleagues told me they are sorry that I didn't get further in introducing some tests and the testing process. That makes me feel that they have actually understood the importance of testing, but it also suggests that no one feels confident enough to continue the work on their own.

Then again, it's out of my hands now. I guess all I should be interested in is that my new employer is excited about agile development.

Old Habits Are Hard to Break

2006-09-01T17:19:00.000+03:00

In the last two weeks I've spent some time writing a small program, which I finished a couple of days ago. It served its purpose but looking back, I see some room for improvement.

First, the GUI was a crucial part of the program, and I am still to learn automated testing techniques for user interfaces, so I didn't go far tests-first. Instead of learning to use the appropriate tools and techniques I decided to go on without (GUI) tests.

Second, since I didn't know how to write good tests for the interface, I started slacking with writing tests altogether. When I was running out of time, I also reverted to the "good" old cowboy coding style.

Third, I tried to write the program one feature at a time, using a simple planning game by myself (me being the customer as well as the software provider). I made some time estimates and decided on the next features to write based on the available time. I guess I could have prioritized the features in a different way, but I did get a working piece of software in the end - with the chosen features done to the end, and the rest missing completely. However, my accuracy concerning the time estimates varied a lot. I also think I could have adjusted my time estimates better based on the time I used while implementing the previous features.

And last, I actually noticed all of these issues already while writing the program but didn't "have time" to correct them. I guess this way of thinking is the first thing I should change. (This might be closely related to reverting back to the old coding style, but deserves to be mentioned separately.)

Still learning, I guess. But then again, aren't we always?

P.S. Two co-workers returning from their holidays commented on my unit testing paper. One of them was impressed by the detailed instructions I had written. The other - the head of our C# development, kind of - asked where I got the idea and started chatting with me about automatic builds - of which I didn't write much in the paper... I guess there might be a breeding ground that I was unaware of for some agility.

Work update

2006-08-15T16:44:00.000+03:00

Since my last post I have tried using VS2005's testing framework and NUnit with our actual code base. Yesterday I checked in the first tests (totalling 38 test methods for a single class) to our source code control. I had picked the class under test quite randomly but hit a sweet spot with my choice - one of the tests found a bug in a method that was written more than three years ago. And I actually tried to write the tests to match existing code... Perhaps the method is not used very much, since no one had noticed the bug before. (It should have turned up by now, because the method generates a short part of an SQL statement, and with one valid input it returned SQL that is not valid in any DBMS.) There was also at least one method where a null parameter was not considered a special case.

"The other guy" tried checking out the tests and running them, and everything went smoothly. He also thought the tests were a good example of finding small bugs in existing code. Since everything had worked, I updated my paper and added some technical details about running the tests.

Today I finished writing it (at 19 pages) and checked it in. I also wrote tests for another of our basic classes and checked them in as well. This time writing 24 test methods took a lot less time than the previous ones.

So far no one has commented on the work - except for the guy who wrote the method with the bug I found. I went to check if it was ok that I used his method as an example of hard-to-see bugs that could be found easily with testing. He was just browsing through my paper and was pretty impressed. Although no one else has given any feedback, I feel pretty confident. I actually think I'm changing things here.

Let's see if I'm just fooling myself or if my colleagues also start writing some tests.

Winds of Change

2006-08-04T16:52:00.000+03:00

Last week I wrote how I had planned to start talking with my colleagues about improving our processes much more than I had did before. That's exactly what I did.

First, I talked with one of the guys in our internal IT support. He totally agreed with me that we should not be doing things manually if they could be automated. He also told me that one of the developers had tried "some XP thingies" earlier, so I went to have a chat with him. He had read something about unit testing but had not done any on his own. I promised him I'd try writing some tests for some of the most used classes in our production code. He was willing to help, if I needed anything.

Then came the development discussion. I told my superior about automated tests and builds, and she gave me a go-ahead to try and write some tests. I installed Visual Studio 2005 that same day and have tried writing some unit tests with the built-in testing framework. So far I've just been playing around but I still feel great. I also wrote an 8-page paper about unit testing, including instructions for getting the framework to work properly. To be honest, the paper ended up having some propaganda-like raving about the importance of testing and proper coding style. It was still received well by the other guy interested in XP, who is the only one who has read it so far. We also thought I might install NUnit and try it out for comparison. Now I'm getting some other work done, but next week it's time to dive into writing those actual tests.

The only issue I'm worried about is our company culture. All the people I have spoken with have been somewhat intrigued by my Agile ranting but have also questioned whether it's possible to change the way people here work - and have worked for over ten years. That's a challenge, and I must try and point out some benefits from writing tests for our code. I'm also curious to see whether our code is actually so well written that it will be fairly easy to write those tests.

As a side note: I even started thinking whether tests could be used to "guard" good coding standards. For example, making sure methods don't change their parameters' state as a side effect could usually be tested quite easily. Then again, including such checks in all unit tests would probably make the test code bloated and tangled. Still, even if people agree with me that such side effects are unwanted, they might have a hard time adapting to a new coding standard that differs from the way they have written code for years now.

Well, I guess (and sincerely hope) I won't find that many serious code smells when digging through the code base.

Time to Change

2006-07-26T15:58:00.000+03:00

Although I think I have been doing too much reading (both books and blog posts) and too little actual development work, I am happy I kept reading and came across a link in Dave Nicolette's blog. It pointed me to James Shore's Change Diary.

One of the most interesting points was somethings James wrote in the "Years Later..." section of "Week sixteen".

"I have not yet seen technology-first achieve significant organizational impact. If I didn't have management support for structure-first or switchover, I would focus on getting management support. At best, technology-first could provide some ammunition for those discussions, but be careful: some technical practices, such as test-driven development, take a while to show dividends. They slow you down in the meantime. Depending on your situation, they could hurt your cause rather than help."

Since my employer is rather far from being agile, I have planned to start using TDD alone first, not pressuring anyone else to do it before I have something to back up my opinion that it will help us. However, if I understood Mr. Shore correctly, this is probably not an efficient way to achieve things. I should try to change the management's mindset instead.

Felicitously, while I was reading the diary, my closest superior came to settle a time for my annual development discussion session. It's now booked, and I'll be sharing some of my views with her on Friday (in a couple of days, that is).

Now I should get some well-prepared points on paper. I'm thinking of talking about automation issues. As a first step, we could put all of our documents in a version control system, so that they're not scattered on our file server directories. I believe this could keep them better updated. I'm also going to ask our customer support team how they make their builds when preparing installation packages. It could probably be done on a daily (or nightly, to be exact) basis. And most important of all, I'll talk about automated (unit) testing, which I already mentioned a year ago.

Let's see if I can get things rolling, or if I should spend even more of my time browsing job ads (I do that already, but not very aggressively).

Team Experience

2006-06-21T17:14:00.000+03:00

I have been reading Hunt and Thomas's The Pragmatic Programmer (which I probably don't have to recommend to anyone anymore) and was pretty astonished when I read the section "Pragmatic Teams" in chapter 8. Everything I read seemed to ring a familiar bell somewhere in the back of my head. And every ring could be translated to "been there, done that"; I was part of a team like that once.

There were four (and a half) of us. We joined the company one by one and worked separately at first. Later, when the company hired more programmers, we became one of two teams working on the company's two (partly overlapping) products. Unofficially, we were the "senior" team, since all of us had worked in the company longer than anyone in the other team. (Nowadays I would say such division is probably not the way to go...) But to many of us, this was the first (IT-related) job and our skills were based only on academic studies and personal spare-time projects.

We still managed to triumph. (When I say "we", I mainly mean the others. Although I did my share of some improvements, I was more like an innocent bystander compared to the others.) Perhaps the biggest reason for this was that things were in a horrible state. There was no source code control system. There were no builds (and I am not talking about automated builds here, but builds in general). There was no way of knowing which version of the product each client had. (Well, since there were no versions, this was quite understandable.) There was no documentation whatsoever on the database tables the products used. I guess nobody liked it that way. Things had just happened when there were a couple of people writing code as fast as they could, and soon most of the work was putting out small fires everywhere. However, even the bugs that were found were not reported anywhere.

The team managed to change much of this. We started using source code control. We started writing small descriptions of database tables we added or modified, and put those in a common binder. (It would have been better to use plain text documents and store them in the version control system, but at least we did something...) We built a small intranet that included a bug-reporting service and a bug database. The customer service people could add bug reports and follow the fixing process as we assigned each bug to one of us and kept track of its status. Using the version control, we started making builds and keeping track of the versions each customer had. (We also made a proper installation media for the software but I think it was mainly done in the other team.)

We also did things that were not that obvious but which Hunt and Thomas mention in their book (and their book was out by then, so this probably wasn't a coincidence - even though I personally didn't read it back then). We came up with a name for the team and used it in all of our documents, and pretty soon the rest of the organization started using the name, too. We shared knowledge by making small handouts of books we had read and sharing them with other members of the team and everyone else in the company who was interested. We added a page in the intranet where people could write short reviews of new books. We even had names for the builds we were making (thanks to Pekka and his imagination :) ). And we sat together in one small corner of the company office, talking out loud when we faced problems.

Even though we all eventually left the company to find new (and probably not so many) challenges, I can truly say we all learned a lot. And while doing it, we had some serious fun. I can't say I miss working there in whole. But I definitely miss working as a part of that team. *sob*

Abusing TDD genetically

2006-04-24T13:51:00.000+03:00

I recently made a small program as an example of a genetic algorithm. It was a minor school assignment, so the algorithm type to use was set in advance. Trying to use TDD as much as I can nowadays, I once again started writing code tests first.

After learning about how tests should drive design earlier, I now faced another interesting situation. Part of the design (the algorithm type bit) was already set, so the tests should actually adapt to that. I thought about how I should write tests in a case like this, and decided to experiment a little. Instead of writing tests for existing code (that didn't actually exist yet, but was quite thoroughly planned and only waited to be written), I tried to come up with tests that could have forced me to choose the algorithm I had already thought about. I know this was not anything like the approach TDD is meant to motivate, but it was fun - and writing unit tests still really paid off.

I managed to write tests that drove me towards the algorithm I had already partly designed and made the original design, in a sense, justified. Writing really demanding tests also made me improve the original design by showing that some details in the algorithm worked only occasionally as I had meant them to work. "Occasionally" is an important thing here, since genetic algorithms form a partly random approach to finding solutions in large search spaces.

Next I will present some examples of how unit testing helped me while writing a simple genetic algorithm. If you're not familiar with the concept, you might want to quickly browse Wikipedia's article on the subject. If you want to skip that, let's just say the algorithm is all about evolution (of solutions to the problem) and leave it at that. :)

Uncle Bob's blog post Extract Class provided me with a good way to test randomness. For example, I implemented the mutation of individuals so that the likelihood of mutation depended on the fitness of the individual: a perfect individual should never mutate, a strong individual should mutate only with a small likelihood, and a very poor individual should almost always mutate. So, I wrote tests for each case, writing a loop in which I called the mutation control method and counting the number of times a mutation actually happened.

public void testStrongIndividualVeryUnlikelyMutates() {
Individual original = new Individual("88888");
Individual after;
int changeCount = 0;
for(int i=0; i<1000; i++) {
after = new Individual("88888");
after.mutateIfBadFitness();
if(!original.equals(after)) {
changeCount++;
}
}
assertTrue((changeCount < 250) && (changeCount > 50));
}

One of the things unit tests helped me improve was generating offspring for two parent individuals. Since I didn't want the individuals to produce exact copies of themselves (since that would not give me any new information), I wrote a test that ensured the offspring was different from both parents. I was surprised to see the test fail with randomly generated individuals, since I thought a good selection of the crossover point alone would solve this. I soon realised that if the parents had identical "DNAs" on one side of the crossover point (e.g. "123|456" and "888|456"), the offspring would be an exact copy of one the parents. This was really easy to solve by forcing the offspring to mutate at birth, but I might not have found the flaw without a good test.

All in all, the task was fun and educating, although my approach probably added a (big) twist of solid coding horror to TDD.

Doing What I Love

2006-03-22T13:53:00.000+02:00

While doing some study-related research, I stumbled upon a nice article on doing what one loves by Paul Graham:
http://www.paulgraham.com/love.html

Although I might disagree with one or two particular things, I think Graham has some excellent points. Especially his musings on people's motivations sound really familiar and accurate. They reminded me of Terry Pratchett's words: "Too many people want to have written." Luckily the hacker culture probably isn't as tempting as writing novels, and "Too many people want to have written killer apps" isn't excruciatingly true. At least, not yet.

P.S. If someone has read Graham's book Hackers & Painters, let me know what you think about it.

My Agile Week

2006-03-20T15:42:00.000+02:00

Last week was probably more agile for me than any other week has ever been. On Wednesday I participated in my third randori coding dojo, and on Friday I eagerly listened to each of the three presentations in the agile seminar at Kiasma.

The seminar was absolutely great. The first presentation was Vasco Duarte's Team Building and Agile Software Development, followed by Sebastian Nykopp's Test Automation in Agile Development Today and - last but definitely not least - Joseph Pelrine's How Agile Works: Complexity and Agility. Vasco Duarte and Joseph Pelrine talked more about the social and "soft" side of software development. Some of the stuff sounded pretty familiar to me because of my leadership and management studies, but there were also several new things and the familiar ones were now tied to my own trade better than ever before.

Sebastian Nykopp's presentation was more on the technical side, and thus perhaps a bit more challenging to listen to. However, having learned TDD so far only at grass-roots level, it was really nice to see the whole bundle of test automation from FitNesse to the (familiar) JUnit unit tests. As I wrote in my last post, I really should get a grip of TDD on a larger scale, so this presentation really hit a good spot.

I think the presentations gave me some valuable ideas on the ways I could try to get TDD (and perhaps some other XP methods, later) started at my workplace. We'll see.

The dojo on Wednesday was - again - loads of fun. This time the dojo was held at the FifthElement premises, being the first dojo outside of the Reaktor office I have participated in. Although I consider myself as a novice in TDD, I actually started feeling the agony of being on the red bar too long... We stayed "on the red" for over five minutes during some big change, and although (or because of) I wasn't at the keyboard at the time, I almost started feeling uneasy physically, waiting for the green bar to appear. :)

Joseph Pelrine said on Friday "[After RUP,] Agile was like a homecoming for me". I can't say I feel the same, but there's definitely something in the agile ways that I find more and more alluring. I'm already feeling TDD puritanism creeping in, and I really like the feeling.

All design is not BDUF

2006-03-09T15:10:00.000+02:00

I don't use TDD at work. So, the stumbling steps I take on the test-driven path are ones I choose voluntarily while doing (solo) school projects etc. The Coding Dojos of Agile Finland as well as a few skilled friends have helped a great deal but I feel my advancement is still rather haphazard. I also must confess that I have not read even the most basic books on extreme programming. So, many of the things I trouble myself with might be rather evident if I had. Therefore I would be more than happy to hear any recommendations, so I could stop asking stupid questions. (Although I know I won't have time to read anything "extra" in months...)

One of the big things I have stumbled with is writing good tests. This is of course one of the cornerstones of TDD and thus an important thing to learn well.

For me, I think the biggest question in writing tests has been: "Where do good tests come from?" As far as I have understood, the production code should be written to pass the tests. So, writing code after a test is defined should be quite straightforward. And this has definitely been the case with simple examples, e.g. the topics we have encountered in the dojos. While writing entire functional programs I have, however, been a bit unsure what to do and when to do it. Good production code comes from good tests, but where do good tests come from?

I have lately been writing two programs in which I have tried to use TDD. The one I'm just finishing is a naive parser for reading Bayesian networks in Hugin lite form and constructing actual network based on the information read. (Actually, that's only the first part of the whole program, but this is a group effort and we're working independently on different parts of the program - and this part was my responsibility.) Writing tests was quite straightforward; I had the grammar of the input files and could write tests to check the validity of small parts of the input file one at a time. I guess combining this part of the program with the other parts would have been more challenging test-wise, but I am the only one in our group who writes unit tests, so I avoid the challenge here (sadly, I might add).

The second program is a sudoku puzzle solver (yes, I know there are a lot of them already, but this was a good chance to try some AI-related stuff on my own), and here I ran into problems. I started with the smallest thing I could think of: a cell on the sudoku game board. The first tests were really easy to think of; building a constraint-based solving algorithm/strategy would definitely require the cells to know which values were still available to them, so I started by writing tests that removed some values from a cell's list of possible values and checked the remaining values to be valid etc. Soon it was clear that if a cell had all but one of its possible values removed, the remaining possible value was the only valid value that the cell could have, so it should automatically be chosen. Testing and implementing this was easy.

After a while things got hairy. When adding the bigger components of the program, I started writing tests for some particular kind of data constructs I thought I might need. I chose to write tests that would suit the faint idea I had about the inner implementation of the program. Pretty soon I realized I had no idea what I was going to do next. I had a bunch of tests and methods that passed those tests - and I didn't know if I was ever going to need the functionality I had just implemented. Trying to avoid Big Design Up Front, I almost had not designed at all. I had code that would probably remain dead even as the program would get finished.

I think the problem I have has two sides. First, I lack the knowledge and experience to decide what kind of functionality should be tested. For example, should I test some basic file handling routines? (I guess as long as I use the basic components offered by the programming language itself this would be overkill. However, custom error handling and other special functionality probably should be tested.) Second (and I think more importantly), I don't think enough about the big picture; what is unit testing (and agility in general) trying to achieve and why does TDD help to make things agile? Timo Rantalaiho wrote a good reminder in his latest post: "[W]hen doing TDD, we're not supposed to write tests but to specify requirements."

One of my teachers once said that if written academic text isn't clear, the thought behind it was not clear either. I think the same thing applies here: bad code is a sign of bad thinking, and writing code (or a test) when you're not sure what it should do means you're pretty much writing worthless crap. Avoiding BDUF should not mean avoiding design entirely.

Another Setback

2006-02-15T10:45:00.000+02:00

Once again it seems I won't be coding much on my free time in a long time. My plans suffered a serious setback when I found out that the research group I wanted to join isn't hiring at the moment. So, I guess I have to find someone else who is willing to pay me for doing my master's thesis, or the latter half of the year will be a difficult balancing act between work, studies and writing my thesis. That would not leave time for doing any TDD (unless I start doing some serious propaganda at my current workplace and get to use it here).

On Test Coverage

2006-02-10T17:04:00.000+02:00

On Wednesday I spent three hours at Reaktor again, participating in an Agile Finland's coding dojo session for the second time ever. It was fun, and this time I had a particularly good lesson about (lacking) test coverage.

First, a small disclaimer: I don't mean to reprove anyone involved in writing the code that we started with. I can't claim I would have noticed this bug during the previous session myself, if I had happened to be there. I read the code base through before the Wednesday's session and this didn't catch my eye.

Now, to the point. The challenge was to write a poker hand evaluator, and for this, we need a way to construct the hand in some way. This is the corresponding method as it was:

private Card[] createHand(String hand) {
String[] cardStrings = hand.split("-");
List cards = new ArrayList();
for (String cardString : cardStrings) {
cards.add(new Card(cardString.substring(0, 1),
cardString.substring(1, 2)));
}
return cards.toArray(new Card[cards.size()]);
}

This method takes a string representation of a five-card hand, e.g. "DA-D2-D3-D5-D4" (which would be a straight flush from the ace of diamonds to the five of diamonds). The method generates the corresponding Card objects with a suit and a rank. However, there's a small error. A card with a rank of 10 can't be generated, since the latter substring only takes one character to represent rank (and elsewhere in the program the rank was supposed to be "10" - this is also the only card in which the error occurs, since aces are represented as "A":s, and facecards are "J", "Q" and "K", respectively).

The fix was very simple:


            ...
          cards.add(new Card(cardString.substring(0, 1),
                             cardString.substring(1)));
            ...

This error had not caught anyone's eye - maybe because there was not a single test including a card with the rank of 10. To me, this raises a question about the right kind of test coverage to use with TDD. Should there have been test cases with every single card tested? Probably not. But this time taking something - even this simple - for granted resulted in a bug.

Personally, I think one of the points of TDD is not to think you have taken everything into account, but knowing you have done so. (Well, of course programs can never be completely bug-free, but you know what I mean...) To a non-expert coder like me, I guess it's exactly the small things like this that I can learn to use extensive unit tests with. Live and learn - sometimes the hard way.

A Wicked Programming Language

2006-01-26T12:09:00.000+02:00

Sometimes I find "geeky", cryptic coding funny and even interesting. Today I stumbled upon a "Turing-complete programming language" called Brainfuck (see also the corresponding Wikipedia page).

Of course code (or a language) like that is merely entertaining. I would never like to see anything like that in a production code I might have to maintain. (And, pointing to my previous post, I would never advise a novice programmer to see anything like that for learning purposes.)

Still, the language definition put a smile on my face.

FP vs. OOP?

2006-01-25T12:19:00.000+02:00

Because my computer is still being fixed (luckily the repair seems to be covered by the guarantee) - and I can come up with a bunch of similar excuses (like my mail server blocking the invitation to the second/third coding dojo session in Helsinki) - I have concentrated on reading articles and blog entries on programming.

One of the most interesting topics I ran into was the issue of teaching programming to new students. There seem to be two quite strong schools: one in favour of FP (functional programming) as the first thing to teach, and one in favour of OOP (object-oriented programming) in the same role. One of the most interesting articles or publications on the subject was Matthias Felleisen's presentation How to Design Class Hierarchies (pdf, 95 pages - but reading the whole thing won't take more than 10 minutes).

Felleisen raises some interesting points - at least interesting to me, since I started my "academic" programming life with Java.

First Randori Session in Helsinki

2005-11-24T00:00:00.000+02:00

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

2005-11-19T23:20:00.000+02:00

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

2005-11-11T21:33:00.000+02:00

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

2005-11-09T13:15:00.000+02:00

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!

2005-10-31T13:42:00.000+02:00

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

2005-09-30T13:59:00.000+03:00

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)

2005-09-29T17:51:00.000+03:00

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

2005-09-21T15:33:00.000+03:00

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

2005-08-30T23:34:00.000+03:00

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.