My [Unit] Testing Epiphany

In my recent post “TFD vs TLD – What’s the Definition of ‘Later’?” I alluded to a state of arrogance that was subsequently punctuated by a fall from grace and a sudden realisation that my testing strategy was in fact fatally flawed. The outcome was a new found appreciation for Unit Testing in its modern guise. Since then I’ve tried to guide other developers along the righteous path in the hope that they could be spared the pain of my embarrassment, but I’ve come to believe that it is a Rite of Passage because the benefits are largely downstream which makes the upfront costs feel excessive, especially when the clock is ticking.

Anyway, so how did I reach a level of complacence and arrogance that caused me to dismiss writing formal unit tests as a waste of time?

My professional career started out in the early 90’s at a small software house writing graphics based desktop applications. The great thing about graphical software is that you can see whether something works or not. Of course, off-by-one pixel and colour errors are difficult to spot, but by and large you can test the application manually and get good results. The culture at the company was strong on reading and we used to have copies of DDJ (Dr Dobbs Journal), MSJ (now MDSN Magazine) and WDJ (Windows Developer Journal) on rotation. I was also encouraged to read Steve McGuire's Writing Solid Code and Steve McConnell's Code Complete – two books which I found awe inspiring and I think others in the company did too. There was already a strong desire to produce quality software and many of the techniques in the books were adopted to ensure an even higher level of workmanship*.

This is a list of some of the core techniques that we adopted and that I’ve pretty much carried on to this day:-

• Compile with the highest possible warning level and report warnings as errors. Then, where possible, fix the code and not the compiler to ensure it builds cleanly.
• Use ASSERT to verify pre-conditions, post-conditions and invariants in functions to highlight bugs as soon as possible.
• Don’t code defensively. Fail fast and loudly to give yourself the best chance of finding and fixing bugs.
• Step through code changes in the debugger to verify that it does what you think it should, paying special attention to edge cases like loop termination conditions and branches to ensure your testing gives good code coverage.

The one item most relevant to this post is probably the last one - using the debugger to verify what you’ve written. I’ve followed this religiously as it made perfect sense to me. Why do a dry-run mentally or use print statements when you you can do a live run and inspect the state with the debugger? The most significant side-effect of this practice though is the need to be able to invoke relevant code in the debugger with ease so that the code/build/test cycle is as short as possible. This in turn often lead to the creation of test harnesses and diagnostic tools with a narrow focus that also really helps with support issues. So, if this was proving to be pretty successful, why change? Because the key thing missing is repeatability, and this is where I came unstuck...

Fast forward a few years and I was writing a very simple but fast XML parser and as a by-product I knocked up a noddy GUI which not only allowed us to edit the kind of simple XML data fragments we were dealing with, it also acted as a nice test harness because all the libraries' features could be exercised via the various GUI functions. One day I did a little refactoring, and after making some minor changes and running through some tests, I checked the edits into the source repository, safe in the knowledge that I’d improved the quality of the codebase a little. Some days later a colleague (who had been introduced to unit testing at a previous company and was trying to spread the word) announced to the team that his “unit tests were failing”. These tests were for a library that no one had touched in ages, and due to there being no Continuous Integration or automatic running of this test suite, it wasn’t as simple as picking on the last few check-ins. A quick spot of debugging later and the finger was duly pointed - at yours truly…

In my ‘supposedly’ low-risk spell of refactoring I had managed to replace a line something like this:-

return Decode(m_reader->ReadTag(blah, . . ., blah));

with one that no longer called the Decode() method which parsed and replace entity references like & and ' :-

return m_reader->ReadTag(blah, . . ., blah, blah);

This should of course have been caught in my testing, but it wasn’t; because I was foolishly under the impression that my refactoring couldn’t have had any impact on the handling of entity references. Secondly I also apply a policy of diff’ing every single change before checking it in to ensure that I don’t mistakenly check-in temporary/commented out code and to give me a final pass to sanity check that I’ve not missed something crucial. My expected change was at the end of the line, but somehow I’d missed another accidental change at the start. It was during the subsequent discussion with my colleague that the light-bulb went on and I realised that I was (a) far more fallible than I had come to believe and (b) that I could in fact make subsequent changes faster and more accurately because of the scaffolding that would already be in place. Although the failing unit tests were not for my XML parser (he was just using it to load test cases and one of them had an “&” in it) I fixed the code and quickly re-ran his test cases to verify my fix and allow him to continue his work.

