Still I managed to keep myself occupied well enough.  I spent most the time experimenting with TDD and writing some useful tools for the team.  It worries me sometimes how I can spend hours on end with my own company and not get bored.  I guess that’s what being an only child trains into you from a young age.

Still amongst all the work I somehow ended up buying a new camera from the local mall.  I decided to go for the Canon IXUS 950 IS which I bought to replace my older (but still excellent) Canon IXUS 500.  I was quite pleased with myself after some extensive haggling I managed to get an extra Canon battery, 2GB SD card, case, and a screen protector for 2300RMB (£165).  However I got the impression she was pretty chuffed too with it all.

On Sunday I decided to give my new camera a work out at Shanghai’s very pretty Yu Yuan Gardens:

I am visiting our extended team in Shanghai and was tasked in cutting their release process by 50%.  After some investigation it appeared a lot of time was spent ‘provisioning’ their builds to the dev/test/live environments.  Our solution was to write a tool to automate the whole process.  They where tied up with their market deliverables so this gave me one week (well 1/2 a week once the jetlag settled) to write the tool.  Immediately I started thinking about enterprise solutions with ASP.NET front end for the whole extended team to use.  Thankfully Craig our software architect rightly told me to focus on solving the problem first and extend it later.

So off I went and broke the problem down into smaller modules.  Once I had a rough idea of what I wanted to do I jumped straight in and solo TDD’d my way through a component that takes our build output and shaves off all dead weight ready for provisioning.  When I was done I was hugely satisfied.. this was a really quality piece of development.  With my unit tests supporting this module I knew it was capable of the job.

However I had just spent over a day developing this component and I had another three or four of the these components to develop to be “done”.  Does this mean I needed more time to do the job? I don’t think so, I think I just lost sight of the agile principles.  Early delivery of working software that gets extended in iterations.

My learning’s from the whole experience:

• Don’t try to solve all the worlds problems on the first attempt.  Pick a simple scenario that might not be suitable in the end but will help ‘build up’ the program.  I know what your thinking… “d’uh”.
• Develop each component in parallel using the above principle so the whole system in developed in unison.  That way if development is cut short at least the problem is partly solved.. and who knows that might be all that was required after all.
• Start with a prototype to prove the concepts before heading into the land of TDD.  Good TDD takes time with great results, but there’s no point if the fundamental principle behind your program is flawed*.

What I cant understand is why I ended up making these mistakes.  I’ve read the books and knew these things before I started, yet I still ran head first into them.  I guess there is simply no substitute to making the mistakes personally and learning from them first hand.

* As is turned out my program wasn’t flawed but in retrospect there was a chance that 2 days worth of work nearly surmounted to nothing had I not been a little lucky.

Now I personally don’t see the advantage of testing private methods as their workings will always have an impact on the public methods, with not too many levels of indirection.  However an internal class is a different thing altogether, it could be a complex piece of functionality that gets used in multiple places inside an assembly. 

Thankfully the .NET guys have realised this to so have given us a command like the ‘friend’ command in C++ to allow a whole other assembly to get access to the internal workings.  Personally I actually think the C++ approach is more robust as it only grants an individual class access but at least it’s a solution.  Maybe the .NET guys wanted it to be clear this attribute was only used for testing assemblies and not for messy its internal to X but not Y scenario’s.

Simply add this line into your AssemblyInfo.cs:

[assembly: InternalsVisibleTo("YourTestAssembly")]

If you don’t want to shell out for the book or you think emotions are overrated then the information is pretty much available on MSDN: Design Guidelines for Developing Class Libraries. 

The major two points that stuck out for me:

Scenario Driven Design

The book hammers home the importance of first understanding how your code is going to be used.  It really makes sense, there’s little or no point in writing a beautiful framework if its usage has not been thought about in the context of the end user.

Scenario1: Accelerate a car then stop it.

Car myCar = new Car();

myCar.Accelerate(100);

myCar.Stop();

Scenario2: etc…

Simple Yet Powerful

One mistake I often fall into is making my code too powerful (read complex).  The book described the importance of your user being able to solve 80% of their problems with simple code.  For example the System.IO.File class accomplishes most of the users requirements in regards to file i/o but in the rare occasion where more power is needed then you have FileStream for all the stream operations to help you.  A very good point indeed.