I’ve been working on the BBC’s Homepage for about a year now, leading a team of five front-end developers to create a high quality product.
One of the processes that I introduced to the team about six months ago was that of a formal “dev check” after every task that we completed from our backlog. Whilst we call this process a dev check within our team, it could just as easily be called a peer review, or mini code review.
Up until the point that I introduced the dev check it had not been uncommon for a single person to work on a task, and for code to go through the testing environments and onto live without a single other human ever reading their code. Not the best situation to be in, and it meant that we ended up having more annoying bugs showing up on our test environments than we should have. These bugs were often things that a simple bit of human scrutiny would have caught, and we ended up wasting time going back and fixing them after the fact. Working this way also meant that we ended up with certain areas of the homepage that could only ever be worked on by certain people, because they were the only ones who had ever seen the code.
Like I said; not the best situation to be in.
So, six months ago, we introduced the formal dev check – a step to be completed for every single code related task in our backlog. And, I’m happy to say it’s been a very successful process for us – we now have far fewer bugs getting to test, and we have a lot more shared knowledge within the team.
What is a Dev Check?
Before any task is committed to trunk, a developer who didn’t work on it must say that they are happy with how it’s been completed.
I’m hoping that if you’re still reading at this point that you’re wanting to find out what goes into a successful dev check…
The task is “completed” by Rachel.
At this point she has not committed anything to the trunk of the project. Depending on the size of the task, she might have created a development branch which she’ll have been committing to.
Rachel asks another member of the development team to come and do a dev check. On this occasion she asks Jon.
Jon comes over to Rachel’s desk where she will talk through all the changes she has made.
As part of the discussion, Rachel may realise that some of the things she thought made sense in fact didn’t. This is great, and she’ll make the changes necessary and continue with the dev check.
After Rachel has finished explaining what she’s done for the task, and Jon’s asked as many questions as he feels is necessary he’ll either give the go ahead to commit the code to the trunk, or he’ll request various changes to be made to the codebase.
Rachel will then commit to trunk, build in the team’s test environment and pass off to the testers.
And that’s a dev check.
Out of this process Jon has learnt about a bit of the codebase that he might not otherwise have seen, Jo realised that she needed to shore up a couple of her tests, and the codebase has come out feeling more healthy. This is A Good Thing™.
What sort of things will the dev checker ask?
Up above there in the “What is a Dev Check” section you’ll have read about Jon asking “as many questions as he feels is necessary”, and I’m sure you’ll have said to yourself “But Neil, what are those questions? How will I know what’s sensible to ask?”.
Well, you’re in luck. By a process of trial and error, as a team we’ve come up with a bunch of questions that, if asked, will help to make sure that you both understand what’s going on and can confirm that the code written is of a high quality.
Have new tests been written?
These might be Unit Tests, or Automated Front-End Tests, or Security Tests. What matters is that valid tests have been written to cover the new functionality. You should also make sure that any pre-existing tests make sense.
Do all the tests still pass?
It should be a no-brainer, but of course you should make sure that all the tests still pass. There’s nothing worse that breaking The Build for the entire team just because you forgot to run a bunch of tests on your development machine first.
Are standards adhered to?
- PHP Code Sniffer
- HTML/CSS Validation
- JSLint
- Whatever else works in your team
These are important to us. We fail our builds if our code isn’t of high enough quality. Just sayin’.
Does what you’ve written work across all the Level One browsers?
Obviously this one’s a bit web development specific as it is, but it’s important in other spheres as well. Every piece of software that’s written is expected to run in one or more environments, and you should at least smoke test in a known subset of them to make sure there are no nasty surprises for your dedicated testing team.
Can I see your diffs?
Again, fairly obvious, but you should take a look to see what’s changed since the last time the code was checked in. Don’t just rely on the developer to remember what they’ve changed – I know I can’t remember half the time. This is what machines are good at – make use of them!
Did any of the changes that were made affect any other code?
This one should be obvious as well, but unfortunately it isn’t. It’s all too easy to look at the lines of code that have changed without looking at the later lines which make use of them. Don’t forget to look at the whole system.
Is there anything that concerns you?
The final question to ask, and in many cases the most important one. Oftentimes a developer will know that something smells a bit fishy, but keeps quiet about it in the hope that they won’t get called on it. By simply asking these questions though, we’ve found that these things end up getting talked about, and we end up with better code because of it.
How long does a dev check take?
After reading all that, I wouldn’t be surprised if you’re thinking “Woah! But how long does that all take? That seems like a long list of questions…”.
Well, in my team, we find that a dev check will take a little less than 10% of the time that the code and tests took to write initially. So, if the task took an hour to complete, the dev check would take roughly 5 minutes. A three hour task would take 15 minutes, and so on. It honestly doesn’t take much time once you get into the swing of things.
The Power of Veto
One of the most important things about dev checks is that everyone on the team is equal. Rachel may be the team leader, but Jon can still challenge her code and say that actually she hasn’t done everything required to “pass” the dev check.
The person performing a dev check always has power of veto to say that things, however small, need improving before code is allowed to be committed to the trunk.
Ultimately, the team is responsible for its own output, and everyone should be invested in that.
What do dev checks achieve?
As I’ve mentioned above, there are two main benefits to dev checking:
- Fewer bugs
- More knowledge of the codebase by more of the team.
Essentially the team will be more effective.
How do you get buy in?
Whilst there are obvious benefits to dev checks, sometimes you’ll need to gain buy-in from people before you can get started. Maybe it’ll be team members who think that this extra process is unnecessary, or maybe it’ll be The Boss who thinks that it’ll all just take far too long. What do you say to them?
Getting Buy In From Team Members?
- Everyone is equal.
- Anyone is able to say that a dev check cannot yet be completed.
- The team is responsible for the quality of the team’s output, not just one person.
- You won’t end up getting stuck on a horrible portion of the codebase any more, just because you were the last person to write code for it.
Getting Buy In From The Boss?
If you’re lucky, you won’t need to get buy-in from The Boss, but in case you do, here are a couple of pointers:
- Quality is improved, leading to fewer bugs and happier users.
- The amount of time spent on dev checking is smaller than than that which would be spent fixing the bugs that would otherwise get through. The project will go live sooner, and you’ll have spent less money.
Improving the Dev Check
Any bug that is found is an opportunity to learn and improve our process.
Of course, sometimes bugs will still get through. When they do, you need to sit down and work out why that happened.
In the old world, we used to just accept that bugs happened, that they’d get found, and we would fix them. No more! Now, any bug that is found is an opportunity to learn and improve our process.
A real example of this happening came a few weeks ago. Tina had been doing her thing, updating a script that we use to help us with our release management. This was dev checked by Bradley, and as far as he was concerned the changes that had been made were good to go. So, he ticked off the dev check, and Tina carried on with her next task.
Fast forward to a week later, and Paul was getting down on the floor ready to give a presentation which required a screenshot of the script running. Unfortunately, it no longer worked – shock horror!
What had happened was that Bradley hadn’t realised that the line of code that was changed had impacted on further lines in the script. Moreover, he’d only seen the script run against the additional new requirements, and hadn’t confirmed that it still ran against the original requirements. Whoops.
What came out of this was an improvement to our dev checks – if code has changed we need to make sure that nothing else in our code has been affected by that change. It sounds simple, but it was a failing that we had, so we improved upon it.
Why not just have a big code review?
Big code reviews are great, and are something I very much enjoyed participating in when I was at Yahoo!. Unfortunately, whilst they’re very useful they’re also pretty time consuming, and require a fair amount of setup and teardown time in order to be useful.
Dev checks, on the other hand, are simple to get going with, only take a few minutes, and only have to involve a couple of people.
That’s not to say that you should get rid of larger code reviews. In my opinion they should still happen, but only for larger chunks of code. The formal dev check gives you the opportunity to review code and share knowledge often and with low cost.
Go forth and Dev Check!
And that’s it. If you’re working in a team that has bugs, or has bottlenecks of a single person being the only person who knows about certain areas of your product, then start dev checking. You won’t regret it.
Leave A Commentposted in Blog Posts by Neil Crosby
