Practice English Speaking&Listening with: State of the Union | Simon Stewart | #SeConfLondon

Good morning, everyone. Good morning all. Can you hear me at the back? If you can, a

I apologise. Yes, the dog is Matlida Virginia Woof, named after the Roald Dahl character,

Matilda, and Virginia Woof because there's no time for a bad pun! Thank you very much

for the introduction, Marcus. I'm SHS96C on Twitter. It looks like my password. Never

mind! And I am the lead of the Selenium project, and I've been since, oh, we pushed Selenium

1 like a million years ago. So I'm here to talk to you about Selenium and the State of

the Union and how the project is going. We call this talk the State of the Union because

a long time ago there was a Selenium project and the WebDriver project, and we merged the

two of them, and that was Selenium 2 and it seemed amusing on the first day when we were

talking about the first presentation to talk about the State of the Union, and, well, it's

never the wrong time for a bad joke, right! So, let's kick things off. The Deoxyribonucleic

acid - I didn't know if I was going to say that. It's good. DNA, and the rest of you

may know it, it's a double helix structure composed of molecules of guanine, adenine,

and thiamine arranged along a sugar phosphate backbone which is hydrophilic, the pairs in

the middle hydrophobic, which is why it does that structure. Today, we know what it is

for and what it looks like. Even if I hadn't written that at the top, you would have seen

that and known it instantly, right? It's familiar to us. We are casual about throwing the name

around. We talk about the "DNA of our companies" and bits and pieces. We are careless with

our knowledge. It's one of those things we know. We've always known it. But we haven't

always known it. It's been a long time, right? So DNA. Let me take you back to the Cavendish

Laboratory in Cambridge in 1953. And these two gentlemen, Crick and Watson. When we talk

about the discovery of DNA these are the two names we remember. They published their first

articles in 1953 describing the structure of DNA to the world and this is a photo of

their original model, and you can see something very like it in the Science Museum if you

hang around in London after the conference. That's kind of interesting, right? Those are

the two names we think of when we think of DNA. But there's one name that often gets

left out. That's the name of Rosalind Franklin. So the initial model proposed by Crick and

Watson placed the DNA on the outside. The thing that attracted water was on the inside

and the thing that rejected water was on the outside. That's clearly nonsense if you know

anything about molecular chemistry - clearly nonsense, right? Rosalind Franklin was a very

accomplished X-ray crystallographer, laughed and said they were wrong, and, being a lady,

they ignored her. This photo here is known as "Photo 51" and this is the key to cracking

the puzzle of DNA. Like Rosalind Franklin took the BEST photographer ever of the DNA

crystal using X-ray s, and it was this photo and the measurements she took from it that

allowed Watson and Crick to solve the problem of DNA and discover it. Now, there is considerable

controversy around her involvement. Many people say she was cheated of the credit that she

deserved for having made such a fundamental contribution to the discovery of it. There

are arguments that she should have been awarded the Nobel Prize, along with Crick and Watson

for their discovery of DNA. Sadly, she died very young, four years before the Nobel Prize

was awarded for the discovery, and they don't tend to do posthumous awards, but the way

they got that data is kind of shifty. If you ever want to see a bit of a murder mystery

in the world of science, just read up on the history of the discovery of DNA. It's fascinating

stuff. So DNA - don't worry, I'm coming to Selenium! It will happen eventually! But I

do like a little bit of a nerd-out first thing in the morning. That's what we need. We all

have had coffee, right? We're getting the brains going and we are thinking. After 1953,

pieces fell into place pretty quickly. We know now that, within each human, there are

46 chromosomes packaged into the cell's nucleus, right, arranged into 23 pairs, composed of

about 6 billion base pairs, all coiled tightly together. If you stretched the DNA from one

cell all the way out, it would be about two metres long. Your body is composed of billions

of these things. If you put all of the DNA in all of your cells together, it will be

about twice the diameter of the solar system. That's enormous, right? Packaged in that DNA

is the genotype that represents the organisation. Each of us unique? Anyone here not unique?

I'm checking. I expect a Monty Python, "I'm not! " There you go. In the back! All of us

are unique, and our genotype describe us, and there's epigenetics, and all sorts of

things, but our genotypes describe the fundamentals of who we are, and we share a lot in common,

right? We don't look alike. You can't see someone's genotype but we can see the phenotype

which is the physical expression of their genetic characteristics. It describes physical

