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…

1. 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.

2. Rachel asks another member of the development team to come and do a dev check. On this occasion she asks Jon.

3. 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.

4. 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.

5. 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.

Just after I left Yahoo!, I was asked by YDN if I’d mind still presenting the talk I was planning to do about Yahoo! Pipes. Being the wonderful sort of chap I am, I happily agreed. So, after a couple of months away from the company, on Tuesday I rolled up to give my presentation. I’ve got to say, it felt a bit weird giving a talk for a company I no longer worked for. But, it seemed to go okay. People asked interesting questions, and they seemed to enjoy me talking about how to make Pipes, and sharing a few of the ones that I’d previously made with them.

The idea behind the talk was that whilst Pipes is a wonderful tool, it does have a fairly steep learning curve, and many people are dissuaded from using it before they’ve managed to do anything because of that. When I started using Pipes two years ago, I wished I had someone who already used it to give me a few pointers, so by giving this talk I hope I helped a few people out in the way that I wish I had been two years previously.

All the pipes used within the talk are linked within the slide deck, and if you want to look at any of my other pipes, you can find them at pipes.yahoo.com/neilcrosby.

When I tweeted about this, I was overwhelmed by the replies, and the positive feelings that came out of them. There was a lot of “why on earth would they do that?”, along with plenty of “don’t worry, you’ll find something easily”. I’d like to say a huge thank-you to everyone who’s shown support over the last couple of weeks — you’ve all been wonderful.

I don’t want it to sound like I feel I’ve been maligned by Yahoo! though — I honestly don’t feel that way about what’s happened. Instead, I see this redundancy as an opportunity for me to take a little time to work on a couple of the projects that have been sitting in the back of my mind for the last few months, just waiting for a bit of time so that they can come forward and take shape. With that in mind, I’m going to be taking the entirety of July and using it to build cool stuff. I’m not even going to be thinking about paid work until August. Expect a few blog posts about stuff that I’ve built over the next month.

But what then? I’m hoping to start doing some freelance work, with the crazy aim that this will allow me more time to work on my personal projects than doing a 9-5 would. Well, I can hope, can’t I?

I’ve had a fantastic time at Yahoo! over the last couple of years. I’ve worked with some truly awesome people, and I’ve learnt a huge amount. The company has changed a lot in the time I was there, and there have been plenty of ups and downs. Ultimately though, it was a fantastic place to be, and it was the people who made it that fantastic a place to be.

When I arrived, I’d never really been let out in the community before. The number of events I’d been to could be counted on my bad hand (with a finger to spare) – @media, the first WSG meetup, and d.construct. Since I’ve been at Yahoo! though I’ve turned into an event junkie, constantly going to BarCamps and UnEvents, organising two Big Geek Days Out, talking in London and Munich about SearchMonkey, and writing the Frontend Test Suite that I also got to talk about for YDN. I really feel I’ve blossomed at Yahoo!, and I can’t begin to express how much I’ve got out of my time there.

So thank-you to everyone who’s helped shape my experience over the last two years and nine months. You’ve been awesome, and the fact that some of you think that I’ve been awesome as well makes it all worth while.

Thank-you.

This is unfortunate, since twitter does provide an in_reply_to_status_id parameter for tweets, which is set when one tweet is specifically written in reply to another. If we were able to query this parameter directly then the Twitter Conversation Yahoo! Pipe that I’ve written would be unnecessary and I wouldn’t have had to spend a couple of hours writing it. But I did have to write it, and that’s okay because it gave me a much better understanding of how to use Pipes.

In order to track twitter conversations (between non-private users), I did the following:

1. Find the status_id of the tweet that started the conversation.

   This can found at the end of the tweet’s URL.

2. Make a request to the twitter API to find out who wrote that tweet.

   This isn’t strictly necessary – the user could provide this too. However, by working this out for them the user only has to provide one piece of information.

3. Make a request to twitter search for any tweets written since the original tweet that contain “@username”, where ‘username’ is the username of the original tweeter.

4. For each search result make a request to the twitter API to find out if that tweet has its in_reply_to_status_id parameter parameter set.

   Yup, that’s an API request for each of conceivably a lot of tweets. If the twitter search API returned this data as part of its result set that I could remove this call and be a much happier man.

5. Discard any search results which do not have in_reply_to_status_id set to the status_id of the original tweet.

6. At this point, I originally wanted to recurse the pipe and run through this process again for all the tweets I’d just found via the search so as to get a richer conversation experience.

   Unfortunately, due to the massive number of HTTP requests required, Pipes understandably started timing out.

7. Finally, add the original tweet to the list of tweets if required and order by time, starting with the original tweet.

There’s a fair bit going on there, and things get a bit complicated in the Pipe due to the way various properties had to be manipulated. It all ends up working pretty well though.

This Pipe becomes more useful once you add a quick little bookmarklet to it. Drag my Twitter Conversation bookmarklet to your browser’s bookmarks folder, and then click on it any time you’re on a tweet page that you think will start an interesting conversation. You’ll immediately be taken to a Pipes page which contains the conversation. Then, you’ll be happy.

I’d been wanting to get round to writing this post for a while now, but was finally pushed into getting it written by a statement Paul Boag made on twitter:

Paul Boag: wishes that when somebody asks a question on Twitter you could easily see if anybody else has answered it.

This was quickly replied to by Dominic Baggott, who had seen my Pipe when I mentioned it a couple of weeks previously on twitter:

@boagworld You could check out @NeilCrosby’s conversation pipe built for pretty much that purpose. http://bit.ly/bCkvL

Clearly there’s a want out there for people to be able to see these conversation threads.

The fact that I’ve been able to fairly easily hack together the proof of concept in Pipes shows that it wouldn’t be the most difficult thing in the world for twitter to implement themselves. Even if twitter just “flipped a switch” and turned on output of in_reply_to_status_id in search API results then this hack would become a whole lot more palatable due to the massive reduction in HTTP requests this would mean. It might even mean that Pipes would be able to recurse into the conversations, which would be fantastic.

UPDATE: Darren Foreman has just shown me pbtweet, which also surfaces conversations in twitter, as well as a few other things, and is also apparently based on Pipes.