[MUSIC] >> Hello, welcome to Picture Me Coding.

I am one of your hosts, EriK Aker.

Mike Mull is my co-host.

He's here with me today.

Hi, Mike.

>> Hey there.

>> How you doing, Mike?

>> I'm doing okay.

It's a little too hot here in Southern California, but if that's the biggest thing you have to complain about, I guess things are going okay.

>> I have been listening to this album by a guy named John Muq.

M-U-Q, I think is how you pronounce it.

Muck, M-U-Q, I don't know.

He's from Uganda.

He just put out this album produced by Dan Auerbach, and the album's called "Flying Away".

It's been making me happy.

I've been listening to it pretty much non-stop for a couple of weeks.

Some of it's a little easy listening, but there's some really good grooving songs on there.

Really pleasant, satisfying music to listen to.

Did you check it out?

>> I haven't listened to it yet, no.

Dan Auerbach is the Black Keys guy.

>> So it's not bluesy, it's sort of- >> It's not bluesy, no.

I don't know.

It reminds me of "Don't Worry, Be Happy" kind of.

That's a bad connection.

>> It's good.

You should check it out.

It'll make you happy.

>> I could use that, not to listen to that.

>> What have you got?

>> Kind of a weird one this week, or at least weird in the sense that it's outside of my normal taste boundaries.

But I've been listening a lot to the album "Brat" by Charlie XCX.

>> I've heard of this and I have not listened to it.

>> Yes.

I know that this is popular music and it's dance music, and so I've been avoiding it, but it's had the highest rating on Metacritic for months now.

So I decided finally I'm going to have to listen to this thing.

It sounds too interesting to skip.

So it's not all to my taste, but there's definitely a couple of songs on there that I'm mildly obsessed with.

>> Interesting.

>> This one surprises me as a pick for the week here.

>> It is surprising.

I didn't really expect to like it either.

Like I say, there's some songs that are just a little bit too much in the club sorts of songs.

But there's a really good song called "Sympathy is a Knife", which I like the title of and also the song.

There's a song called "Van Dutch", which I'm not sure what it's about, but for some reason it's really fun to listen to.

>> Is this an album that's 10-year-old safe?

My 10-year-old loves pop music, loves dance music.

>> I think it's not like something where I would say, "Oh, this is not inappropriate for kids."

It's not something that's too sexual or that kind of thing.

Now there's some drug references maybe, but I feel like he would probably enjoy parts of it.

>> Okay.

We'll check it out.

This week we've got a topic I find a little hard to approach.

We are forced to approach it by popular demand.

You have had some people write to you directly saying, "You need to talk about this thing."

>> Yeah.

>> All right.

Tell me about the thing.

What are we going to talk about this week?

>> We are going to talk about agile software development methods.

>> All right.

Everybody who's listening to us is now groaning.

>> Yeah.

>> Mike, set the stage for us here.

>> So anybody who's listening to this probably does software, and so probably already knows this, but if you develop software professionally, you probably use some sort of agile process.

Now it's kind of a fang that most people do.

Very likely it's Scrum.

Scrum seems to be the 800-pound gorilla of the industry.

I guess some people do XP and things like that, extreme programming, stuff like that, but Scrum seems to be the popular one.

I don't think many people love it anymore.

I think some people are just resigned to it, and some people are just really pissed off about having to do it.

Sometimes you're one of those things, and sometimes you're the other thing.

>> Sometimes in the same day.

>> Sometimes in the same day.

I keep hearing people say this line, which I think was original.

It's a paraphrase of a quote that I see usually attributed to Churchill about democracy.

Anyway, people say it's the worst way to develop software, except for all the other methods that have been tried.

So I think there's a sense of with agile that we hate it, but we hate the other thing that we'd probably have to do even more.

So we're going to stay with this until we find something we don't hate quite so much.

>> I think my take usually is this is a thing that I am deeply, deeply ambivalent about.

And when I have worked in the past of people who are passionate about it, I am completely mystified by how you could have that opinion about things like this.

>> I've gone through this a couple of times too, where my introduction to Scrum in particular was, I think 2006 or 2007, where the relatively large company I was working with at the time put us through formal training.

They hired people who are experts in it and put us through multi-day training on how to do it.

And as time has gone by, I've gone to companies where they've adopted it more or less rigorously.

