Published on

How we powered up the BBC Homepage team.

Published in: Technology, Business
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • \n \n
  • In every team, there are things that don’t work too well, and the one I’ve been working in for the last two years is no exception.\n\n \n \nThere are things you can do to improve matters though. Over the next twenty minutes I’m going to show you a few of the things we’ve done on the BBC Homepage to make our lives more pleasant.\n
  • My name’s Neil Crosby, the lead developer on the BBC Homepage. I’m a big fan of automating things that might go wrong, and a huge fan of going home on time.\n\n \n \nI also like my Lego, which would explain the visual theme for this talk.\n\n \n
  • When I joined, the homepage was being moved from one platform to another.\n\n \n \nDevelopers had joined and left.\n\n \n \nPeople were working in one person silos. Code would get to live without a single other person seeing it.\n\n \n \n\n \n
  • There were bugs. Oh, so many bugs. Little and large.\n\n \n \nThings that should never have got through the system. Bat board.\n\n \n \nNot fun. Suffered like this for a long time.\n\n \n \nWhen the page launched last may, it was beset with problems.\n
  • We started working on the new version.\n\n \n \nAs a team, knew we wanted better.\n\n \n \nSat down and decided what we were going to do.\n\n \n \nThat’s what I’m going to talk to you about today - how we improved our working environment, and what it’s done for us.\n
  • I’m going to talk about three of the main things we put in place - \n\n \n \ncontinuous peer review, \nhaving standards \nand writing worthwhile tests\n\n \n \n- along with a bunch of other useful things we now do.\n\n \n
  • This is all pretty simple stuff. \n\n \n \nIt’s common sense. \n\n \n \nBut we weren’t doing it before.\n
  • First up is continuous peer review. If you follow my blog, you might have heard me refer to this as a “dev check” in the past.\n\n \n \nEssentially - after every single task that anyone in the team completes, they find someone else who wasn’t involved, and ask them to review it and ask questions.\n\n \n \nIt doesn’t matter who that person is - everyone is the same in peer review land. Seniors ask Juniors, cats lie down with dogs - it’s all good.\n
  • \n \n
  • What was the work you did?\nDoes it do what the task asked for?\nHave you written new tests? Do they pass?\nCan I see the code working in a couple of browsers?\n\n \n \nDifferent questions for every type of task, as long as they help to eke out problems, and share knowledge.\n
  • There is one question that should always be asked though - is there anything that you’re done for this task that concerns you?\nWe all want to do our best. This question gives permission to the reviewee to admit that there are things they did that they weren’t comfortable with.\n9 times out of 10 they’ll then come up with a better solution, or be convinced that what they did was actually okay.\n
  • At the end of the review, the original developer has to make any changes agreed upon with the reviewer before their code is allowed into the codebase. \n\n \n \nAnd that’s all there is to our continuous peer review.\nGenerally, they’ll take about 10% of the time of the original work - not bad at all.\n\n \n
  • In case you hadn’t already guessed, there are two reasons why I think that continuous peer review is a good idea.\n\n \n \nFirst, people sometimes do things wrong. It happens. The second pair of eyeballs on their code can pick up on the fact that they’re riding an ostrich instead of force strangling people, and that can be fixed quickly.\n\n \n \nThe alternative is that the entire universe potentially ends up seeing you riding an ostrich, and that’s not so good…\n
  • The other reason for performing continuous peer review is that they improve team resilience.\n\n \n \nSometimes people get ill. You don’t want to have to spend timing getting someone else up to speed with an area of code that’s only ever been seen by one person before.\n\n \n \nYou also don’t want to get into a situation where a horrible lump of code has only ever been worked on by one person. Peer review helps to stop that person from always being given the task of cleaning out the death star compactor.\n
  • \n \n
  • Overall, continuous peer review just helps the team. Bugs go down, people can take holidays without feeling like they’ll come back to a horrible heap of nastiness, and can generally breathe.\n
  • So that’s peer review.\n\n \n \nThe next thing that got our goat about the code that we’d been previously touching was that depending on the developer who’d been there before, things might be good, bad, or downright ugly. We set out to change that.\n
  • Because standards are good. But then, liking Lego, I would say that. Standards help lots of separate things come together as one working whole. They’re good.\n\n \n \nSpecifically when I talk about standards here though, I’m talking about coding standards.\n\n \n \nOh god - what if no-one agrees?\n\n \n \nAs a team, we talked about what we would all be happy with adhering to, and we decided on the Zend coding style, with a few house alterations. Where necessary, I chose.\n
  • \n \n
  • But a standard is no good if it isn’t enforced.\n\n \n \nWe decided to use PHP Code Sniffer to check against our codebase, and these rules are automatically run every time we try to build the project in our Continuous Integration environment. If they break? The build breaks.\n\n \n \nBut the standards checking doesn’t just happen on build - we also run them as part of peer review.\n
  • Next up on our list of things we wanted to improve on in the team were having worthwhile tests.\n\n \n \nUp until this point, automated tests that ran against the homepage were pretty few and far between.\n
  • Two types of tests that we now write as part of every task - unit tests and functional tests that are ultimately run by selenium.\n\n \n \nWhat’s worthwhile? We test specific features. Test the “happy path” with some specific bad cases.\n\n \n \nAgain, these are prodded and run as part of the continuous peer review.\n\n \n \nWe strive for high code coverage, but that doesn’t tell the entire story. Touching 100% of the lines of our codebase doesn’t necessarily mean that we’ve tested that everything does what it should.\n\n \n \nWe have to use our brains.\n
  • Once again, if the tests break during the build, then the build will fail.\n\n \n \nThe team will be notified in IRC, and we’ll all shake our heads at the person who destroyed C3P0.\n\n \n \nAnd of course, the tests really come into their own when we realise we have to change some portion of the site for whatever reason - it makes it a lot easier to have confidence that we didn’t break anything ourselves.\n
  • And those were the three big things that as a team we knew we needed to do to improve our lives.\n\n \n \nBy continuously reviewing each others’ work we reduce bugs and improve knowledge.\n\n \n \nBy having coding standards we can pick up any file in our codebase and not have to battle with someone’s personal style.\n\n \n \nBy having worthwhile tests we know that the codebase does what it should do.\n\n \n \nThe rest is all gravy. Still, what else do we do?\n
  • On large tasks, we pair program. Two heads are better than one.\n\n \n \nWe still peer review at the end.\n
  • All frontend tasks start out by simply working in a browser. We then layer JS on top.\n\n \n \nWhen new features are added we do the same.\n\n \n \nEverything on our page works before and after JavaScript has kicked in.\n
  • In our team we come into work, we work hard, get our work completed and go home.\n\n \n \nWe don’t stay into the middle of the night.\n\n \n \nWe do have a life outside of work.\n
  • I was told by David to include baked goods in my presentation, so here they are.\n\n \n \nAnd actually, we do do this - from time to time we bring in baked goods for each other. If you don’t do this in your team, you should.\n
  • Which brings me neatly onto my final point - we now socialise together. That simple act lets us break down barriers far more quickly than anything else.\n\n \n \nWhere before there were various tensions, now they get whined about in the pub, and then everything’s great the next day.\n
  • And life is good. We now have a codebase that’s much more stable than the one that we inherited, no person is an island and we have confidence that when we do unleash our work onto the world that it will actually work.\n\n \n \nAs I said at the beginning, none of this is rocket science. It’s all pretty obvious stuff, but we weren’t doing it. If you take one thing from this talk, I hope it’s this - there’s always something you can do to improve the team you’re in, you just have to go and make it happen.\n\n \n \nThankyou.\n
  • Very quickly, before I take questions, I want to mention an event that I’m sort of organising on the 1st october.\n\n \n \nBig Geek Day Out to the Great Western Lego Show. It’s the largest display of Lego models built by Lego enthusiasts in the UK. If it’s something you’d be interested in coming along to then pop over to and say you’re coming!\n
  • So, does anybody have any questions?\n
  • \n \n
  • team++

    1. 1. team++Powering up the BBC Homepage development team.
    2. 2. @NeilCrosby Lead developer, BBC Homepage Lego enthusiast Baker
    3. 3. Life used to be scary
    4. 4. Really scary
    5. 5. We wanted better
    6. 6. This isn’t rocket science
    7. 7. Continuous Peer Review
    8. 8. Before any task iscommitted to trunk,a developer whodidn’t work on itmust say that theyare happy with how it’sbeen completed.
    9. 9. After every task,Ask questions
    10. 10. Does anything worry you?
    11. 11. Go back intodevelopment if necessary
    12. 12. Sometimes people dothings wrong
    13. 13. People die get ill
    14. 14. Peer review helps the team
    15. 15. Standards are Good
    16. 16. PHP_CodeSnifferDocumentation K&R braces Spaces, Consistent not tabs spacing
    17. 17. Break the Standard?Break the Build.
    18. 18. We write tests. No, really.
    19. 19. Break the Tests?Break the Build.
    20. 20. Perform PairProgramming(where appropriate)
    21. 21. Enhance Progressively
    22. 22. Don’t workout of hours
    23. 23. Bringbakedgoods
    24. 24. Socialise
    25. 25. Life is Good
    26. 26. Big Geek Day Out http://biggeekdayout.comSaturday 1st October Great Western Lego Show
    27. 27. AnyQuestions?
    28. 28. Attribution