form and how an organism develops. Father and son, mother and daughter, two siblings

share 50 per cent of their DNA but they lookalike because their genotypes lead to similar phenotypes,

right? So there is obviously an analogy that I'm going to draw here: some of you may be

ahead of me. I see some nodding in the audience. Thank you. Which leads us to punctuated evolution.

If you look at the fossil records, and you go back in time, you don't see a smooth change

in genotype. You see one form being present and suddenly, it snaps, and you get a second

form, and it snaps, and you get a third form. Why does that happen? That happens because

we accumulate changes in the genotype and we do experiments, and the genotypes that

are leading to changes that are less advantageous, don't succeed evolution ly, and the ones that

you do see all over the place, and that leads to a change in form and leads to a change

in the fossil record. So, the theory of punctuated evolution applied to testing web browsers.

We began way back when, actually not only with hand-crafted JS. We had browser simulators,

we had things written in Java, .NET, Python, or Ruby, that simulated a browser, and, back

in the day, that was good, right? This hand-crafted approach. It kind of worked really well, and

people were relatively happy with it. Or at least not so wildly unhappy that they realised

they were in pain. And then, Jason Huggins and some of the original contributors came

up with what is known as Selenium core. There was a Cambrianic explosion of what happened,

loads of testing frameworks for Selenium. Selenium was one of them. There was Windmill,

Wattier, some of the original evolutionary approaches of, "How do we do this?" Selenium

was the one that caught on. The problem was Selenium was trapped in the JavaScript sandbox.

What we needed to do was accumulate more changes in the genotype, to try some more experiments,

and then we had a change in the phenotype when we had the Selenium WebDriver, and WebDriver

binds closely to the core of the browser and now is, in fact, part of the browser we the

W3C process. It's tied tightly to the thing that we use every day. And so we must, by

definition, have reached the galaxy brain moment, except we haven't because none of

us are really doing unit testing. Like one of the arguments that we have all the time,

people up to me and say, "Selenium test is slow." I say, "How many have you got?" With

a big cheesy smile on their faces. 200! Run in fear! I tell people they should have one,

because if you ever say things with nuance, people say, "I don't understand that." So

just one. A minimal number. So this is punctuated evolution. Clearly, genes are the source code

of our project, the phenotype are the things that you download and which you report bugs

on. It is a very stretched and tortured analogy. And there are some lessons we can learn from

this stretched and tortured analogy. The first one is that progress isn't constant, or doesn't

appear to be constant. I'm wearing the T-shirt of SeleniumConf we had in Japan in April months

ago. We released the alpha 1 in Japan, and we have only just released alpha 3, and, if

you were to take a look at the APIs offered by alpha 1 and alpha 3, basically the same.

Like we have the relative locators that have appeared recently, and that's kind of nice,

but, from a user's point of view, there hasn't really been much change. We haven't seen the

leap in functionality that we know is coming. Why is that? Because our genotype, the source

code of the project, is accumulating more and more changes as we try to get things sorted

out. If you followed the commit history of the project, you will have seen a massive

clean-up in our build process and how we do things, you'll have seen us shift tooling

around like nobody's business. We've completely revamped our build process. It's faster, more

efficient, easier to use. You never see that. You should not ever see that unless you're

contributing, right? You don't care about it. But what we are doing is we are making

the project fitter and healthier, and ready for the next stage in its evolution. Another

thing we can learn from the story of DNA and the discovery is that we can learn from each

other. Crick and Watson would not have solved the problem of DNA and its structure without

the information from Rosalind Franklin. Somebody would have got there eventually. It's inevitable

there was a huge amount of research going on at the time. I think Paul Ing in the US

was also frantically looking for, and may have beaten Watson and Crick if he hadn't

gone and done a tour of the US rather than coming to Cambridge. He had that option. But

we can learn from each other. There's so much to learn. If you take a look at the Selenium

source tree, we have this thing in it called the JavaScript Atoms. These are common pieces

of functionality that are shared by all of the browser implementations, and the atoms

came from the original JavaScript code, but not just Selenium's original JavaScript code,

there was some from Selenium Core, some from internal frameworks that I was working out

at Google, some from other projects - windmill code, I'm sure. There is some that we had

written ourselves in WebDriver, right? The idea of tight binding to a browser that a

WebDriver personifies and embodies, that wasn't unique. Bret Pettichord had beaten us to it,