Actually he had explained to me some months before about xUnit style unit testing and even showed me how to use CppUnit. My objection at the time was the volume of code you appeared to need to write just to test a simple function. Quite frankly I thought it was laughable that a Senior Software Engineer should need to resort to such verbose tactics to test their code – I felt I could test far more efficiently my way. Granted you don’t get some of the ease of use with C++ and CppUnit that you do with the Java and C# variants but the time spent physically writing the test ‘shell’ is probably marginal in comparison to that spent designing and writing both the code under test and the test itself.

I guess my mistake was being unaware of the true costs of maintenance – especially on large systems that have a regular turnover of staff/contractors. Yes, I may have written the code initially and will likely perform the first maintenance due to my familiarity with it, but longer term someone else will take over. It also greatly benefits the schedule if anyone can just dive into any code. Often there is little documentation so you have only the source to go on and unit tests provide a way for you to roll your specification into your codebase. The future maintenance programmer will then not only have some sort of spec to work from but will also have a purpose built regression test suite on tap to which he only has to write any additional tests or maybe refactor some existing ones. What they absolutely do not have to do is start from a blank sheet of paper. Now throw into the mix the fact that computers are a far better tool for performing mundane tasks like regression testing, and as long as you follow the advice about ensuring your tests run quickly, you can get excellent test coverage and feedback within a very short period of time. Automated building and running of test suites is de-rigour nowadays and wrapped up inside the concept of Continuous Integration. Roy Osherove (author of The Art of Unit Testing and the excellent ISerializable blog) covered Automated building and Continuous Integration just recently in his blog.

I’m sure some would argue that my example above wouldn’t have been found with a unit test, but would be classified as a component-level test; the definition of “the smallest testable part” depends to a degree on how much your design allows for fine grained testing. Either way the code did not require any expensive external resources, like a database or network connection, and so could have been subjected to a barrage of tests that would run in the blink of an eye, even on hardware of that era. I would then have known almost instantly of my mistake. Better yet, the suite of tests would also have provided my teammates the courage needed to allow them to perform similar surgery in the future.

 

 

*Unfortunately it seems that the magazine reviewers cared little about quality, or never tested the products significantly enough to notice poor workmanship. The evidence of this was the market leader at the time getting high marks for a product that was buggy and unreliable. Yes it had lots of features but you had better save your work regularly. This was during the ‘90s and whilst GST is no longer in business** the market leader continues to this day – so much for taking pride in ones work…

**What was originally Timeworks Publisher, and then PressWorks is now I believe called Greenstreet Publisher. I worked mostly on it’s sister product DesignWorks - a line-art drawing package - and the bundled utilities SnapShot and KeyPad.

WCF Weirdy – NetTcpBinding, EndpointIdentity and Programmatic Configuration

We are now using WCF for our inter-process communication (IPC) mechanism, and as you might expect the development and testing on a single machine worked a treat. However once we deployed it to our test environment in a proper remote client/server scenario it stopped working. I wasn’t involved in the main work, but as it appeared to be security related and I’ve done a fair bit in the past with DCOM and security I thought I’d see if I could lend a hand.

The architecture is (as Juval Lowry describes in his WCF Programming book) a classic Intranet setup, i.e. a client and server talking using the WCF NetTcpBinding and with all settings at their defaults. This meant that in our environment I expected it to pretty much mirror the run-of-the-mill DCOM model, except that we hadn’t got quite as far as running the service end under a “system” account yet – both client and server were still running under the same user account. The error we got from the client end was:-

“A call to SSPI failed…The target principal name is incorrect”

