Web Standards at Yahoo! (with transcript)

How do you encourage your organization to take web standards seriously?  How can you enforce standards across a big company with no central dictatorship?  What is the one question that you better not answer wrong in a Yahoo! job interview?

The developers at Yahoo! probably write more HTML, CSS, and AJAX than any other organization on earth.  They need their code to work on multiple browsers and operating systems, so they save a ton of money by focusing web standards.  They were one of the biggest cheerleaders of the CSS improvements in IE7, since it means they can retire the IE6 hacks sooner.  In this interview, Nate Koechley of Yahoo! explains how Yahoo! creates a standards-first culture.

Joshua Allen: Hi, I'm with Nate from Yahoo!. So do you want to tell us your name and what you do at Yahoo!?

Nate Koechley: Sure. My name is Nate Koechley. I work on the YUI, the Yahoo! User Interface library open source JavaScript library team. I was one of the early web developers at Yahoo!.

For the last five and a half years I've been involved with growing the professional discipline of front-end engineering at Yahoo!, setting strategy there and trying to evangelize a better way.

Joshua: OK. So this is one of the main reasons I wanted to interview you for MIX Online. It seems like Yahoo! Has a ton of products out there. You've got "Answers." You've got "Yahoo! Maps." "Yahoo! Mail" is huge.

Nate: It's a long list, yeah, about a hundred different products: sports, news, movies and everything else.

Joshua: What a lot of people don't realize is this is also spread out over some pretty broad geographical areas and autonomous teams and so on. So really, Yahoo! Consistently rates well on support of web standards. Your feeds always validate. So how do you guys keep it coordinated among all these teams?

Nate: That's a great question. First of all, yeah, we're about four or five hundred dedicated front-end engineers spread out over maybe 30 offices around the world. So it's a large endeavor.

We don't really have a command-and-control structure. What I try to do is instill values in the company and instill a culture of caring about these things, and then leave it up to the individual developers to find a particular solution.

Joshua: OK. So when did you get started on that? Roughly how long have you been doing that?

Nate: I joined Yahoo! About five and a half years ago now and joined a team of two or three people who all started about the same time. Prior to that, there weren't any web developers at Yahoo!.

Technology was more simple back then, so designers and engineers would trade off. There was no discipline focused on the code that goes to the browser. So one way I define front-end engineering is we're responsible for everything you see when go to "view source."

The first thing I did was wage a campaign against font tags. We'll start at the beginning and get that out of there. We started introducing CSS to Yahoo!, basically just on a project-by-project basis. We didn't really tell anybody. We just started doing it.

And then we started to grow the team. We recruited people who had that shared vision. We recognized early on that it was going to be a long-term project. It can't just be a top-down mandate. And so we're still getting better and better at it five and a half years later.

Joshua: OK. So if it's more like an evangelism effort, do you see this as something that you scale out through broadcasting best practices out to the organization? Or do you have to do a lot of...

Nate: It's both. It's everything. It takes a lot of small things and then a couple of big things. We do a lot of small things like code reviews and code preliminaries, where we actually look at a design before we start writing any code. Just talk about how we're going to approach that particular design or that particular site.

We keep internal blogs, internal wikis and have brown bag lunch meetings. And a lot of person-to-person talking it out and trying to share what we're all learning.

At the other end of the spectrum, there are the larger things. Which like I said, you can't really have a top-down mandate for it, but you can try to tell everybody that we care about these things. That one way is better than another way in a broader scope.

So you need some organizational support. You need to know which things to really care about and which ones to let slide for now, is how to go at it. So big and small and trying to hit it from all angles.

Joshua: In five and a half years, Yahoo! Has acquired a number of other companies and added a lot of new projects. So do you see your job as being easier now, or harder than it was when you started out?

Nate: That's a good question. Well definitely easier because a lot of people who are joining us now have these values already. It's what we look for when we're hiring, among other things.

Joshua: So it's like an interview question? If they don't know what the CSS validator is, then they don't get hired?

Nate: Exactly. So we filter on the way in. Since we're now a bigger organization, we have some processes in place so we do new-hire education, teaching people about the way we're looking at things and what resources are available to them.

But of course it's harder also because there's just more people, more projects. The web always moves fast so it's hard to keep on top of everything and balance deadlines and quality and everything else.

Joshua: Speaking of the web moving fast, it seems like there's been an increase in the use of AJAX and even the RIA technologies like Flash is used in certain places and WPF on some things within Yahoo!. So how does that impact your job?

Nate: Everyday. One of the slides I like to show people is what web developers are supposed to know. And so we look at the seven different knowledge areas: HTML, CSS, DOM, JavaScript, browser model, and other things.

Then we look at the different subsets of those. So there is the specification. Then there is the implementation. How you guys implemented the spec and how all the other browser vendors actually implemented the spec. The delta there.