bound tightly to the commentator faces of internet explorer. For those of you who don't

know, Windows is based on a set of com which is a method for emulating in C, and it works

really well. IE is not so much a web browser but a com objects on top of each other wearing

a trench coat and pretending to be a web browser. Jim is in the front saying, "It's true!" It's

funny but it's true. That idea, that came from Wattier. Relative locators, the new feature

we shipped in alpha 3, that is not unique. The first project I saw that in was Sahi,

and Tyco have an implementation of them, and more and more are appearing. One of the things

we discussed at the W3C T pack meeting is the idea of bidirectional communication from

the browser and the test to your local code, right? We could land it and say we invented

this thing but that would not be true. We did not invent it. What we have done is learn

from each other, right? So there is nothing new under the sun. The thing that is original

is how you mix these things together, and how you present them to the world. One things

that we really should do is give credit to people, right? Ideas are cheap. Implementation

is super hard. I'm sure we all have ideas of how to solve problems in our neighbourhood,

or in the world around us, or in the code that we use. The number of times that someone

has come up to me and said, "Why doesn't Selenium just do this?" "Just" is a lethal world. It

means it's basically impossible. So, you know, we should say thank you. Like Jason Huggins.

Thank you to Paul Hammond, Patrick Lightbody, thank you to all the people who did the initial

work to start Selenium. Like thank you to Michael Tan and the current committers for

all the work they've done. Thank you also to Narian Ramim who started Sahi in India.

He blazed the trail of the relative locators. There are so many people who have contributed

code to releases. We have an authors file in each of our releases. You can have a look.

Hundreds of people. Phenomenal. And thank you to Puppeteer and the Chrome debugging

team. It's intensely irritating that everything is embedded down to do a bunch of new work,

but it's really exciting. The things they've showed us is that there are capabilities that

you all want to use in your testing that we should have made available and we are now

scrambling to figure out like, "How do we do that?" Without that kick, we wouldn't be

doing it, right? It's evolution in action. Something has come in. Something is changing,

modifying the genotype, the phenotype of our project to be better, and a better fit for

the problems that you have to solve, and that can only be a good thing. That can only be

a good thing, right? Yes, I hope so. Or terrible. Maybe it's the worse thing in the world. There

is one more lesson we need to take away from all of this. One important thing we need to

remember, right? And that is the state of discourse in our industry and in web testing

in general, right? Selenium got as far as it did because we worked with everyone, right?

We didn't slam the Wattier guys because it's a fight to death. Of course not. We welcomed

them with open arms, collaborated, and had a chat with them, and some of the things they

did gave us insight into how we should do things. Jason, when he was running Selenium

could have said no, don't care about this WebDriver thing, this is the right way to

go. But because we collaborated and talked, we merged the problems, we merged the projects,

and we solved the problem, right? The problem is the thing that we are trying to solve.

We don't care how we do it. It may be because I am an old, old man, with grey in my hair,

and rose-tinted glasses looked at the past, and nostalgia isn't what is used to be, but

I'm pretty sure things have got worse recently, and that worries me. There's a denial of science,

right? We've always said Selenium is a library for browser automation. And we've explored

that domain in great depth. You could have come to any SeleniumConf on any year and you

would have found talks about how to make your tests more stable and more reliable. You would

have found talks about how to make your locators absolutely rock-solid. You would have found

mechanisms for doing reporting and integrating with tool chains. You would have found ways,

patterns, to explore making tests more maintainable, right? We've spent a long time exploring this

space and laying out these ideas. And they're there for you to find. You can go out on to

the internet, quick Google and you will find Page Object, screen play pattern, mechanism

for make locators work, documentation about how you can extend the various bits and pieces,

and the other thing is we've also spent a long time encouraging you not to use the tool.

Like the reason why I got backing when I was at Google of to doing work on Selenium on

WebDriver is because one of the directors heard me talking to one of the teams and encouraging

them not to use WebDriver. It was like, "This is wrong, you're doing the wrong thing." And,

yet, you know, we reach for it, and I guess that's kind of sad, right? Because it means

that we have a reliance on gut feeling. Sad puppy, don't rely on gut feeling. It's an

important signal, right? It tells you something. But we spend a lot of time being told that

Selenium is awful. How many of you work at a company who say, "The Selenium tests are

terrible. The end-to-end pests ..." yes, ? They never pass. The end-to-end test isn't ready.