The initial Google search for this error threw up a very useful post from Scott Klueppel. The only problem was that we weren’t using configuration files, we were configuring the endpoints programmatically. Whilst I was googling my colleague ploughed through the MSDN documentation and found that using the constructor overload of EndpointAddress that takes an EndpointIdentity also seemed to do the trick:-

EndpointAddress endpoint = new EndpointAddress(uri, EndpointIdentity.CreateSpnIdentity("MACHINE\ACCOUNT"));

This tied up nicely with what Scott said is his post about needing an identity, but not entirely, because he mentioned that an empty identity will suffice. However the MSDN docs and many other Internet posts go intro great detail about crafting a service name string and using SetSPN to publish it to Active Directory. Naturally he followed the official documentation and it worked. To humour ourselves we also tried an empty string and that worked too! In fact it didn’t matter what we passed as the string to CreateSpnIdentity() – it worked. This just seemed way too random for my liking so I dug a little deeper to see if I could find out why this was happening. After all, if the contents of the string don’t matter, why bother passing it? And although it may not matter now, will it later down the line when we’ve all forgotten about this episode? That’s not the kind of maintenance nightmare I want to be responsible for.

Fortunately I discovered the answer via a couple of MSDN articles about WCF and Authentication – Overriding the Identity of a Service for Authentication and Service Identity and Authentication. The latter contained the following crucial note:-

“When you use NT LanMan (NTLM) for authentication, the service identity is not checked because, under NTLM, the client is unable to authenticate the server. NTLM is used when computers are part of a Windows workgroup, or when running an older version of Windows that does not support Kerberos authentication.”

I’ve yet to work in an Enterprise that relies on Kerberos across the board. I’ve seen it used in some parts of my clients’ network* but by-and-large NTLM still lives. I did search for a utility that might help confirm my suspicions, but I didn’t find anything. I know it’s famous last words, but I don’t see any reason to doubt this as the answer.

Long term the whole SetSPN thing seems like the way to go, but it will complicate our deployment procedure so I wanted to see if the articles had any other useful nuggets that might guide us towards some middle ground. As a footnote to Scott’s advice the MDSN articles have this to say about empty Identity strings:-

When SPN or UPN Equals the Empty String

If you set the SPN or UPN equal to an empty string, a number of different things happen, depending on the security level and authentication mode being used:

• If you are using transport level security, NT LanMan (NTLM) authentication is chosen.
• If you are using message level security, authentication may fail, depending on the authentication mode:
• If you are using spnego mode and the AllowNtlm attribute is set to false, authentication fail.
• If you are using spnego mode and the AllowNtlm attribute is set to true, authentication fails if the UPN is empty, but succeeds if the SPN is empty.
• If you are using Kerberos direct (also known as "one-shot"), authentication fails.

We’ve temporarily gone for the first option and filed a JIRA task to revisit this before our deployment procedures need finalising. This also gives me more time to read up on the subject of WCF authentication. I own a copy of Keith Browns Programming Windows Security which has served me well, but it’s finally starting to look a little dated.

 

* It’s a good way of find out if your clock is in sync or not. I once investigated a bunch of authentication failures on some of our VMware test boxes and it turned out to be because the clocks had drifted outside the 5 minute window that Kerberos allows.

TFD vs TLD – What’s The Definition of “Later”?

The fallout from Joel Spolsky’s “The Duct Tape Programmer” post still seems to be reverberating around the blogosphere. The dust has largely settled and Uncle Bob has resumed normal service on his usual insightful postings about testing etc. For a moment I thought he had gone way over the top and become excessively evangelical - even for him. He seemed to suddenly become a one man crusade to restore balance to the force and recruit legions to the cause of TDD. I saw him in person for the first time at the ACCU Conference last year and found him a truly compelling speaker.

As often occurs with a controversial issue such as this I discovered lots of useful discussion in the comments to his post, which I personally lapped up because I have only really been able to dabble in Unit Testing and TDD due to working on legacy systems with massive coupling. Also there were plenty of TLA’s flying about such as TFD (Test First Development), TLD (Test Later Development) and TDD (Test Driven Design/Development) along with BDD (Behaviour Driven Development) and DDD (Domain Driven Design) thrown in for good measure to keep any idle spectators on their toes.