And people get really excited about it.

And I have kind of the same reaction, which is maybe you should experience it before you get excited about it.

>> I also imagine people go to those Agile Scrum courses and there's a motivational speaker up on stage saying, "Yes, the power of positive real estate!"

or something like that.

There is a wonderful essay titled, "Aggile and the Long Crisis of Software" by Miriam Posner.

Miriam Posner is a professor at UCLA in information studies.

Now, that has in the past been related to or also called library science.

Posner is an academic who knows about information retrieval, information studies, libraries, things like that.

Now, in this essay, she offers an outsider perspective from when she was working at a library for the first time with a group of software devs and she saw them doing Agile Scrum, something she'd never seen before.

Now, I read this essay a year ago, maybe, and then you sent it to me again as we were preparing for this.

And the beautiful thing about this essay is it's an outsider's perspective.

It's an academic's honest approach to this thing she's encountering.

It's written in an anecdotal style.

It's a very, very nice essay.

>> I would agree.

I think it makes great points and it's also just really well-written.

She said, "Honestly, I was impressed.

In my own work, I often felt as though I was flailing around, never quite sure if I was making progress or doing anything of real value.

The developers, in contrast, seemed to know exactly what they were doing.

If they ran into a roadblock, it was no big deal.

They just dealt with it.

They expected requirements to change as they progressed and the two-week time horizons allowed them to substitute one feature for another or adopt a new framework without starting all over from scratch."

That's the beauty of Agile.

Designed for ultimate flexibility and speed, it requires developers to break every task down into the smallest possible unit.

The emphasis is on getting releases out fast and taking frequent stock, changing directions as necessary.

So this is how she begins the essay and she approaches it as this new process, new to her process that she has respect for.

Like, wow, they seem to be getting a lot done.

Before we really unpack that, though, I think we do have to talk about the manifesto, where it came from, what happened before, and I'm going to really have to lean on your experience to help me situate this or ground this.

Because by the time I started working in the industry, it was already a thing that people had talked about, you would go get interviewed and then one of the questions was, "Have you worked in Agile Scrum environments before?"

And it was almost like a badge of, "Yeah, you've done professional software development."

Maybe we should talk about the manifesto first.

Short enough, we could just read it right here.

What do you think?

Should we start with that?

I think that works, yeah.

All right, I'll give it a read.

So, the Agile Manifesto is four lines with some preamble and a sentence afterwards.

And then there's also the principles, which is a lot longer, but still not as long as even this essay about it.

So they write, "In the manifesto, we are uncovering better ways of developing software by doing it and helping others do it.

Through this work, we have come to value."

And then they have four bullet points.

And it's almost like the Universal Declaration of the Rights of Man or the Bill of Rights or something like that.

They just sort of loft these things into space like, "We hold these truths to be self-evident."

Exactly, yeah.

All right, I'm going to read them now.

"Individuals and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan."

And then they finish with, "There's value and stuff on the right, but we value things on the left more."

So all of these are like, "A is better than B."

A lot of abstract stuff in there.

Do you remember when you first heard about this?

Vaguely, I probably heard about it considerably after it was drafted.

I believe this was kind of famously drafted at this meeting at a ski resort in Utah or something like that.

And about 2001, it was probably a couple of years after that before most working software engineers started to hear about it, I think.

A lot of these people who were in this meeting are now people who are reasonably well known in the industry.

Martin Fowler, Kent Beck, Robert T.

Martin, Uncle Bob was one of the organizers of the meeting.

If you go to the Agile Manifesto page, there's a grainy picture of the guys in the background, and they're all wearing dad jeans and rumpled down shirts.

Yeah, khakis, dockers and stuff.

Yeah, exactly.

They look like they were plucked from the background of the film office space.

Yeah, exactly.

Anyway, I heard about it before the methods started to become common.

And I don't know, I guess it's hard for people now to understand how different this was from what people were actually doing at the time.

Yeah, I can imagine.

But wait, before we talk about the history, I got to say, when I first read these, I was like, that's it?

This stuff is so fuzzy.

It's like every team I've ever been on that's working well, people get this feeling of, whoa, I wish we could bottle this or scale it up.

And nobody ever said, well, let's come up with a whole bunch of super abstract general principles that'll work forever in the future to bottle or scale it up.