It doesn't matter. It does that. Just not true. Like, we know how to write stable tests.

We know how to write stable locators. We know how to solve a lot of these problems. I'm

not saying it's trivial - absolutely it's not, that's why we get paid to solve problems

- but we know how to do it and we know the techniques to make sure our continuous pipeline

is green. And, yet, you talk to people, they go, "It's terrible. Oh, it's awful." "Rubbish.

They're slow. I can't make it go any faster." A cheesy quote I'm sure we've seen before:

everyone is entitled to his own opinion but not his own facts." Right? Like, yes, you

can say like this thing is rubbish, but you can't - it isn't rubbish, right? You can have

that opinion, and you're welcome to hold it, but it's not necessarily backed up by the

facts on the ground. There isn't a wider metaphor about modern British politics! Although we

are terribly close to the houses of parliament, so, if you want to protest later ...! Some

examples of discourse where it's not been ideal and the lessons we can learn. The first

one from our own home: we landed relative locators. They are really nifty, right? Like

they could have been written ten years ago, because basically all they're doing is injecting

a bit of JavaScript, and the JavaScript is trivial to write. The problem is, the way

we've done it, we've added it with what we call an atom, right? The atoms weigh in. When

you compile them, they're pretty large - 44 kilobytes is the size of this particular atom.

Every time you do FindElement, off goes 44 kilobytes and back comes a response. The browser

has to process 44 kilobytes of raw compressed JavaScript. It comes back, yeah! I didn't

find anything. There are perfectly valid concerns about the amount of data that is being sent.

And one of the initial problems that people had within the project, with the relative

locators, is that it is too much data. If somebody is using Sauce Labs, this is going

to make their tests super slow. It's going to be awful, it's going to be terrible. Therefore,

relative locators are pointless. It's like wait a second. Wait a second. People have

spent - I have spent - a significant amount of time making these things work. The JavaScript

is trivial, but it's been a long time since I've written JavaScript if I had to hook it

into the compiler, flow it through, and then do the language bindings, and then I had to

think about it, popularise it, and compare it with prior art, and blah, blah, blah. Writing

a feature is a lot of hard work. The thing is, these are going to be super valuable like

talking about where something is in the page visually, it's going to be so useful to so

many of our users because so many of our users are not really deeply familiar with the internal

structure of the DOM but they can say this is clearly above that. We have lowered the

bar, we've made it simpler for people to use this tool. It's valuable. But the pushback

was, you know, pretty upsetting, I will be honest, because I have a thin skin after 20

years in open source. So the lesson that I took away is be gentle with each other. Remember

projects are made of people. When you have criticism, it's fine. Say. It's a perfectly

valid complaint to say this is an awful lot of code being sent across the wire. Can we

do something about that? The answer is yes, we're going to do something about it. We have

introduced a new feature in the W3C script pinning which should make this a lot cheaper,

right? Like we are iterating on it, and, you know, the person who complained was perfectly

correct in saying there has to be a better way of doing this, and there is. But, when

you're saying something is bad, also think about why it was written. And the person on

the other end receiving that, because it's a human being. I love this cat. In Turkey

and South Africa, advertising laws, I understand, mean that when you're doing an advert, you

can't mention your competitors, which is fascinating, right. Saying how bad other people are, which

is so much advertising you see nowadays, and so many blog posts and so many comments, thing

X is terrible, thing Y is awesome, thing X doesn't do this, thing X doesn't integrate

with that, right? There was a post recently by a company that had sponsored SeleniumConf

saying Selenium is terrible. We are breaking up with it. I was like hang on a second, none

of this is fair. None of it is right. It's appealing to gut instincts rather than actual

facts. Misrepresented someone or something to gain an edge is cynical and unhelpful.

And yet we see it all the time. What can we do instead? Build on your strengths. Explain

why your solution is better. When we're talking about some of the changes we are making, we're

not saying everything is awful because it doesn't have relative locators, we are saying,

actually, relative locators are going to be really useful. The stuff we are putting in

to make your builds, your Selenium server more traceable so you can hook it up to tools

like Honeycomb and figure out what the heck has happened once a request leaves your machine,

like, that's really good, right? And when you're talking to people, when you're encouraging

people to do things, the right thing to do is to talk about what you're proud of. Like

what makes your tool, what makes your approach, what makes your idea better? Not what makes

things worse? What makes things terrible. Because, when you do that, you're in a race