The most useful post for me came a few days later when Uncle Bob (Echoes from the Stone Age) started to discuss the types of problems that you cannot tackle with TDD. This was hugely enlightening because this list pretty much mirrors a large part of what I do day-to-day. I felt somewhat relieved that I haven’t been “not getting the point” so much as attempting to squeeze the proverbial square peg into a round hole. And before you ask, it’s not that I haven’t mocked my interfaces to reduce my dependencies etc, it’s just that I don’t write a lot of what you might traditionally call Business Logic. The logic I do write is often heavily dependent on I/O, threads or 3rd party systems which pushes one more towards the ‘Functional’ rather than ‘Unit’ side of the testing spectrum to find real value.

Anyway, the one part of the discussion which I never felt was truly resolved, or that even the warring parties seemed to clarify their position on was what is the definition of “later” in TLD - Test Later Development. I got the general impression that some of the commentators had visions of old-school Waterfall style development where the “later” meant weeks, months or even years after coding had been completed. Does anyone really work like that these days? Did anyone really work like that? Certainly in my career to date the notion of “later” has pretty much meant seconds to minutes, with an hour on a rare occasion. I cannot imagine ever writing a non-trivial piece of code and not testing it in some way immediately. Yes, my tests may not have been truly exhaustive, but I do know that when a piece of code I wrote failed it was probably due to some fairly non-obvious scenario. I realise that sounds incredibly arrogant and I’m going to document my fall from grace in a follow-up post…

What was clear from the comments was that everyone in the discussion agreed that Unit Testing is A Good Thing – for some definition of unit testing. However it did also highlight that there is still much confusion about the various different forms of testing and what people call them. Some did not distinguish between TDD and Unit Testing which raised the ire of a few commentators. I myself have found the definition of “Unit” to be incredibly vague especially when trying to apply it to other development disciplines such as database scripts. I worked on a legacy system once where, due to the high level of coupling, the smallest testable unit was an entire .exe component.

I think I’m now beginning to “get” the TDD philosophy, but I’m not entirely sure it fits my style of working for two reasons. The first is that I have always found very lightweight modelling (in the way that Martin Fowler describes it as sketching in UML Distilled) to be incredibly useful for visualising a design first. The second is that I have 15+ years of experience to draw upon which means that many aspects of a design are in the realms of boiler-plate code. I find it very disruptive context switching between the boiler-plate and test code when I just want to rattle out the bog standard stuff first and use TLD to add the unit tests after. I can therefore save TFD for the new territory even though I often have a pretty good idea of where I’m heading because that’s why I sketched out the design in the first place. I’m sure it’s a fatally flawed argument and maybe I need to let go of the up front sketches and trust that I’ll still find my way via TDD and discover other benefits along the way. Old dogs can learn new tricks - you just have to tempt them with the right sort of biscuits.

Maybe I’m being too literal (it’s one of my more annoying traits) and perhaps we should just avoid the use of the TLD acronym and instead use TMLD (Test Moments-Later Development) and TMLD (Test Much-Later Development). Oh, wait, that won’t work… How about TRAID (Test Right After Implementing Development) and TAYFHIWD (Test After You’ve Forgotten How It Works Development). Hopefully there will be another TFD vs TLD flame war real soon and I’ll get the chance to fill in some more blanks and gain a further understanding of the Software Development Process. Heck, why am I waiting? Surely I can bait Uncle Bob with what I’ve just written… Now then, where’s his blog hosted again…

Company-Wide IRC Style Chat & Messaging

The big thing that I’ve missed at my current client is the lack of a company-wide IRC style chat or messaging system. I work in a team of 6 and we are all relatively new to the company. Even though we nearly all sit together, we still use IRC as a collaboration tool to simplify broadcasting those temporal messages like “I’m going to restore the database in 5 minutes” or “bouncing the XYZ service because its gone AWOL”. It also has that Channel 9 feel that helps promote transparency to our managers. But it’s only our team using it. Maybe other teams within the organisation have similar setups, but I have no way (that I know of) of finding out. Ideally we should all be tapping into the same IRC server and creating global technology and project level channels – exactly what was done at my previous client…