It's so fuzzy.

Yeah, it's fuzzy.

There's these 12 principles of agile software, which go along with it, that add a little bit more detail, but still pretty fuzzy.

I think my take on this is that these people who were gathered to make this manifesto, they were all kind of invested in different methodologies that, at the time, they were kind of calling them lightweight methodologies in contrast to the sort of document-heavy approaches that had been used prior.

And so I think what they were trying to do is find all the commonality in those different methods and put it into something that was like pithy and fairly uncontroversial, for the most part, I think engineers reading this were not alarmed by any of it.

Do you think people were excited when they had this?

Like, this is the manifesto.

Yes, this is what I've been looking for.

I think most engineers were actually pretty excited about it, including myself.

I think when you work as a developer and you've been working in an environment where you are writing a lot of documents or making a lot of diagrams or whatever, you have this sense that you are probably not spending your time in the right things because those things are not producing software and maybe they're not producing...

You figure that every job probably has some preliminaries that you have to do before you can get down to making the actual thing, but there's, I think, a sense at this time that a lot of the processes were sort of borrowed from traditional engineering and didn't really apply that well and probably weren't really helping the final product to be that much better.

So I think there was a lot of enthusiasm about the ideas in the manifesto at the time.

I want to talk about that, Priya, just before that, I want to go back to Posner.

Posner says in the Agile and the Long Crisis of Software Essay, quote, "The manifesto directly attacked the bureaucracy, infantilization, and sense of futility that developers deplored.

Developers weren't demanding better pay, they were demanding to be treated as different people."

And I have to admit, when I think about this manifesto, it always feels to me like one of those surveys, like, what are the qualities you're looking for in an ideal mate?

It's like, it's so abstract.

Maybe the reason for this is that they're pretty anti-management.

This is another thing that Posner posed it out.

They claim that they're organizational anarchists.

You can kind of see that here.

They want less dogma, less rigidity.

They want to freely produce software.

So they produce this kind of fuzzy thing.

But they're reacting strongly to something, and you've kind of hinted a little bit at what they're reacting to.

Can you tell us a little bit about what they're reacting to?

What you remember leading up to this in terms of software development practices?

Yeah.

So my first attempts at professional software development were probably in the late 1980s.

So, it manifesto came along in 2001.

So there was a period of a decade or so where I was working in organizations doing either waterfall or some less well-specified version of a design, a writer requirements document, write a specification document, and write the software.

And I think there were two things about it.

I don't really know if I agree with the infantilization part, but I do think there was this sort of frustration that, as a software developer at that time, you could find yourself in situations where you were sort of handed a document and said, "We've done all the hard work for you now.

Make this thing using your coding skills."

We've done all the hard work as in, let me kind of spit this back to you in my naive understanding.

When I hear waterfall, here's what I think.

There is a software architect and they are in an office with walls and a door.

And I don't know what they're doing in there all day.

They end up producing this design document, a spec, right?

And it comes out, maybe it takes them months to produce it.

And the attitude is, well, they already did all the design.

It should be trivial to just code this up.

Like 90% of the work is done by the design.

And it just sort of slides downhill to me.

And then I start trying to build the pieces of whatever it is they're talking about.

And I'm three months in and I'm like, "Yeah, this isn't going to work."

And I get back to them and they are hanging their head and ashamed for me.

And then they go back and they revise their design, takes another three months.

Is this a complete mischaracterization, complete misunderstanding of what waterfall is?

Not entirely, no.

I think the degree to which it was formalized was very dependent on the organization that you worked for, I think.

So, if you were working, say, at a defense contractor, these ideas may have been very nailed down.

There were probably people whose entire job it was to develop a requirements document.

So, their entire profession was to write down what the system should do.

And once they had completed writing down what the system should do, their job was over.

There was no sense in which they were going to try to implement that system.

That's kind of like a PO.

So, you got someone at this time whose whole job is requirements doc.

Then what happens?

Waterfall is like the crap falls slide downhill, right?

That's how waterfall is?

Yeah.

So, at some point, the idea of waterfall is that you have these phases and the one phase feeds into the next phase.

And so, it probably wasn't like when one ended and the next day, the next one started.

There was probably some overlap between the end of one phase and the beginning of the next phase.

And the idea is, like, we're going to be like traditional engineers.

