Email
Like
Liked ×
Save
Private Content
Embed
Loading embed code…
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.
Loading

+ Follow

team++

by Neil Crosby

3,152 views

How we powered up the BBC Homepage team.

Accessibility

View text version

Upload Details

Uploaded via SlideShare as Apple Keynote

Usage Rights

File a copyright complaint

8 Embeds 1,091

http://neilcrosby.com	1049
http://lanyrd.com	28
http://neilcrosby	8
http://twitter.com	2
https://twitter.com	1
http://a0.twimg.com	1
http://translate.googleusercontent.com	1
http://www.linkedin.com	1

More...

Statistics

Likes: 2
Downloads: 53
Comments: 0
Embed Views: 1,091
Views on SlideShare: 2,061
Total Views: 3,152

\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 biggeekdayout.com and say you’re coming!\n
So, does anybody have any questions?\n
\n \n

2 Likes

Biblioteca Campus Gandia CRAI at Biblioteca Campus Gandia CRAI 11 months ago
Israel Santiago, Software Engineer / Project Manager at Araujo Drugstore S/A 1 year ago

team++ Presentation Transcript

team++Powering up the BBC Homepage development team.
@NeilCrosby Lead developer, BBC Homepage Lego enthusiast Baker
Life used to be scary
Really scary
We wanted better
This isn’t rocket science
Continuous Peer Review
Before any task iscommitted to trunk,a developer whodidn’t work on itmust say that theyare happy with how it’sbeen completed.
After every task,Ask questions
Does anything worry you?
Go back intodevelopment if necessary
Sometimes people dothings wrong
People die get ill
Peer review helps the team
Standards are Good
PHP_CodeSnifferDocumentation K&R braces Spaces, Consistent not tabs spacing
Break the Standard?Break the Build.
We write tests. No, really.
Break the Tests?Break the Build.
Perform PairProgramming(where appropriate)
Enhance Progressively
Don’t workout of hours
Bringbakedgoods
Socialise
Life is Good
Big Geek Day Out http://biggeekdayout.comSaturday 1st October Great Western Lego Show
AnyQuestions?
Attributionhttp://www.flickr.com/photos/dunechaser/3385957499/ http://www.flickr.com/photos/kwl/5114935852/http://www.flickr.com/photos/dunechaser/3385957057/ http://www.flickr.com/photos/cross_stitch_ninja/4932950637/http://www.flickr.com/photos/guinavere/5975167653/ http://www.flickr.com/photos/hoyvinmayvin/5167032467/http://www.flickr.com/photos/thevoicewithin/5602511743/ http://www.flickr.com/photos/azrasta/4865872893/http://www.flickr.com/photos/pedrovezini/4915241275/ http://www.flickr.com/photos/minifig/3174009125/http://www.flickr.com/photos/dunechaser/567753250/ http://www.flickr.com/photos/pinkpurse/5282398538/http://www.flickr.com/photos/kaptainkobold/5683011508/ http://www.flickr.com/photos/pasukaru76/5459428379/http://www.flickr.com/photos/pasukaru76/4725010212/ http://www.flickr.com/photos/hoyvinmayvin/4759814312/http://www.flickr.com/photos/pedrovezini/5473616337/ http://www.flickr.com/photos/hoyvinmayvin/5056582082/http://www.flickr.com/photos/spacmonster/2896019144/ http://www.flickr.com/photos/martym/4494938838/http://www.flickr.com/photos/evil_cheese_scientist/4693669312/ http://www.flickr.com/photos/kwl/5075443408/http://www.flickr.com/photos/activars/5182488473/ http://www.flickr.com/photos/kwl/5258518254/http://www.flickr.com/photos/kwl/4514986410/ http://www.flickr.com/photos/pasukaru76/5174278607/http://www.flickr.com/photos/hoyvinmayvin/5894936732/

team++

by Neil Crosby

Accessibility

Categories

Upload Details

Usage Rights

8 Embeds 1,091

Statistics

team++ Presentation Transcript