to the bottom, and literally no-one is happy. Remember, nobody sets out to do a bad job.

On this slide for those of you who are following at home or can't see, the sign says, "Turn

left" and the arrow points to the right. I am pretty sure the poor person doing the road

marking didn't set out go go, "You know what ...!" You know, they might have, because that

is hilarious! But nobody sets out to do a bad job, right? We hear talks by people from

projects such as Puppeteer and SideX, and they talk about how awful and slow - it turns

out as people use their products, as more people use Puppeteer, they're running into

the same problems we solved years ago. Right? They're adding explicit waits. I've seen so

many Stack Over flow posts saying the element is on the page but I haven't seen it yet.

When I click it, it doesn't work. Like, literally we did - there's a whole chunk of spec about

wait until the element is interactable because that's exactly the problem that you run into.

I mean, it's adorable. But it's a little bit frustrating, and the thing is, if instead

of replicating all the work we had done ten years ago, people are like here's a newing

that you can do, a new capability, and there are amazing capabilities in these talks, like,

you can hook in, like the bidirectional thing means that you can have a mutation observer

observe what is happening on the page, and oh, it's fantastic, and now I can do a weighting

that it wasn't possible to do. Like you can stub out network requests, and so you can

introduce a new mechanism for providing stability, and you could have done it using a proxy in

Selenium, and Jim has written long blog posts about that. But, you know have been , having

it wired into the tool itself is a really nice feature, right? That's fantastic. Talk

about that stuff. Because that's better, and then steal all the good stuff that we have

in our project and in the W3C spec so that, ultimately, people writing web tests can write

the best web tests they can. That would be good, right? It's not a zero-sum game what

we are doing. As a developer, you have a change of tools to use. Sometimes, it's appropriate

to use Selenium; sometimes, it's appropriate to use Jasmine; it's never propose to use

TestNG - I joke! There are cases. TestNG has the categorisation features and it would be

nice and J Unit has those out of the box. No-one tool solves every problem. Some of

them solve many problems simultaneously, and that's good. You pull the tool out of the

toolbox that is most appropriate to the problem you want to solve. That's great. You might

use Puppeteer and Selenium in your tests. Shock, horror! I don't know. You could do

all sorts of, right. It isn't a zero-sum game. It's not actually a game right? Like I think

at the first SeleniumConf Jason Huggins presented some data saying having Selenium on your CV

earned you $20,000 more every year. SeleniumConf, there are people who have built their careers

off the back of browser automation and testing. There are very successful companies that have

done this. Sauce Labs in particular, like just to pick a name out of the blue - I don't

know. Thank you for sponsoring! Richard Bradshaw tweeted recently that he's really excited

about coming here because his journey on his career path started partly at SeleniumConf.

People build their careers, right? When you are slagging something off, when you're tearing

something down, like, people have built their careers on type press, build their careers

on TestNG, and to pull something down and tear it, "I hate Java", it's petulant and

childish. So, yes, there we go. Sorry, I will stop hectoring you now. Thank you very much

for listening. Now, road map! Woo! More Selenium content. What are we doing? Quite often, I

get requests for when are you going to ship Selenium 4? Well, when it is ready. Like,

one of the nice things about being an open source project is that you ship when you're

Aldershot Town done, you don't ship to a timeline, right? But there are things that we are doing.

There are markers on the road so you can track what's happening. The first one is the alphas.

We've done alpha 3. What we need we are doing is slowly adding more capabilities and more

features, right? You may not see it, but we are merging the codebases from the odd Selenium

Grid and the old Selenium server and the old RC server, and mashing them into one relatively

attractive whole, and we are adding capabilities like distributed tracing, and we are adding

things like the relative locators, and we're doing things like switching our network stack,

and we're doing all sorts of things. User facing, the APIs, the tooling is pretty good.

If you've used it before, it continues to work. You can drop in an alpha right now and

start providing feedback provided you're just providing feedback on the client side. It

should all be good. I realise I should all open myself and what unpleasant. There are

some changes coming in IDE as well as Selenium Grid. I think Tomer is speaking at one point.

He will probably cover some of this, but Applitools have been working super hard to make sure

that the next version of IDE will be amazing, and they're moving it to Electron which is

really cool because it allows to you do the capabilities of hooking into the browser to

make recording tests a bit easier. They will post a blog and a road map soon and a design

for people to critique. They really like - like we would really like as a project, for people