You'll have an architect who designs the bridge and then, I don't actually know where it goes from there.

Eventually, it goes to somebody who builds it, right?

And those people are not at the elite in the layers of respect in the cake of whoever's building the thing.

The people who are just the builders are just builders.

Yeah.

There was a phase where you'd be defining what the thing would do, which was requirements or analysis or something of that nature.

And then you would have a phase where it was, how are we going to do that?

And so, somebody would be writing a document that was maybe architecture, maybe like, literal specifications for APIs or function calls and that kind of thing.

And, you know, again, these things could take months.

So, from the beginning of a project until the point where you actually started to put code into an editor, could be six months, it could be a year on big projects.

And that would drive developers insane, I can imagine.

Well, yeah, I think the thing that was tough about it and the thing that I think Agile was trying, the Agile manifesto was trying to address is that by the time you got this thing that told you what you wanted to build, you were completely isolated from the people who actually wanted to use the software.

There was just no connection between you and the end user.

And I think they were trying to address that.

Some of the companies I worked for in the 90s, it was far less, you know, there weren't that many people, and it was far less formal.

So, like I worked with a bunch of people who were a PhD chemist type people at one point in my career.

And they were also the domain experts.

So, they could figure out what the system needed to do.

But they were also reasonably competent coders.

And so, they could work on the design and implementation of the system.

So, there was a little bit of fluidity there and a little bit of overlap between the roles in certain companies.

Posner says in her essay, "Waterfalls promise of tightly controlled management was a mirage.

No amount of documentation, process, or procedure seen capable of wrestling, development, and predictability.

Software projects were big, expensive, and they seemed to be spiraling out of control."

Does that sound familiar?

Yeah, I mean, it was definitely also a function of the size and complexity of the project, you know, at the time.

If you were working on something really big, like there was the famous Denver Airport fiasco around that.

I don't know that.

What's that one?

I should probably have looked up the details of it.

But there was this famous, they were trying to develop a system for, I think it was like baggage handling or something at the Denver Airport.

And it was extremely long and expensive project, which totally failed and never shipped anything.

There were cases that succeeded.

You know, there were projects where this worked okay.

And I think it had a lot to do with the sort of type of software that you were developing and how much of it you as a company, as a software company could dictate.

If you're trying to develop something where there really wasn't much of a market yet and you were sort of defining the market, then you could probably get away with this because there wasn't, you know, whatever you produced at the end was the thing that was either going to fail or succeed in the marketplace.

And so there wasn't this sense that you were trying to satisfy something that was already a customer expectation.

Tell me it was something that I think I'm naive to, and it's probably a common naivety in our field for people who haven't been in the field as long as you have.

When I think about Agile Scrum, Scrum predates Agile, and it was adapted as this framework.

And then I get a little confused with like Lean.

These are also adapted from manufacturing practices, Toyota manufacturing practices.

In my head, there's, oh, they did waterfall, they did waterfall, they did waterfall, and these guys came up with that manifesto.

And then someone said, hey, we could do Scrum with that.

And then boom, everybody stopped doing waterfall and they switched to this.

Is that really how it happened?

Were there other competing ways of building software?

Is it just a kind of night and day transition like that?

What do you remember?

It definitely was not night and day.

And it was also not the case that people universally accepted that this was a better way to do things.

Just as some context, I think when the manifesto was done in the early 2000s, there was already sort of a movement to more iterative processes.

So the particular system that the company I was working for at the time used from probably 2001 to 2004 or five, something like that, was a variation of what was called the rational unified process.

Rational unified process, which isn't just calling it rational.

Like wasn't that company called rational?

Yeah, there was a company called rational and their process.

Those are the people who invented UML.

They are the people who invented UML, I guess Grady Butch is probably the most famous of them.

I always thought UML came from the Bible or something like tablets came down from the mountain and UML was on it.

And then I was like, wait a minute, a company invented UML?

I didn't realize that.

I just thought it it was a re-inherited it as some ancient wisdom.

My vague recollection of it was that there was this movement to sort of standardize the system for making diagrams, software diagrams, and a standardization process.

And then the people who were driving that sort of turned it into this company called rational.

And then they made this whole rational unified process.

And I derailed it a bit, but this is what you guys were doing at the time, rational unified process?

Yeah.