There's another delta between how a certain vendor wanted to implement it versus how they actually did. The defect. And then kind of a thread through that is the theory of the practicality, what's important and what we care about and what makes sense for our business.

And we're doing those. So, we've got those seven knowledge areas, four facets each, across multiple browser platforms, across multiple operating systems, with multiple rendering modes. So, you do the math and the number is 672 things which we're trying to keep track of.

Joshua: Yeah. And then Apple decides to ship another browser on Windows, right?

Nate: Yeah. So it's a lot of things, and those are just kind of the core, or classical, fun in engineering aspects. Now we're making decisions between Flash and a bunch of other technologies, and those impacts.

It's fun. It's lots to think about. And that's not even talking about localization and accessibility and all these other things. It's a huge problem space, but it's a fun one to be working in.

Joshua: So, do you also have responsibility then for evangelizing localization standards, accessibility practices, and those sorts of things?

Nate: Well, I think high-quality web development takes all of those things into account. One thing we've been recognizing more and more lately is that in addition to just a wholesale adoption of web standards, I've enjoyed looking back at some of the...

If you go to the W3C and look at the big slash design principles or something, Sir Tim has just a bunch of these notes of things he thought were important when he was crafting the Internet as a whole.

So, in a addition to the particular rules, we're also trying to look at a lot of smart people before us who have thought about these things and we're trying to go with that flow, work with that grain, wherever we can.

So, a lot of time we find, we start separating layers, that make localization easier, that makes accessibility more complete. Luckily, a lot of these thing kind of work together and support each other.

Joshua: OK. So you mentioned kind of splitting out Java Script form the code, and the style from the HTML, and so on. One of the things that we talk about a lot is the developer-designer split as well.

Do you have a kind of strict developer-designer split at Yahoo!, and how does that impact, if anything?

Nate: So, when I was first hired and Mike Lee, and Jack Choo, and Chanel, and the other folks that were kind of the charter group of developers, we were actually hired into the "user experience and design" group.

I think our job initially was to help designers work faster and to take some of the templating work off their desks so they could focus more on the interaction. And then about two years ago, in the States at least -- it's a little bit different globally still -- but web development became shifted organizationally and is now part of the engineering department at Yahoo!.

So that was good. It got us more control over the entire stack, and the ability to have the things we care about filtered through all those different pieces. But it definitely strained... Or it reduced our face time with all the designers.

So we've really had to focus and remember to... I always look at web development as kind of in between design and development, and business and product. We kind of touch every thing and we're the last people to touch it before it goes out. So we have responsibilities to everybody.

But there is a pretty clean split. Web development is now part of engineering. We still have some that do a lot or prototyping and a lot of R&D in the design department. But more or less it's first-rate engineering, that's what counts.

Joshua: OK. So, I guess, one other question. You have the YUI libraries and you have these, basically things that you make available to the general public to be able to build their websites as well.

So, how much impact do you think that has had internally on your processes?

Nate: Well, one thing I like to say about the YUI library, or the reason you would use any library at all, is that there's no shortage of better things to do with the time than to keep re-inventing the wheel.

We've all got tons of work, we've all got great interfaces, we're dreaming off and wanting to build. And to spend time writing another, you know, getting on with my class method or something else isn't a smart use of time.

So I think that having a library that acts as a magnet for all the intelligence of all the developers, and now, all our users around the world, takes that burden off each individual project and each individual developer.

YUI has been implemented on almost everything at Yahoo! Now. It's on every new project. It's a shoulder that other people stand on. There's still plenty of work to be done. It's not a fix at all. But it gets people off on the right foot.

Joshua: Awesome. So, do you have any final words of advice to people who are trying to evangelize web standards within their own organization?

Nate: It's really a cultural thing. Like I said, developers tend to be pretty individualistic on their own. They don't like to be told how to do something. But I find that a lot of developers really care about these things at the end of the day.

I just had somebody come up to me, some new hire a couple of weeks ago. It was in my class that I teach to new hires. And he came up afterwards and he said, "Wow, it's great to be here and to know..."

He said he was at a smaller company and they used to be 100% in web standards. Then they grew a little bit bigger and they kind of took their eye off the prize. And he said it was really refreshing to come to a company that cared about these things, even though we're so large and moving so fast, we're still holding those values up high.

And I think that's what it comes down to. It's a matter of keeping it part of the culture and expecting high-quality work out of people. And working holistically and thinking long-term.

We've got code on our site that's 10 years old, we're writing much better code now. It's going to have a lot longer life, and we're all in this for the long haul. It's still the early days and it's worth it to do it right.

Joshua: OK, great. Thank you for your time.

Nate: Thanks a lot for having me.