Thursday, November 26, 2009

Readable vs Elegant?

I've been thinking about this for some time but there seems to be a contradiction within the software development community, an internal struggle between being clever and superior and a wanting for things to be clear but succinct.

At DevDays in London, Joel Spolsky showed a code snippet of how you would copy a string in C.

It was something like :
while (*s++ = *t++);
to the untrained this may look like a half finished effort, it isn't and even though the first time I saw it I thought WTF. A second glance and you can see that amongst the terseness it is actually doing something utilising pointers.

So I guess that I would call this elegant code and even though (from my pointerless point of view) it took a second glance I would call this readable code. This is probably a very good example of Elegant yet Readable. We should all strive to write like this but there are cases where we go wrong.

Elegant but not Readable

Above is a 1989 entry for the International Obfuscated C Contest, confusingly it prints e. You cannot deny a lot of love has gone into making in unreadable. I know that's the point but I feel sometimes some developers go out of their way to out smart their peers. Often the author will protest that their peers should know what the code is doing, the implication is that they are superior to their idiot counterparts. It is the ultimate in geek posturing and is done at the expense of maintainability and probably team harmony.

Readable but Inelegant

while (*t != 0) {
    *s = *t;
*s = *t;
I just looked up the antonym of elegant there because I didn't want to use inelegant. After looking at the options I stuck for inelegant but I thought that two of the other suggestions were worth considering.
graceless and unpolished
This code often comes from a novice or perhaps an intermediate user of a particular language someone who is comfortable enough to get by but by no means a master in it.

The code example above is the doing exactly the same thing the original example but is more verbose. At the same time it is perfectly readable but knowing that what you can do in 7 odd lines, does it become graceless and unpolished?

Is Elegant better?

I think when someone attempts to write elegant code there are three levels the code can attain. These are defined by the initial reaction of the reader.

  1. Too much: "Woah wtf is he doing here!?"
  2. Just right: "Ooh that's neat."
  3. Too wrong: "Err this builds but that's it."
Elegance should be harnessing the idioms of the language but when it becomes a form of obfuscation that's when the problems occurs. Yes you may scare the newcomer by using an advanced feature but as long as the intent is clear I see no problem in harnessing all the features of a language. Those features have been designed so your code is more expressive in less lines of code. Provided the language design is good we should take advantage of them.


I decided to write this blog post as I wanted to clarify my thoughts on the matter, I think I've come to the conclusion you should make you code readable at all times but at the same time you can be elegant with it. In fact elegance is something you should strive towards as I believe elegant code shows you know your tools well. There doesn't have to be a choice between readable or elegant. The choice you should make is readable and elegant.

Monday, October 26, 2009

Visual Studio 2010 beta 2 side-effect - SQL2008 autoupgrade

I went wild the other day and installed VS2010 Beta 2 on my development machine.

Without asking it upgraded my \SQLEXPRESS instance to MS SQL2008 fro MSSQL2005.

I then had to jump through flaming hoops to install the update MSSQL Management studio express, installing 2 pre-requisites, Windows Installer 4.5 and Windows Powershell 1.0. (I'm on XP , I hope these are on Vista or Win 7) and then when I eventually could run the installer I perhaps the most confusing installation screen in the world, ever.

I think I went for a full installation on this page and it just installed me Studio, I can't be sure as I went round the houses several times and now I can't even find out how to uninstall the little s***t to test.
R2 Management Objects?

Very naughty VS2010.

It also prompted me to restart mid installation with this gem of a dialogue box.

Remote Pairing - a quick guide

Today I spent most of the most of my morning and afternoon honing my TDD skills with Rob Cooper. Whilst none of the work we did was particularly earth-shattering it was great to delve in code and discuss at length. We tackled a TDD Kata in depth rather than discussing the 'form' elements we concentrated on discussing how the design emerged and the different approaches to testing. We had a few technical issues and ironed most of them out but I wanted to outline the setup as it seemed fairly easy to arrange.

Remote Pair Recipe

  • IDE of choice - (helps if these match)
  • Git - (or other DVCS)
  • GitHub Account - (or other hosted service)
  • Skype/GTalk/Live Messenger - for Audio Comms
  • MS SharedView - see what the other pair is doing

MS SharedView deserves a special mention here as it worked extremely well for screen sharing.


Check your setup

Before starting make sure you can both access and commit to Github. This is the place where you are both going to be passing your code back forth to. Make sure your equipment works (someone in this pair had a crappy mic in his headset - no names mentioned (*cough* - me)). This slowed us down and upset flow a little. Thankfully the other pair was not blameless. If you are going to use other tools agree what they are, including version, before the event so you don't have to spend time scrabbling around the internet for requisite software.

Have a plan

Do not go into a session unprepared. Without a plan a session will lose direction. I think we were over-prepared with things to do but its better to have more than less.

Don't be scared

Having someone watching your every keystroke may seem like a daunting thing but hey you can always have your revenge when its their turn to drive in general you are both here to write better code so if you make a mistake and your pair notices it or if you have a bad habit you should be grateful it is being pointed out. That way you can fix it.

Don't be offensive either

There are many ways to convey that your pair has not removed the duplication in that class other than by comparing his intellect to that of an amoeba. Pick a nicer one.

Swap driver-navigator often

Rob and I swapped mid-scenario in our TDD session. I would red-green (to the simplest possible case) then Rob would grab the session add a further test and refactor. We thought this was a nice way of doing things as we both had our input in creating the feature. I would make the fixture and pass it over to Rob as tested. Rob double checks with a further scenario and makes the call to refactor.

Embrace your differences

Rob and I had a slight difference in our approach to testing. We stopped and talked about it afterwards but it was not a problem in this case as the code was 'throw away'. The issue may have been more pressed if we wanted to keep the code.

Take breaks

I'm ashamed to say that even though Rob and I are both Pomodoro Technique practitioners we took 1 break in the multi-hour session. This was wrong. I found that towards the end of the session I was losing concentration. With pairs I think this especially important due to the intense focus you have with two of you.


We approached the exercise like so:
  1. Driver picks feature
  2. Driver writes test.
  3. Driver passes test.
  4. Driver commits and pushes to GitHub
  5. Navigator pulls from github
  6. Navigator becomes Driver
  7. Driver adds 'confidence' test and refactors.
  8. Go to 1.
As mentioned above this did have a nice side effect of us both touching the same features and meant we swapped often. The code was clean and I hope we both got as much as I did out of the exercise. I'll certainly be doing this again.

Saturday, October 03, 2009

TDD Kata: Do not attempt this alone.

There has been some talk of TDD Katas over the last couple of days on Twitter that I think originated from something Roy Osherove did in his TDD Masterclass. I find the concept intriguing.

So what is Code Kata?

A code kata is a set of programming exercises designed to improve your coding skills through pratice and repetition.

Dave Thomas of Pragmatic Programmer fame describes it as such:
How do you get to be a great musician? It helps to know the theory, and to understand the mechanics of your instrument. It helps to have talent. But ultimately, greatness comes practising; applying the theory over and over again, using feedback to get better every time.
and as a failed musician (through lack of practice) I see sense in it. When you learn to play a piece of music you don't just play it all the way through. You practice parts of it. To attain the skill to play parts of the piece you learn scales or chords and practice them on their own.
So I thought I would have a go at Roy's TDD Kata.

30 mins later

Finished. Would you believe I finished within 30 mins? (Note: my 1st attempt at this kata was a cutdown version but I crammed everything into the allotted time, just!
That leads me to one conclusion, I MUST BE AWESOME.
So there we have it. I've'done' Katas.
In the next blog I'll be talking about

But what exactly did you do?

Oh yeah what did I produce? Well I got it reviewed by someone hot out of Roy's TDD course and it had a number of issues. It seems that over the years I have picked up a couple of bad habits. It was like I was playing the tune but holding the instrument upside down. So I swapped reviews with the reviewer and attempted to try again using the feedback I was given.

I didn't even get halfway through it! :(

This is great I've got lots to learn now. I can improve my process and really learn how to Test Drive my code quickly and effectively and also improve on the actual code itself.

But then I read Roy Osherove's blog entry on the kata and I'm confused. Roy says:
The point about the Kata is that you should know it by heart. you should not be thinking about the solution, your fingers should by typing it "blind", including all the refactoring work, the renaming and whatever else you do.
So am I blurring the intent of the kata? By reviewing the code and improving it am I breaking the ethos of the kata? If the pupose of the kata is getting to know your tools and output better, then surely the most productive way is to have snippets at every section. Or to be utterly ridiculous to just copy paste the code in.
The idiot programmer like me will just be practising its awful solution to the problem and will be blissfully ignorant in the fact that it is improving its craft. And yes it may be able to do it in under the allotted time but when someone else comes to pick up its code, they may well spend a lot longer sorting out the unorthodox way it was done.
This is obviously wrong.

Not a solo activity

Its plain to see that you need a someone else to see where you are going wrong. Where you can improve even if that someone else is you! Do a retrospective, read a book on "cleaner code" or perhaps on the "art of unit-testing"? (No books spring to mind right now - I'm sure a web search may bring some up though).
If you do have the luxury of another person be subjective about their critique, they may have things you disagree with but try not to take it personally.

An improved kata?

I love the idea of the kata but I can see where I could go horribly wrong.
What I would like is the idea of a community kata. A bunch of developers do single kata over a fixed period, say a month. Over that month each time they complete the kata they commit it to a version control system where the other devs can access it and review the code. An annotation of tips and hints (e.g. was mouseless, used this snippet) is included in the commit notes so everyone can compare techniques. Time to complete would be a nice to have but more importantly an indication of improvement of time would be preferred. My single finger seeking typing my not be 150wpm but I if improve by 20% that would indicate my other methods are working. At the end of the month the developers can choose to stay on or try another.

I'll be doing more kata as I think it's a great concept in the right circumstances. You want to improve your ability to use your tools but if your music is crap...

Friday, September 18, 2009

Why should I break when I'm in the zone?

In one of my Pomodoro Technique rants on Twitter one of the reservations on using the technique was not wanting to stop when in the 'zone'. It's a compelling point, why would you want to break when you are a fireing on all cylinders?

I guess that fact that you don't want to stop is that getting to that level is an infrequent event. More often you are out of the zone rather that in it. Ask yourself that after a sustained period of being in the zone, how do you feel when you finish?
  • Elated, exhausted, in need of rest and perhaps a reward. 
  • You should be feeling pleased with yourself and rightly so.
  • You have achieved a great deal more than normal probably without distractions and this is true productivity
  • You are probably running in overdrive.
You are the hare.

The key with the Pomodoro Technique is that you are working at a sustainable pace. By having regular breaks you keeps you overall productivity up. By managing interruptions you get defined segments of  true productivity.  The technique helps when you are not in the zone. When you get into the rhythm of the Pomodoro Technique the breaks are part of your flow. The symptoms are like the zone but longer lasting.  You may not get as much done over a day but over a week, a month the results will begin to show.

You are the tortoise.

Another way to look at it is weight training. A weight trainer does not build his muscles by lifting a 200kg weight for 5 mins. He does a set of  reps and then rests his muscle before he does another set. If he does too many he will tire himself and lift less.

Pomodoro Talk at NextGen Manchester

I did a 'nugget' (small talk) at NxtGen Manchester on the 16th on the Pomodoro Technique. Thanks to all that patiently watched while the main act arrived, I really enjoyed it!

I've put the slides on

And embedded them here!

Thursday, September 10, 2009


Renzo Borgatti has a Pomodoro presentation on Vimeo where he talks about do a retrospective pomodoro at the end of the day. In this 'pomospective' he asks the following questions.

  • Were any tasks noticeabley over/under estimate?
  • What went good/bad?
  • Am I respecting breaks?
  • Can interruptions be avoided?
  • Is rhythm established?
I am finding it difficult to do these at the end of the day so I am doing them with in a set break.

Am I respecting breaks?

Errr no.

Renzo's Slides from the presentation.

Tuesday, August 25, 2009

Selling my soul for a free TDD course?

I just read this on a blog I follow and normally I wouldn't do this but I really want to go on this course... so for that reason here bbits have a peace of my integrity. Oh and one more thing... #Moonfruit.

Roy Osherove is giving an hands-on TDD Masterclass in the UK, September 21-25. Roy is author of "The Art of Unit Testing" (, a leading tdd & unit testing book; he maintains a blog at (which amoung other things has critiqued tests written by Microsoft for MVC - check out the testreviews category) and has recently been on the Scott Hanselman podcast ( where he educated Scott on best practices in Unit Testing techniques. For a further insight into Roy's style, be sure to also check out Roy's talk at the recent Norwegian Developer's Conference (

Full Details here:

bbits are holding a raffle for a free ticket for the event. To be eligible to win the ticket (worth £2395!) you MUST paste this text, including all links, into your blog and email with the url to the blog entry. The draw will be made on September 1st and the winner informed by email and on

P.S. Roy did a great videocast of reviewing the tests for NerdDinner. You should check it out:

First Pomodoro of the day.

My first pomodoro of the day is always a 'Plan and Catch up' session.

I begin by checking the results of the previous day's pomodoro and count up the number of full pomodori achieved. This I can use to as a guide of how many I will achieve today. I then do my equivalent of a daily scrum with my team and then can begin to plan my day.

Lets say yesterday I completed 9 pomodori. I allocate nine spaces. Following the meeting I realise that Abdul needs a code review and so I can allocate say 3 pomodori to that task and a quick look at my email shows that I need to speak to Donna about testing a feature. I'll allocate 2. I can now see that I only have 4 pomodori spare. I'll look at uncompleted tasks from yesterday and my active inventory list and pull the the most important ones (or the ones I can finish within those 4). Yesterday was a disruptive day so I hope to achieve more than 9, in which case I will just pull more from the active inventory list as appropriate.

Tuesday, August 18, 2009

SQL union Gotcha! Its a feature.

I spoke last time about the strange behaviour if SQL where if you run

SELECT 'X' AS line
SELECT 'X ' AS line

you will only get 1 value returned.

Well this is not a bug apparently it's a feature of the ANSI SQL-92 standard.

From section 8.2

 If the length in characters of X is not equal to the length
in characters of Y, then the shorter string is effectively
replaced, for the purposes of comparison, with a copy of
itself that has been extended to the length of the longer
string by concatenation on the right of one or more pad char-
acters, where the pad character is chosen based on CS. If
CS has the NO PAD attribute, then the pad character is an
implementation-dependent character different from any char-
acter in the character set of X and Y that collates less
than any string under CS. Otherwise, the pad character is a

Blimey so SQL pads the shorter string with spaces!

Thanks to StackOverflow for that one.

Friday, July 24, 2009

SQL union Gotcha!

This one got me the other day. What would you expect the following to return?

SELECT 'X' AS line
SELECT 'X ' AS line

Notice the space in the second SELECT.
Well apparently SQL 2000 and 2005 both return 1 result. Even though its a UNION (and not a UNION ALL).

There is nothing I can see in Books on line about this. Why does it happen? I'm guessing it's a bug.

EDIT it's NOT a bug. See my follow up to this post for the reason why.

Monday, June 29, 2009

The Pomodoro technique first impressions

Hold on. *sound of winding, now a quiet ticking in the background* I am a born procrastinator. I've got a fabulous talent of nearly doing stuff but then just looking at something else that is slight related. It's a talent that I've honed over the years and I am proud to say when it comes to not quiet getting things done, I've cracked it.
However this talent of mine is not seen as such by my employers, partners or friends. They often get frustrated that whilst I'm polishing the cat or trying to create extravagant latte art, I should be doing X. So in an attempt to placate the angry mob, I have been looking at was to keep my wandering attention under control.


The first thing I tried was the eat that frog approach. The idea is to do the worst/biggest priority thing on your list first because once you've done that you'll feel better. However the biggest thing for me always seemed too big to do. I didn't break it up. Also the todo list was growing bigger and bigger. So I wouldn't add to it until I had cleared enough items off. This was worse that ever! At least with my method of doing all the little things first something was getting done. Now nothing was happening!

Getting things done

Then I thought I would read Getting Things Done but the big problem about that book is that its long and dry and yes I never got around to finishing it. The main point was that all this stuff is piling up in your head causing you to function sub optimally. So either Deal with it, Defer it, Delegate it or Delete it. Then there is some complicated filing system, blah blah blah... ooh look a cat on the internet!

The trouble is that I'm like a goldfish or a pigeon or whichever one gets distracted easily (forcing myself not to search wikipedia for said beast). What I needed was a short, sharp, shock some clear instructions and I think I've found it.

Tomato Time

Whilst on a yak-shaving hunt brring. Ok back in 5 mins.

Tomato Time

So as I was saying on whilst on a yak-shaving hunt I discovered a blog entry Pomodoro Technique in 5 minutes and because I had nothing better to do I read it. It seemed so simple.

All you need is

  • some paper

  • a pencil

  • and a timer
The idea is that you time box your work into 25 minute periods (pomodori). Even if you finish early you must continue with that task until the time is up(over learning). Once you have finished a pomodoro you put an x next to it on your sheet of paper, take a 5 minute break and then choose to continue or pick another.

First Attempt

Did I tell you I was easily distracted? Well I am. In this pomodoro (I'm writing this blog with) I've nearly wandered off into cyberspace twice. My first Pomodoro was not successful I managed two glorious minutes of unadulterated concentration.


Someone was talking in the office an I went and googled something related to the conversation and then ended up joining in. Wow that's just embarrassing but it is the first step. I realise 10 minutes in that I've interrupted myself. I take 5 minutes and start the timer again.

Second Attempt

The two minute mark comes and goes my mind is trying its hardest to jump to something else. My task involves some problem solving and I want to do something else, anything else other than knuckle-down. I almost feel like I am craving for distraction, like I would crave for a cigarette. Its mind-over-twitter right now for me and I continue checking the clock every 2 or 3 minutes or so. Who knew that 25 minutes on one thing could be so difficult? At last the timer rings. I get a few strange looks from my work colleagues but I am triumphant. I mark an x next to my task.

End of first day

There are 7.5 hours in my working day. So I should be able to do 13-14 pomodori a day. I've achieved 5. I think I should feel discouraged but I don't. I can see what I wanted to achieve and how much time I've spent uninterrupted on it. I feel control.
Its time to reflect. What have I gained from from breaking up my day in to smaller pieces?

I just didn't realise how much I suffered from interruptions (both internal & external). I regularly get rung up, emailed or called out from doing my main task. It's part of my job but there's the other side of completing original tasks too. I need to find a balance for these. Internal interruptions are a factor too. I find it easier to get up and make a cup of tea than sit-down and just think. I use things like the kettle as a crutch.

People on the whole don't mind being asked to wait until later. When someone does ring up I can polite tell people I'll get back to them and there is no fuss.

Writing down how much time you have spent on a task gives you a clear record. With all the interruptions you may feel you have spent a couple of hours on a task but if you have been distracted it is not quality time.

There's more...

There is more about the Pomodoro Technique than I've mentioned in this post specifically in terms of record keeping and process improvement. They are important but not a requisite to first attempt the Pomodoro Technique.

Sunday, January 11, 2009

Cryptosystems intro.

I've been study at cryptography recently so I'm going to jot down a few notes from my course.

Why do we need cryptography?

  1. To keep information secret (confidentiality)
  2. To ensure that the message is the correct and has not been altered (integrity)
  3. To verify that the sender of the message is who he says he is. (authentication)
  4. To prevent the sender denying it was he who sent the message and the receiver claiming she had not received the message (non-repudiation)
So there's a fairly broad range of requirements. However it seems we can achieve these goals though just 2 classes of encryption algorithm.

Types of Encryption Algorithm


This type of algorithm works because both the sender and receiver both share the secret key.

M(Plain text) --> Encrypt(K) = C (Cipher Text)

C --> Decrypt(K) = M

It doesn't matter if the algorithm is public knowledge as the key is er.. the key.


Sender encrypts with receivers public key receiver decrypts with private key.

M(Plain Text) --> Encrypt(Ke) --> Cipher Text (C)

C --> Decrypt(Kd) --> Plain text.

{Ke,Kd} are a pair

More on Symmetrical Cryptosystems

Examples of single key algorithms include:
  • DES
  • Triple DES
  • AES
  • IDEA
  • RC5,RC6
  • Blowfish

My very simple symmetrical key cryptosystem.

The concept of symmetrical key algorithm isn't hat hard to get you head around lets take a very simple (contrived) example.

My plain text message

|J|O|H|N| can be translated to its order in the alphabet |10|15|8|14

Then we can encrypt them with our secret key. Lets xor them with the secret key 7.

|13|8|15|9 --> |M|H|O|I|

So this provides us with some protection.

MHOI does not look like JOHN and even if the hacker knows we XOR the message and convert into numbers he will have to guess our secret key.

Of course this example is terrible.

There are several reasons why.

To design a Symmetric Cryptosystem we should follow these criteria.
  • Cipher text should depend on the plain text and key in a complex manner (confusion)
  • Each part of the cipher text should depend on all of the plain text and all of the key (diffusion)
  • Small changes to input data should cause many changes in output. (Avalanche effect)
So my encryption algorithm fails on the last two (and arguably the first).

We can look at a better example with DES (Which I will continue in another post.