So we had adopted this as sort of a follow on to the waterfall world.

And it was kind of a weird hybrid of waterfall and what would later be called Agile methods.

So it had phases.

In the software development process or in the history of it being popular?

In its process, it had phases.

And I'm trying to remember if I can remember what they were called.

I know that the first part was inception, I think.

So it was kind of like there was this phase in the process where you're trying to figure out what things were supposed to do.

And then there was a, I think they called it a elaboration, which was trying to figure out what kind of like this would have been the second phase in waterfall.

And then there was a construction phase.

And I can't remember what the fourth one was.

But the idea was that there were these phases.

And then within the phases, you would do iterations.

So the process was not simply that you did the phases one at a time in sequence.

It was you did the phases, but inside of each phase, you had iterations that would produce artifacts kind of like Agile, except the artifacts in the unified process weren't necessarily software.

They could have been diagrams or documents or was this popular at the time?

Were there a lot of companies doing this?

And if so, what happened to it?

I don't know.

I think it was reasonably popular for a couple of years.

There were a bunch of books put out.

And I think people were, you know, it sort of evolved because there were pieces brought in from like the idea of use cases was brought into the RUP.

And I think use cases came out of, oh, it's the guy's name.

I think his name was Ivar's Jacobson or something like that.

It's the guy who had worked on like phone switches and stuff.

He'd invented this idea of use cases.

For a while, it seemed like it was going to be the big thing and nobody really ever loved UML, but it did get popular in the industry to the point where you'd see it on job ads and people would ask about it in job interviews and things like that.

And you still see people talking about UML occasionally.

Yeah, for a long time, I felt like, wow, I really don't know what I'm doing because I don't really know UML concepts well enough.

It felt like it was a thing people would use to judge me.

It's surprising to me here, you say nobody ever loved it.

Yeah, it's, well, there probably were people who loved it.

But it was one of those things that, I mean, there are people still use bits and pieces of it to this day.

I'm sure people, there are people who are still totally bought in on it.

But I see like sequence diagrams all the time.

So there's parts of it that I think are valuable and which are still in reasonably common use.

But the idea with their process, the idea was that you would have all sorts of diagrams, which they call different views of the architecture.

So you would have a view of how things were going to be deployed onto the machines and you would have a view of the object hierarchy and you would have a use case view and so forth.

And I can't imagine doing that for features and web applications.

Well, I think there's probably a certain extent to which web applications and the speed at which things started to move.

And the, I mean, it was already happening in the late 90s, but I think probably after the dot com bust and when things started to pick up again, I think, you know, things were probably moving too fast to at least in the internet world to accommodate the sort of diagramming and analysis that was still a part of the rational unified process.

You think of the products that were launched, I kind of think around 2008 to 2010, like maybe GitHub or Twitter, these are Rails or other apps were later on Django and they were built so spun up so rapidly.

And they rapidly acquired an audience.

They grew at this massive scale.

It's really hard to map this ancient crusty sounding process onto the development of these products, which are really like they change the world really.

Yeah, I don't know.

You know, I can't imagine that the people who built GitHub were writing UML object hierarchy diagrams.

I don't know.

Maybe they were.

Maybe they are now.

It's also possible that, you know, those applications, they didn't really need a lot of end user input, a lot of domain expert input because they were building products that were sort of for the software industry.

Simplify this for me.

Very few bullet points.

What sucked about before Agile?

What was good in the Agile manifesto, if anything?

Very, very simple version of it.

What do you think?

Well, I think from a developer's standpoint, which really is the only thing that matters, the problem as I saw it, and I think the reason why at least initially Agile was a welcome idea was that there's, to this day, I think most people know that when you are trying to figure out how a piece of software should work, sometimes the only way you can make progress is to write some code.

There's a line in the Phoenix project, the novel I always liked, about how you will never know at the beginning what you will end up having known and wish you'd known by the end.

And so building software is a process of discovery always.

Yeah, and even back then, Fred Brooks had made his sort of famous comment about right when to throw away because you will anyway.

So this idea of the throwaway prototype, and the problem, I guess, with a throwaway prototype is that people never throw it away.

But to me, that sort of codified the idea that sometimes the only way you can learn about how a system is going to work is to try stuff and see what works.

It was hard to do that in the world where you were coding to a spec.

Can you imagine doing buildings that way?