to get involved. Like now is the time to go I don't like this bit, or I could change this.

IDE, Codex4 is available, but it's also available as an API for you to extend. If your favourite

language, I don't know, Elixir isn't supported, now is the time to jump in. If you're using

Selenium, files and bugs on the new features. Angie Jones did a blog post about the new

relative locators and found an issue and is going to fix that, and grid, like? I don't

know what I'm doing. CDP. Loads of changes. Once we've got the alphas out, once we've

got the basic functionality out and we think it's okay, we will do a handful of betas.

We will punish it out. We make sure that the language bindings have all the features supported.

It will be nice. It will be feature-complete so I'm expecting that beta period to be pretty

short, and then some time before Chinese new year - I'm not sure which year - we will ship

4.0. Shifting towards dawn. Now we have day light! Not a great joke, sorry. We are going

to get faster with a bit of help. Now is the time to get involved in the project because

now is the time when everything is in flux, and there are workshops on Wednesday when

we are going to cover a bunch of this stuff, so you can learn how to use the tool more

effectively but there is also fix a bug, or become a committer, and we actually fix a

bug, and we actually have had committers join us there. After we ship Selenium 4, so many

options. I am a book nerd like, I love books. And this sets my teeth on edge, because it's

like there's no way I will ever have time to read all this. There are so many options

available for us as a project, for things that could do, right? And things for you to

get involved. The raw APIs are pretty good. They're not perfect - nothing's perfect - but

it's not bad. Fit and finish is - like we need tooling to go here's an easy way to implement

the proxies, like Jim's blog post. Here's how you can make writing new locators easier.

Here's how you can do this, here's how you can do that. Like all the rough edges. Who

has a download a version of Gecko and keep them in sync? One brave person raises their

hands. Fit-and-finish. In the Java world, there's an equivalent tools everywhere. Maybe

it would be nice if they were part of the core project. New technical stack. People

have an irrational dislike of the Java virtual machine, for some inexplicable reason. Maybe

a new technical stack is what it needed. Like we will have distributed things. It will be

easy to pull out bits and pieces, rewrite it, plug it back in. Maybe that's what we

do. Documentation. Like, I will leave it at that because it makes me a little bit weepy.

Diego has been working hard to land a whole bunch of new changes. We have new docs coming,

and now is a great time to get involved with that. The cloud support, the re-architecture

of Selenium that is coming, makes it really easy to hook into AWS, Azure, whatever on-premises

solution you have. Like, it's so many options, right? And reflection s really one reflection,

right? And that's rough edges of the gateway to contribution. Like, when I started doing

open source, Joe Walms, a friend of mine, said one thing you need to do if you ever

want a successful open source project. He said make the APIs as good as they can be

because the edge of your system is the bit that is hardest to change, and then do a really

shitty implementation in the middle, and somebody will be so incensed, they will come in and

tidy it up for you, and then you have a committer, and then do it again, and again. I can assure

you the internals of Selenium were kind of shit. Jim got sucked into maintaining the

IOE driver because the C code was so appalling that, upon review, a Googler went, "How does

this even compile?" And then I've learned something about C that I never wanted to know

after spending a week trying to figure out how it worked. Jim comes along and goes, "I'm

no C++ expert but this appears to work." It's like, thank you, and ran off into the distance.

The other reflection, the other lesson is Rumi quote, raise your words, not your voice.

It's rain that grows flowers, not thunder. Don't be angry at people all the time. Don't

be furious. Don't go this is terrible, this is awful. There are so many things where,

actually, just saying, "Hey, look, have you thought about this? Can we do this? What about

this? Here is a contribution I would like to make." Very seldom do we say no to a contribution.

We sometimes say this is the kind of approach we are taking, this is the way we are going,

would you mind changing it? I don't think we've ever really said no categorically to

something. Be gentle with each other, right? Speak softly. Carry a big stick. Things WebDriver

is older than. Edge. Edgium. The new Chromium we write. That's kind of fun. Chrome. We shipped

the first version of Selenium 2 before Chrome even existed. I mean, it may have existed,

but, you know, it wasn't available to the public. I was actually one of the beta testers

of the Linux version inside Google, and I clearly remember the day when it rendered

everything upside-down. Like they did the Australian release! So, there's Chrome. Current

job. Past job. Job before that. I have had many jobs. WebDriver is older than those.

I got married after I started working on WebDriver. So, you know, WebDriver is older than that.