Mind you this system wasn’t in place when I joined it. The company was using email based “forums” (aka distribution lists) which are horrible to use - you post a question and get 2 answers and 500 Out-of-Office replies! The turning point was when the company dropped the email forums and pushed the IRC style client out to everyone (I believe it was optional before) making sure it ran on start up so everyone would notice. It quickly grew in popularity and even though I was unconvinced at first, I soon became a huge supporter when I discovered the global channels for everything from C++ to XML to Agile to D. Oh, and there was even an ACCU channel :-) In fact it was through the C++ channel that I found out all about the ACCU and ended up joining.

The main problem I’ve found with many Internet based forums is that the turnaround time on getting an answer was too long, and even then you probably ended up getting a n00b answer that missed the point. StackOverflow, which is a superb online resource that trumps nearly all others, is still not immune to this syndrome. The beauty of the company-wide chat was that you nearly always got an immediate response and you could explore the entire problem incredibly quickly because the time spent by all channel members was in the interest of the company. You also had the luxury of switching to the more old fashioned methods like the telephone or meeting face-to-face.

Even as a passive observer you got a real feel for what other teams in the company were doing, such as what tools they were using or what methodologies they were applying. In one particular case I was trying to get a more modern approach to unit testing the database code off the ground and I quickly found some allies trying similar ideas in other teams. We also used the chat tool to get a company-wide shared code repository off the ground to promote more reuse (or at least higher visibility) of in-house developed components.

Naturally there was one channel that was used for less business-like reasons, although it was carefully named so as to not appear to be for idle chit-chat, and by-and-large it wasn’t. The topics certainly weren’t about the business itself, but it was still mostly IT related and added value of a different sort – a much needed social element. We all knew that the channel content was persisted and that “The Powers That Be” could mine that information if needed, but that was probably all that was required to ensure conversations didn’t spiral out of control. That latter feature of persistence and the subsequent ability to find previous conversations through a web style service proved to be incredibly useful. Quite often you’d get similar questions and it was trivial to redirect that person to the search facility with a clue as to when and by whom it might have been discussed. Of course you’d have hoped they had done that first…

The main reason that I’ve sorely missed the company-wide chat at my current client is not to find out what the quality of the canteen is like but exactly because I’m working on a greenfield project and we have the ability to choose our technologies and practices. The “Email Fair Use Policy” is probably quite easy to find on the Intranet – assuming it hasn’t already been shoved in your face – but the details of what tools are proscribed for use in-house is often much harder to source. For example what SCM can we use? What version of Visual Studio? CruiseControl or Hudson? We wanted to find out what tool-chains other teams were using to ensure that there was a critical mass within the company of developers with those skills in case we got stuck. It’s also an excellent way to discover those people who seem to have their finger on the pulse and knowledge of what technical directions the company are pursuing.

I’m sure this isn’t an easy sell to the CIO/CTO as IRC doesn’t exactly have a good reputation – being lumped in with the other social networking pariahs like Facebook and Twitter - but I felt as though it made a significant difference to my work as I didn’t just have my own team collaborating with me but the whole company.

Why is C++ Getting Left on the Bench?

During my recent 6 month sabbatical I spent some time soul-searching. Not searching my soul mind you. Nope, I was trying to fathom out where the future of C++ lies, with respect to the corporate/financial world – the pond in which I swim. As I prepared to return to work again some 4 years after last looking for a new contract, there was a distinct lack of C++ roles. Well, duh!, there’s a global recession, which means there isn’t much of anything at the moment. But it felt like there were far less C++ roles than there should have been. To make matters worse I was interviewed for my current role on the premise that it was for C++ development, but before being made an offer it switched to being a C# role. I was still offered it, even though I have no previous C# experience, which is fortuitous for me as it gives me the opportunity to retrain in C#/.Net on-the-job.

