Code Reviews

Most people agree that Unit Tests are a good idea, and most developers try to write them (with varying degrees of success). But the challenge of creating Unit Tests for existing projects can be incredibly daunting to developers.

Many people may not see the need, if an area of code has been working for quite some time then why introduce tests which will take a lot of time and (if you need to refactor to make them work) introduce risk in an area? When I wrote about the value of Unit Tests back in 2015 I postulated that the value of these small executable is not in finding bugs, it’s in preventing bugs in the future.

Unit Testing, unlike exploratory is not about finding issues with existing code, it’s about reinforcing and documenting (through executable code) exactly how each function, class, and property should behave in particular circumstances. If you understand this then you’ll see that the value of Unit Tests does not diminish with an established solution (even if most of the teething bugs have already been worked out). In fact it makes your existing code bases much easier to safely maintain!

So the question becomes how and where do we start?

I’m currently working on an application which has in excess of five million lines of code in it. Some parts are new and some date back to the project’s inception. Writing a full set of tests for the entire application is a monumental (and I have to admit largely pointless) exercise.

What we need to do is look at the areas which are most in flux. If Unit Tests are a technique for helping to protect our software against unexpected change then the areas where they deliver the most benefit are the areas of code which change frequently.

We’re engineers, not psychics (at least I’m not) so use metrics. Look at your Source Control history and see which classes are subject to frequent change (both bug fixes and feature work applies). Target your Unit Tests here, use the 80:20 rule and target your efforts in the right place. One of my favourite sayings applies here… how do you eat an elephant? A little at a time!

Slowly, little by little the classes which see the most changes will stabilise and you’ll introduce less bugs when expanding them or fixing existing defects.

These are my thoughts, do you have any experiences breaking down huge applications into Unit Tested code? How did you do it?

When hiring for a new developer its extremely common to ask them to demonstrate their technical ability. Often this is a practical test to be done at home and then sent into the hiring manager.

It’s a nice idea, you get to see the candidate’s unhurried work, get a feel for their skills and potentially ask about them in a face to face interview later. It’s far harder for a bad developer to write good code than it is for them to learn a few answers about relational databases or solid principles.

However, I believe this approach is flawed!

To explain why I want to describe the recent experience of a friend of mine, an outstanding developer who recently applied for a development role. The technical test was presented to him and he completed it, he’d had a rather manic week and so determined not to miss his deadline so he worked late I tot he night. He confessed to me later that he probably spent somewhere between ten and twelve hours on that piece of work!

What happened?

The company rejected him with a series of bullet points over design choices without ever giving him the chance to explain why he’d made those decisions.

So let me ask you this, do you think friend is ever going to waste his time with one of their roles in the future? Do you think I, knowing his experience would apply for one of their jobs? What about the rest of our friendship group?

My point is this – any hiring manager will tell you how scarce good development resource is. By demanding eight, ten, maybe even twelve hours of our candidates’ time and then throwing it away, that’s (in my view) arrogance.

What’s more it doesn’t actually tell you very much! Sat at home what’s to stop someone googling the question, posting something on Stack Overflow, or asking a friend to complete the test for them? How do you know that the candidate’s work is their own?

So what do I recommend instead?

I’m hoping to start recruiting over the next week months and I intend to send code review tasks out to my candidates. Why?

Asking someone to review your code gives them a chance to suggest improvements and identify where you’ve not used best practices
Code reviews ask candidates to explain and articulate their views, something a straightforward programming challenge doesn’t
You still get the same feel of a candidate’s focus (do they focus on code clarity, performance or UI aspects?)
You are demanding far less of a candidate’s time and therefore aren’t putting off people applying for the role

Will my approach work? I don’t know, we’ll find out! What are your experiences with practical coding challenges? Do they work?

Tag: Code Reviews

Starting Unit Testing in a Huge Codebase

Why Technical Tests are both a Wonderful and Terrible Idea