I blame the testing

| 3 Comments

It's amazing what a day or two away can do. I came back to the tests with a fresh mind this morning and dealt with the issues that had caused me problems at the tail end of last week before I got my morning coffee.

Ok, so I don't take coffee until 11.30. I still think I did pretty good...

I'd written the bulk of the tests on thursday evening. Unfortunately I'd made one of those mistakes that you just can't see until you walk away and come back with a clean brain. The bug involved a cross currency FX forward rate. As usual it was an 'edge case', ie one of the areas that was the most complex in the old version of the code. It was a cross currency from EUR->USD->CHF where there was a CHF holiday on the day that would otherwise be the USD->CHF spot day...

In summary, it was the same problem that we've had problems with for the last month or so, but the names and dates had changed. This time we nailed it; I think...

Throughout the FX testing and refactoring phase we've been trying to reduce the number of lines of code and make what's left more simple and also make what's left follows the way the examples in the text books work. In general we're looking to end up with code that someone can understand without a great deal of thinking. The only comments we have are pointers to the books where we got the calcs from. The rest is named nicely and reads well; if we get a moment in the schedule we may even get some overview docs written (don't hold anything).

So, I'd written a test on Thursday evening and it didn't work and I stayed late looking at it and poking it and not really understanding why it didn't work but needing to continue prodding it.

Today I looked at it and saw the problem; we were testing a particular situation, a bug that happens when there's a CHF holiday on what would be the USDCHF spot day, we'd used our mock objects to set the world to X/Y/2003 and I'd poked a holiday into the system as Z/A/2004... 2004? Ooops.

Once that was fixed I got the results I expected. The test passed as it duplicated the exact conditions for the bug. I fixed the expected results and it failed. We could then run it again and again and again and step into the code to see what was wrong. Not surprisingly it was a bit of code that 'looked unbalanced'... The code looked wrong, we changed it to something that looked right. The tests all worked. We eyeballed lots of other test cases and all was good... Woo hoo!

Lesson learned? When it's late in the day and you get a hard thing to do, go home. You'll do it faster and better tomorrow.

3 Comments

I like to discuss the following lines you wrote above:

"In general we're looking to end up with code that someone can understand without a great deal of thinking."

This is your speciality. I've worked a lot with your source codes related to COM and socket servers. And in most cases there was no need for me to look at the articles, because your source code is mostly self descriptory.

As you mentioned that you write the code in the similar manner that is written in text books.

I also try my best to end up with a code which is easily understandable for the others, but under most cases my destination is failure :( Like everyone we also have tough deadlines.

So, what i refer to write code in easy manner ??

Most of the socket server code was written before I got into test first development. So it's not the test first stuff that makes it readable and understandable...

I try to make functions small. I try to name things in an obvious manner. I try to reduce coupling and have classes just do one thing. Sometimes I get it right, sometimes I don't. I try and accept that I've made mistakes and fix them rather than get all defensive about a decision that may have been wrong. If I have to write a comment to explain a piece of code I try and change the code so that the comment isn't required to understand the code. I practice a lot (well, I write a lot of code anyway). I keep trying to learn, I keep reviewing how I do things. I always accept that I might be wrong and try and improve things.

I've been doing all of the above in commercial programming environments for at least 10 years and before that I was apprentice to and then worked with a perfectionist for 10 years as a builder - these things rub off; I like things to be right :)

One thing that was drummed into me during my apprentiship was that it's always quicker to do things right than it is to do things wrong and then redo them.

So, what can you do? Keep trying and realise and learn from when you get it wrong.

Writing code in modern IDE environments and on powerful machines doesn't require cryptic coding anymore (cf. obfuscated C competitions). Writing 'modern' code is more akin to tell stories. The code should be simple enough to tell you the what. Any comments should explain the why, if necessary. The smaller the function, the easier it is to debug as there is less going on...

Leave a comment