But, why should a Greenfield project, and one which many would consider in the past to be perfect C++ fodder (distributed computing), change direction? I experienced a similar effect during my last role. There was, for a brief period, a concerted drive to try and implement as much as possible in C# instead of C++ because it was perceived that they could deliver value so much quicker. Of course the comparison was largely the usual apples vs oranges affair, as they were comparing the time it takes to make changes to a “10 year+ waterfall developed legacy C++ system with 0 unit tests” against a “Greenfield agile developed C# based web service designed with testability in mind and a full unit test suite to boot”.

A recent thread on an ACCU mailing list has furthered my concerns about the potential future markets for C++. It was actually a question about why so much development continues in straight C, when C++ is “clearly” a better choice. Although I’ve never worked in the embedded market, I gather from the various discussion threads that tooling plays a significant part in its lack of adoption, especially with respects to the more heavyweight features like RTTI, exception handling and template meta-programming. But there also appears to be a level of paranoia that surrounds C++ code, no doubt due to the same heavyweight features, that I can see plays a part in the embedded world – but not for desktop or server-side applications. From what I’ve heard Linus Torvalds hasn’t exactly helped the cause by openly criticising C++ development; and having seen some shocking code myself I can see where he’s coming from.

Still, just because a feature is available, doesn't mean you have to use it - you can still write procedural code in C++. The most complex templates I’ve ever written are for smart pointers, oh, and some truly dreadful generic collections back in the early part of my career. However I’ve used boost::function (a non-trivial component) on many occasions. You don’t have to be David Abrahams to be productive in C++. At an absolute minimum you could write in C, but take advantage of C++’s greatest strength, RAII, and at least take the pain out of the resource management. RAII is an incredibly simple concept to understand, cheap to implement, and clarifies code by removing the need for the ugly Single-Entry-Single-Exit style so often demanded in C based projects.

As a distinctly non-polyglot programmer I have absolutely no credentials for claiming that you can be as productive in C++ as you could be in, say, C# or Java. As a language, I believe you probably could be, but the distinct lack of standard libraries means that you need to buy or build the moment you step outside of “Hello World” and into even meagre requirements like XML processing or TCP/IP communications. C++0X goes some way to alleviating the common ailments like threading and lambdas but is it too little too late? The stock answer to the anaemic library problem these days is often “Boost”. Yes, it’s full of goodness, and pretty stable, but F/OSS still doesn’t sit well in many institutions.

C++ definitely has an image problem. A lot of mud has been slung over the years and unfortunately some of it has stuck pretty solid. An old colleague of mine who was a C# developer often used to quip “Don’t you have some memory to manage or leaks to plug?”. The answer of course, was no. I haven’t had to deal with memory (or any kind of resource leaks) in my code for years. Probably the better part of a decade. RAII (which is described in exquisite detail in Matthew Wilson’s Imperfect C++) means I don’t think about it any more than a C# or Java programmer. In fact probably less so! Granted, techniques like Expression Templates are seriously complex and require real brainpower – but only if you’re going to implement them; as a consumer of these techniques do you really need a PhD in Software Engineering?

The tune from the recruitment consultants about the demise of C++ in the Windows based Finance world where I dabble only confirms my suspicions. .Net is king and no longer just client-side - it’s also encroaching on the server-side where performance is not measured solely in computations-per-second. That pretty much leaves just the quant style number crunching domain, which is not really my bag, or maintenance work on aging legacy systems that are limping along until the rewrite goes live - no doubt written in C#. “Keeping The Lights On” is fun for a bit, until you realise that you have absolutely no chance of making any significant contribution to the mass of Technical Debt.

Maybe the problem lies with the decision makers? Are Today's Managers just Yesterday’s C++ programmers who had such bad experiences in the ‘90s that they feel morally obliged to protect their workforce from such abuse? Once bitten twice shy and all that? OK, pretty unlikely. How about excellent marketing from the other camps? Good PR probably helps to kick-start a revolution, but developers are a pretty savvy bunch and not afraid to point out when the Emperor is dressed in his Birthday Suit - I don’t think anyone could pin the phrase “Passing Fad” on Java or C# these days.