And people say that WebDriver is my first child, and absolutely correct, because my

son is five years younger than the project. It's kind of interesting. Kind of shapeful.

I'm very fond of him ... [Laughter]. But I shipped WebDriver first. I don't know, do

you ship babies? You know what I mean! He's adorable, by the way. I was speaking to him

this morning. He said, "Do you know what I'm doing?" He said, "Are you talking to lots

of people? " I go, "Yes. " He goes, "Oh". Thanks, son. It keeps me grounded, right?

So the first push of code that I did was 2007, 3 January, sitting on my sofa, drinking a

glass of red wine and I thought this will be done in six months. I am an engineer, I'm

standing by my estimate. It is wildly, wildly incorrect. I'm kind of tired. Right? I've

been doing this since 2006. That was the first time I wrote code that actually we shipped.

This is my puppy. This is Matilda Virginia Woof. She is so adorable! I've been doing

Selenium for a long time, right? And I'm kind of tired. And so Selenium 4 is going to be

my last release. After this, I step back, project happens. We will see what occurs.

So that's going to be fun. Fortunately - or unfortunately, it depends who you are - it

takes us time to ship anything. But Selenium 4 will be my last release. What happens afterwards?

I don't really know. It's going to be exciting, right? I do know that strange women lying

in ponds descripting swords is no basis for a system of government. You're in London,

right? I'm allowed to quote Monty Python. I couldn't find a picture of a lady raising

a sword so there is a sparkler for you. Who is going to lead project? Who is going to

figure out what we are going to do? I don't know. Like it would be nice if I had the answer.

What I do know is that there are some amazing people involved with this project, and have

been for a long time. We have an amazing steering committee. We have people with energy and

vigour throwing code in incredibly rapidly. One reason I have to step down is because

Alexi is catching me up in the number of commits, and it would be shameful if I was still meant

to be leading the project as he overtook me. I don't know what's going to happen. But the

nice thing is the things that I am really good at, starting things, and saying here

is a Brave New World - here's a brave new direction we should be heading in, here's

what we should do, like I'm a great starter, anyone who has worked with me will guarantee

tell you I am a terrible finisher, I don't dot Ts and cross Is - hang on, that's wrong.

That's exactly the point! Like, I'm terrible at this game. I'm really good at big thing,

let's do this! When we get to 80 per cent, I'm like, it works. I'm not a detail person.

Nor am I very good at fit-and-finish. Like, or documentation. I speak a lot, I tweet.

But I don't write down things very often. Because I'm not organised enough to do that.

I'm not very good at going, what will people need? I just think it's trivial when I go

I write it myself. Someone with a different mindset is probably needed. And I have one

great fear for the project which is when I joined Facebook all those years ago, and I

became super busy, the project kind of stalled for a bit, and maybe I should have stood down

then and let someone else take over. But the average length of time that somebody works

for an IT company in the Western world is somewhere between 2 and 3 years. Facebook,

there's a four-year cliff, where at four years, you get all the stock you got when you joined,

and there are people who leave straightaway, right? Attrition is super high in IT companies.

I've been working on this since 2007. There are other people who have been involved with

the project for almost as long. Jim, I think you were 2009? Alexi has been on for four

or five years now. 11 years. The other thing people will tell you is I have absolutely

no memory. Have I told you how bad my memory is? Like the people who even think of as new

on the project have been around for years, right? Like, by rights, if we were a company,

most of those people would be leaving. My great fear is that, as people go I am kind

of tired now, there won't be fresh blood coming through. JavaScript bindings, JSON, they've

got one person. IDE - both employed by Applitools and working on that because of their grace.

Like, hanging by a thread. Java bindings, Alexi and myself. Ruby is probably healthiest

- probably three people. Python - kind of dicey, right? We need help. This is your project.

Like, you've come to a conference. Clearly, you use this. We could do with a hand. So,

as I reach the end of my allotted time, in every sense of the phrase, I'm not going to

die, I'm just leaving, I'm going to ship 4 and go hey! One last thought: does anyone

remember Wild Stallions from Bill and Ted's excellent adventure. The Bill and Ted rule

is the rule we should be following and we move into the future. The Bill and Ted rule

is be excellent to each other. So I hope in this conference, and as you leave the conference

and go out and you're playing with Selenium, and working with the people around you, that

you are excellent to each other. You've been excellent to me. Thank you very much for your

time.