I'm just going to try this in this way.

And hopefully nobody dies when they're on the second floor of this cantilevered building.

I'm just going to try something.

You're cool with that, right?

Yeah.

So I guess I have two reactions to that.

One is if you were building a skyscraper, it would probably be frowned upon to go out and try to build a small skyscraper to see, to learn about skyscrapers.

Or do something radically weird in the foundation.

I'm like, at the bottom of the thing, I want to do something nobody's ever done before just to see that it'll work.

We're going to build the rest of the skyscraper on top of this experiment.

Everyone's cool with that, right?

Yeah.

So that does sound inadvisable, but irresponsible.

Irresponsible.

But also, I guess my counter to that would be that people didn't start building skyscrapers.

So nobody, it wasn't like, well, we figured out a log cabin, let's build a 200 story building now.

There was this progress of doing things and figuring out how they worked and building smaller buildings and doing two floors and three floors and 10 floors.

So by the time people were building skyscrapers, there was knowledge about how to build foundations and geology and mechanical engineering.

And so there was this body of knowledge that had been built up as a progression over time.

So I think what the difficulty with software is that every time you're building something new, there's some stuff that you can probably borrow from the history of what you've done before, but there's other stuff you just don't know.

And so you do have to go out and build the foundation and see if the building falls over.

And that is the basic issue, I think, with the waterfall and the more document-oriented versions of software development that people struggled with.

Even a rationally unified process suffers from that, you think?

So yes and no.

I think they made some moves there that I think were a good thing.

And there are some aspects of it that I carried along with me throughout the rest of my career, even when I was in places doing Agile.

Sometimes I did them without telling people.

So for instance, one idea that I really liked is that you would build what they call an architectural baseline.

So the idea here is that the architecture is important.

It's hard to change late in the building of a system.

And so the idea was to try to start building an architecture at the very early stages of the system, even if there wasn't a lot of functionality to it.

So the idea being that you could start to look at how things integrated much earlier.

One of the liabilities of the previous methods, waterfall and spiral and stuff like that, was that you would tend to come up with these really well-defined modules of software that did specific things functionally.

And then very late in the process, you would try to integrate them into the larger system.

It sounds really rigid and overly specified.

It was very rigid and as everybody knows, at least everybody knows now, integration is really one of the hard parts.

It's very difficult to get those pieces to play nice with each other.

And so having a process whereby you start iterating on that integration aspect early, I think was insightful and valuable.

It's something that I've kind of done informally at least in almost every company I've worked for afterwards.

So naively, it sounds like every environment I've ever been in where we need to design a new system and so we just start putting things up on a whiteboard and they're like blobs representing services with discrete responsibilities and arrows connecting them.

That sounds like what you're talking about.

And it does seem like the gut response of what's the first thing I need to figure out here?

What are my players?

How will they talk to each other?

Yeah, I think people do it more and less formally, but even in these situations where you start to draw the boxes and arrows on the whiteboard, I think there's a tendency with people to say, "Okay, I'm going to do this box now."

And they go out and they try to build the internals of that particular box and then they forget about the arrows.

And so I think the idea of the architectural baseline, or at least the way I've interpreted it over the years, is you start to build the connections.

You start to look at what the arrows do very early in the process, even if the boxes don't have a lot in them yet.

And I still think that's a valuable way to think about things because it's hard to go from a system that is highly coupled to a system that is event-based, let's say, in the later stages, even if you have the functionality of the particular pieces fairly well.

Interesting.

So architecture is hard to adapt.

We've got to try to get it right up front.

All right, Mike, we have not even covered a large volume of agile criticisms that have emerged in the 20 years since the agile manifesto came out.

And we're pretty much out of time.

So next week, our job is to trash agile as, I guess, representatives of voices in our industry.

We have to trash it because that's a pretty common thing that's happening nowadays.

Yeah, and I certainly don't want to leave people with the impression that we like it.

Well, what I said was I am deeply ambivalent about it.

And so here's what I want next week.

Tune in as Mike and I will plumb the depths of our ambivalence and/or dislike for agile processes.

Sound good, Mike?

I look forward to it.

All right.

Thanks so much for hanging out with me today, talking about the prehistory of agile and where it came from.

And I will see you next week.

Thanks.

See you next time.

Bye-bye.