LWS Team (#lwsteam), Blog

by lwsadmin. 0 Comments

Developing and Delivering (surviving as a developer in a National Museum)

Rich Barrett-Small

Rich is here to talk about his experience at the V&A and as an agency developer.

The V&A is a museum of the applied arts. The V&A has a website that has visitor numbers entering into the millions per year. They also have a diverse range of visitors, with different needs and abilities.

The website has two distinct visitors types, internal and external. Not every internal visitor has all of the evidence to say what an external visitor needs on the website, even though they don’t always know that.

Web development of any kind is a many-headed beast. Your first priority is usually to avoid being given spreadsheets my non-technical colleagues. Others priorities include, being a web designer, being a coder, being a lawyer (data protection etc). It’s a big job, or more of a syndrome. However having an overview of the web stack is what’s the greatest thing about being a web developer.

When Rich talks about web standards, he’s not just talking about the W3C, he’s thinking about programming practise and website performance. You’d think advocating for web standards in a public institution is easy. It’s not.

What are the practices they use to ensure high standards in the V&A? Public institutions like to buy proprietary software off the shelf. It often ends up that your in-house team fills the gap when the paid-for support doesn’t meet the standard.

He shows an example of a GUI they used to use. It’s really bad. It looks like some kind of database schema. Fortunately they didn’t ever roll this out to their website editors.

A software vendor often thinks they can create web enabled software by building a web interface on top of their existing software. Vendors often think they can port their desktop software to the web, they’re wrong:

“The last great thing written in C was Schubert’s 9th symphony”.

They set about modelling the data model in django.

They use MVC (model view controller). They’ve managed to extend their applications modularity to an extreme. They decided to ‘eat their own dog food’. They use symphony to keep their django implemtation inline. This kept them honest, if the V&A can use their API, anyone can.

They use a RESTful architecture (inspired by REST anyway), see the documentation:

http://www.vam.ac.uk/api

They use the HTML5 doctype and use a few of the APIs.

He shows some operating system stats. Over the last year Windows has dropped to under two thirds of visitors. Mac, iOS, Linux etc now account for one third.

Browsers, Internet Explorer is still the biggest, but is only 34%, decreasing dramatically. Firefox peaked at 27% in 2009, Chrome is increasing rapidly. This should make a good argument for supporting modern web standards right?

Most of the directors of the museum (and most of the rest of the staff) use Internet Explorer 8. This is a problem, there’s a battle to be had. You’re under pressure not to use progressive enhancement etc, it’s from these organisational challenges that most problems comes.

It’s worth while to make sure the key players in any problem are keeping up with where the project is going.

It’s hard to keep web standards if you can’t keep standards in human interaction. A lot of the time it’s about making the right technological choices up front. You need tools that make you agile, of course this is a loaded word.

A good analogy for working in a public institution is a round of golf. You occasionally hit a ball but most of the time you spend talking about things you’re interested in.

The (coding) Zone

It can take two hours to get there and 30secs to drop out. Creative people (designers and developers) need to sacrifice an hour or so to get there.

Testing

Baseline is to learn the testing suite for your app. Testing in production. Stress test your designs in CSS. Everyone loves a comp, but your design must scale as much as your infrastructure. Designing dawning rectangles [in Photoshop] is not web design in 2011.

Don’t virtualise you DB servers, it can get restrictive.

Caching

This shouldn’t be used to hide any shortcomings in your application. It should just be used to help out during times of exceptionally heavy traffic.

Accessibility

Web Content Accessibility Guidelines. You can roll standards development into your accessibility work.

Usability testing

Get someone to pay for this properly. Get someone to test this properly.

Final piece of advice: “stay hungry, stay peckish”.

Q&A

Q. For a company that uses IE everywhere, how do you get them to support the API?

A. The API is for the V&A first and foremost. The web team has shown the usefulness of the API across the museum with interactive displays etc over time.

Q. Everything is publicly paid for, have you open sourced your code?

A. Yes. One issue with the codebase it’s not in a state where they feel it’s good enough to release on to GitHub. A lot of it is specific to their database model.

Team++ – techniques for turbocharging your team’s performance

Neil Crosby

When he joined the BBC he realised he could improve the team. Here are some of the things he did.

For the last month he’s been a Technical Project Manager for LOVEFiLM. He’s a project manager but he’s not evil. He used to be the lead developer on the BBC homepage.

Today he’s talking about the terror he felt when he first joined the BBC. The BBC moved from a Perl based system. When they took the BBC homepage live for the first time, immediately everything fell over. Bugs, storing data in silly places.

They realised had huge bits of code going into production that only one person had seen. This was a problem when they left.

When they started on a new version of the BBC homepage, they wanted it to be better. He’s going to talk about the things they did to make their lives better.

Here’s the list:

  • Continuous Peer Review
  • They brought standards
  • Tests

This isn’t rocket science, but none of the teams they’d been in had done this very well.

Continuous Peer Review (“Dev Checks”)

It’s not a replacement for a normal code review. They happen when you’ve done a big chunk of code. A Dev Check is a process that happens before something’s tested by UI testers.

“Before any task is moved into test, a developer who didn’t work on it must say that they are happy with how it’s been completed.”

The testing developer will ask questions of the developer who wrote it. Does it adhere to standards of the team? Does it work in different browsers? You share code and if it’s not good enough you tell them. You also ask “Does anything worry you?”. Sometimes I write code that’s not great. It’s good to be challenged on this. Nine times out of ten, you’re happy to fix the code.

If something isn’t good enough, it goes back into development. Whatever the organisational level of the Dev Check developer (or even the original coder), you have to go back and sort out the code. The Dev Check process takes about 10% of the time it takes to write the code in the first place. The BBC did this for everything, including simple links.

“Sometimes people do things wrong”. This just happens, but allowing bad code onto a live server isn’t good.

“People die, get ill”. Dev Checks are good to share knowledge, it means the team gets better.

Ultimately, peer review helps the team, the bug rate plummets, you have more time to write code.

Having standards

These are good right? “Yes” from the audience. Having standards of writing code is important. When Neil was in Yahoo! they tried to put standards for code in place. However, it two months of arguing about tabs vs. space, where the curly bracket should go etc.

On the BBC homepage, they use PHP _CodeSniffer. It looks at the standards and makes sure the code adheres to them. However, just having standards doesn’t mean you actually stick to them. So they worked the standards into the build process. If the build process breaks, the developer responsible would have to go and fix it. This made the BBC have a code base that would be easily viewable or digested by any other developer.

Worthwhile Tests

They wrote tests. They put them in their build system. This became part of the Dev Check process to make sure that Unit Tests were in place.

Functional Tests

They made sure they fit in with every single story that initiated the feature.

Regression Tests

Sometimes things do break. Anytime anything broke, they went back to write some new tests for it, this saved the team from making stupid mistakes. Just like with the standards, if the tests broke, their build broke.

Other Helpful Stuff

Pair Programming

This is good, please do it, it’s good sometimes for the right thing, do it where appropriate.

Enhance Progressively

One thing Neil was really keen on for the BBC homepage was to make sure it works for everybody. They started development working without JavaScript, they called this the “core view”. Explaining this to designers without saying “JavaScript” meant the team worked well. This is good because sometimes JavaScript isn’t available straight away.

Also – Don’t work out of hours. They didn’t want people burning out. Of course, sometimes things explode and people had to stay late, but this was the exception.

Also, Cakes Are Good! …. and Socialise! It’s nice to be able to moan about something in the office when you’re not there.

With all of this they wen’t from a bad environment to good.

Q&A

Q. Why not just fire the bad people?
A. We knew there were things going wrong that were not just about the people. We also wanted to make sure the code base shipped to Salford in the BBC move was on a good quality.

Q. Were the slides from your own collection of Lego?
A. Some of them yes.

Q. You’ve explained the “Core View”, how did you work with browsers?
A. They started with semantic HTML, that would work with everything.

Q. How did you convince the people with the money that it would eventially work?
A. By mentioning the amount of bugs we’d reduce.

Q. How do you enfore the continous code review idea but how do you convince people to do it?
A. Firstly by recognising that the quality of the code originally was bad. But also by selling it as a chat and making people realise the quality of their code would get better.

Q. What didn’t you pair programme on everything?
A. Some things were just too small.

Q. Everything you talked about it post commit, what about precommit?
A. A lot of the systems we use are vastly different.

Q. How big was your team?
A. The team in London was 4 front end, 1 back end. They also had a team in Cardiff. They did the Dev Check process over IRC, but this wasn’t very nice.

Q. Can you give an example of a functional test?
A. E.g. making sure that if the user clicked off the page and can back the information was maintained on the page.

Q. How did you sell to the mangers that working until stupid oclick is a bad idea?
A. Fortunately it wasn’t in the culture already.

Q. Was there anything that you did that didn’t work?
A. I’ll come back to that one!

Q. How can you try and convince people to be less precious about their code?
A. At the beginning of the process people were more precious. However, only over three weeks things fell into place.

Q. Why did you leave the BBC team, surely continuity is really important?
A. The team was moved to Salford. He’d still be working there otherwise. All the way through they made sure the code quality was there. He also tried to make sure he

Q. What was the most challenging part of the process for you personally?
A. Working on the new codebase was hard. When it came to working on the new code base the was much gnashing of teeth. But a change in quality came from the team itself.

Q. How do you tell the difference between the small stuff and the big stuff?
A. Every story they worked on had a Dev Check. Everything that was a bug had a regression test.

Q. Did you have a specific day when you did review?
A. No. When a task was completed you did it then and there.

Q. How many other people at the BBC have you infected?
A. A lot of this was through the force of your own personality.

Q. The Dev Check. These reviews would add up to a backlog, how did you get people to push it and prioritise them?
A. During their day-to-day work they were all on IRC. Whenever they needed a Dev Check they had someone who’d say yes and come and perform it.

Q. At what level did you do accessibility testing?
A. During the process they kept in touch with accessibility people at the BBC.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

HTML tags are not allowed.