I know it’s a massively overused quote but those immortal lines from Uncle Ben in Spiderman are the closest thing I have to an answer “with great power comes great responsibility”. C++ welds great power, but potentially at an extremely high cost and I don’t think enough developers are willing to take on the responsibility of learning how to use it safely. They want to focus on delivering value to their customers and not getting bogged down trawling the internet for vendors or F/OSS libraries because their language doesn’t even provide a facility to search a folder for files. And rightly so. I love C++ to bits and I feel sad to have switched to another language after nearly 15 years of it. But the reality is that it just isn’t moving fast enough to fill even the basic needs of what a general purpose programming language has to provide today for a General Purpose Programmer like me.

Two Book Reviews Published in This Month’s C Vu Magazine

The current issue of C Vu (Volume 21, Issue 6 - one of the journals published by the ACCU) has two book reviews from yours truly. The first is for the 3rd edition of UML Distilled by Martin Fowler, and the other is for The Old New Thing by Raymond Chen. Neither book is exactly new and the latter I read some years ago, but I noticed a couple of gaps in the book reviews on the ACCU website (which are searchable by non-members as well as members) and thought I’d fill them in. Both books get a big thumbs up from me*. Of course if you want to read the reviews you’ll either need to subscribe to the ACCU so that you can download back issues of C Vu and Overload, or wait for them to be published on the website.

*Given the name of this blog and the contents of my very first post I don’t think this will be much of a surprise to anyone.

So Long and Thanks For All the Onions

A couple of days before Christmas my father passed away. Even though he was in his 70’s and had recently been in hospital, we all thought he was on the mend and so it was still somewhat of a shock. Yesterday was his funeral at which both myself and sister spoke. I’m not sure if a blog is the right medium to publish something as personal as a eulogy, but I believe it’s because of the last 9 months of blogging that my writing skills have improved to the extent that I’ve been able to attempt to write a piece that would do him justice. This blog may just be a temporary affair, but he will be with me always…

For as long as I can remember people have said to me “you’re getting just like your father” or “you sound just like your dad”. This is usually said in jest and I’ve always tried to shrug it off. But is that such a bad thing to be?

As some of you will know I work in IT as a computer programmer, and it’s here that one of the most dominant of Dad’s genes shines through. He had a strong sense of logic, which was often put to good use solving Sudokus and cryptographic puzzles in the newspaper. But it also had a somewhat perverse side that meant that an argument could be taken to ridiculous extremes. Normal people would call it being bloody-minded, and I can personally testify that it’s a trait that doesn’t go down well with your partner - no matter how useful it might be for your choice of career.

Although we shared a similar gift for numeracy, he honed his ability to do mental arithmetic and eschewed a calculator in favour of pen, paper and grey matter, come to think of it, did he even own one? No doubt this is also the reason that he had a love of cards, and Bridge in particular. The only card game he would shy away from was Rummy because he was unable to beat mum at it. The one time he finally did, we made him a certificate. To most of us a game cards was largely a game of chance, but to him it was more like Chess. He was always thinking three hands ahead of us and loved to analyze the outcome of each hand – something I appreciated, but I’m not so sure the others always found it quite so interesting. Isaac and Millie - my two eldest - are both card sharks in the making and will definitely miss the free lessons.

Dad was one of those people that read a newspaper from back-to-front. I say front, but I think in reality after digesting the sports pages and neatly separating the puzzles for later, he just skimmed through the actual news. There is no denying that he was a lover of sport. And not just the usual mainstream stuff such as

Football, Cricket and Tennis. Oh, no, he also followed Darts, Snooker, Athletics, Swimming, Golf, etc. In fact pretty much anything the TV was showing. Or for that matter was being reported via Teletext. In the days before he had managed to convince his neighbour Pete to let him watch Sky round his place, he would just watch the game results page on Teletext. He didn’t even have radio 5 on in the background with the commentary!

From what I gather he wasn’t half bad at playing sport either in his younger days. I remember going to watch him play cricket at Ifield Court and we even shared a pitch together once. He always came to watch me play Football, Rugby & Cricket and of course was instrumental in my Swimming career. His skills with a stopwatch were legendry and as 1500m was my race of choice it gave him ample opportunity to provide various statistics about each 50m, 100m, 200m and 400m section - all timed to the same degree of accuracy as the pool’s electronic timing!

That kind of precision and attention to detail was reflected in other parts of his life too – from folding a sweet wrapper to the placement of the stamps in his collection. Yes, Dad was quite literally a train-spotter. Although I’ve never really shared his passion for trains or stamps, I am nonetheless also a geek, but mostly of the computer variety. I also have a full catalogue of all my vinyl records and CDs and I’m sure my passion for music comes from him. How could a boy not marvel at the reel-to-reel tape deck that was dusted off during each phase of decorating? I wasn’t a fan of the decorating but I did enjoy being in a room full of music – after all who doesn’t the like Beatles? He had a pretty wide taste too, covering most things from classical to modern pop. During my teens I often caught him listening to some of my tapes – Frankie Goes to Hollywood was definitely a favourite.

So is there anything missing from my DNA sequence that I wish I had been given? I have absolutely zero interest in gardening so I’m not going to complain there. Fortunately Charlotte is covering that angle and I’m sure the success of this and any subsequent year’s harvest from our back garden will in many ways be down to the advice given by Dad. Let’s face it, he had enough practice! He certainly had a much better grasp of DIY than I do. Although he left the hardcore stuff like electrical or plumbing work to the professionals, he built the garage the sits to the side of the house and the retaining wall and rockery at the foot of the garden - a considerable achievement by anyone’s standards.

I’m sure my wife would wish for me to have inherited his frugal nature, at least regarding money management. In some respects he was way ahead of his time as he tried to minimise his carbon footprint by switching off unnecessary lights and sockets, closing doors to minimise heating expenditure and recycling A4 paper in post-it note size chunks. He’d even rather save the last cup of tea from the pot and later reheat it in the microwave than throw it away and make a fresh brew. The one tip of his I did adopt during my cost-conscious student days was to drink light-and-bitter, which is supposed to be half a pint of beer and a similar sized bottle of light ale, but the barman would often pour up to the bulge in the glass so you got more than a pint you see.

Fortunately we’re not carbon copies of our parents which gives us an escape hatch to avoid some of their foibles - not that I think Dad had many. If the worst memories I have of him are when he used to wake me up with a cold flannel to go swimming (of course I was really awake and I’m sure he knew that) or that we had to be quiet whilst we were eating then that that’s probably not a bad benchmark. Going to University was certainly quite an eye opener as it seemed everyone else in the flat belonged to a broken home and their parents had divorced. I realised that any grievance I might have against my parents was somewhat petty in comparison.

That said, of all his attributes, the one I hope our children have inherited most is his morale compass. Some may regard his fondness for formality to be old-fashioned, and I remember how surprised he was to find out that we don’t address our superiors at work as Sir or Madam. His experiences with eBay certainly tested his patience (even if he got mum to do the dirty work) as he wanted everyone to behave as ethically as he did. He was a firm believer in fair play and instilled politeness in us as children and never swore or used bad language either. In these respects he was quite the gentleman.

Ok, actually that’s not entirely true as I do remember him swearing a couple times during an evening playing snooker when he was working for the Snooker firm. It was very late and the brandy had been flowing freely. He missed an absolute sitter and exclaimed… Well I don’t think I’ll repeat what he actually said, but the entire room stood aghast, not sure they could believe the words that had just been uttered by their supposedly respectable bookkeeper. This is probably why he could get on with almost anyone as he was equally comfortable hiding behind the curtain entertaining the grandchildren as he was talking shop with customers.

So you see, being “just like your father” isn’t so bad after all, in fact I should consider it a compliment. I reckon Mother Nature has dealt me a pretty good hand and I’ve come to realise that I should not see it as a curse, but embrace those hereditary genes as they make me a better person.

And remember, if you see me weeping in future; don’t automatically assume it’s down to the loss of my father. Yes, he’ll be greatly missed by us all, but it may just be that we’ve unearthed a few more of his onions…