(upbeat music) - So, this was supposed to be replaced by the title of the talk. I never came up with the title. And then I thought, "Actually, FIXME is a
good title for this talk." So, FIXME this. As Evan just said, I've
been doing this for a while. In fact, I've been doing
information systems, being involved in that world,
for 20 years, or thereabouts. Which is a really weird
thing for me to say because when I got started I
was about 20 years old. And this concept of being
involved in an industry for two decades just seemed foreign. Now I've been around
for about two decades, and in some ways, things are no different. I have the same fire to fix the future. But instead of having that
fueled in some ways by sort of youthful ignorance, which I think is a very valuable thing, and one of the things I do
miss from the past is that, that ignorance, that bliss. I have something else instead,
which is a sense of history. And that sense of history is
both a blessing and a curse. In some ways it's an
easy trap to fall into to just reminisce, and be
content with what we did, and where we were. In another way it's a blessing because it gives you a sense of scale. The technology industry seems like it moves so incredibly quickly. Not a week goes by, and
something new is announced, and you think, "Oh man, everything I knew "is all of a sudden old or outdated," when really, the broad
strokes, the tectonic plates, they don't move all that fast. If you think about the main technology that underpins a lot of the applications that people in this
room, and that I work on is the relational database. It's basically been
around in its current form for I don't know how long. More than the 20 years that I-- I should have looked that up. I would have started, "The relational database
was invented in 1954." But I don't actually know. So anyway, it's been
around for a long time, and it's still at the
core of our applications, a lot of applications. We've had other forms of storage come, and in many senses go,
and things have changed, but in an industry that
supposedly moves so quickly it's still interesting to
think about the fact that one of those core pieces
has been around for so long. Ruby itself has been
around for 25 years now. But in that time, things
have still changed. Even if some of the things stay the same, some things do change. One of the things that have
changed since I started is this notion of the DBA,
the database administrator. The person whose job it is to guard this precious data store from the savages, application developers. This guardian role, when I got
started about 20 years ago, was pretty common. You didn't have to be that big of a team before you had someone whose job was to defend the database. Now I'd be surprised if
most people in this room are on teams that have a full-time DBA. Why did that change? What happened to the relational
database and to our industry such that we no longer needed,
in most teams, the DBA? It's not that this role
is entirely extinct. It's just exotic. You have to go to exotic
places and exotic companies, very large institutions,
before you find this again. It's not sort of commonplace in small to medium sized businesses. What happened? So some of what happened was advances just in the underlying hardware. One of the reasons we had
DBAs were to make sure that the relational
database stayed performant. Now the ceiling for what a database can do without having someone
who's a trained professional tinker with it all day, is so much higher. We've raised the ceiling
through technological progress in such a way we don't
have to spend all day having someone just tweak the dials in such a way that it won't fall over. In fact, at Basecamp, where I work, we have a relatively large database. We've manage to launch
all sorts of features with the wrong indexes,
to tens of thousands, if not hundreds of thousands of people, and not realize it until it fell over like three months later. That is progress.
(laughter) There is progress in how long
we're allowed to stay ignorant about the underlying fundamentals
of technology that we use. And I mean that seriously and not glibly, that that is actually progress. The fact that we can
push out considerations that before had to be made up front and very early in the process
is a huge step forward. But the role of the DBA, I'd say, is classical creative destruction. We used to have this role in
our industry that employed, as a percentage of people
who were in the industry, a fair number of people. And today, we don't. It's kind of gone away to some notion. And it's not just the role.
It's not just the DBA. It's also a bunch of techniques that revolve around this
relational database, this core of our applications. One of those techniques is
a technique call sharding. Sharding is this concept where, when you reach a certain tipping point in how much data you store, and how many people are
accessing that data, you start splitting up
your single database into multiple databases such that customers one to 10,000
goes to this database, and 10,000 through 20,000
go to this database. And that adds a fair amount of complexity. Before you had one database
and you had to worry about migrating one database,
operating one database, accessing one database. Then you shard your database, and all of a sudden you
have that problem times 10. Now, sharding came into my
world around 2007 or so. We were at Basecamp just
getting towards the ceiling of what we could do
with a single database. And we started doing our
projections and we could see, oh, we are sort of getting
so and so much new data every month, in x amount of months, we're gonna hit the ceiling here. We'll run out of cache
storage for the database. If we're gonna have to
hit these spinning disks, then we're gonna be in trouble. It's actually funny. Mark Imbriaco, who is speaking at the end of day of the keynote, was, I believe, at the time the sole system administrator at Basecamp. And we were talking about this, "Oh, we really need to put
time aside to do sharding. "We need to figure out
the techniques to do it. "We need to set it up. We
need to block away time." We're like, "This sounds like
it's gonna be a long process. "It's gonna be a long project. "Are we gonna take this three months, "or whatever it's going to be to do it?" And I sort of treated this
with the same approach that I treat a lot of things: eh, let's worry about it tomorrow. And tomorrow came, right? And we were like, "Oh, we
got a little closer to limit. "But yeah, you know what? "These boxes that we have at..." I forget the history specifically. Maybe it was at Rackspace. Or Rackspace now has an option that we can get some more RAM, so we can extend our cache storage and we get a little more time. But, I mean, we're still
gonna need to do it. Like, for sure, there's
no way that we can wait more than at least another year. All right, so then the
other year comes around, and again, we got bailed
out by technology. I think the big bailout came
when SSDs became a thing, like when we were no longer
spinning disks around and all of a sudden
the ceiling just jumped an order of magnitude. To this day, all versions of
Basecamp have avoided sharding. We don't shard any of our applications. All of our applications
have one main database that's being written to. Then we have some replicas
that are being read from, but that doesn't really
have any material complexity compared to sharding, and splitting things up
into separate databases. We were able to wait it out, let creative destruction,
and technological progress, and software progress,
take a whole problem, and basically, we don't need to do that. Oh, by the way, we don't employ
at DBAs at Basecamp either. Here's a human side of it,
and a pattern side of it, that we no longer need
to deal with at all. That's real progress. We're still dealing with
the relational database, but we've taken these facets of it that used to be absolutely givens, that once you reached a certain
size you had to have a DBA, and you had to do things like sharding, and we don't need to do that anymore. Now, that progress, when
you look back at it now over the course of 20
years seems just obvious. Like, of course. And it's a little easier
in these two cases, although I'm sure you'll
find people who will staunchly advocate for both
getting ready for sharding and getting ready for hiring a DBA. And at some point you do
need to do these things. I'm sure GitHub, or other
large scale applications that reach close to the
internet scale or thereabout, of course you need to do sharding. But it's become an exotic technique, just like the DBA has become
a bit of an exotic role. Now, some of this progress doesn't happen as smoothly or as cleanly as in just, oh, we stopped doing these things. When I first started
working on Active Record, ORMs were controversial. There were actually real
debates about whether it was a good idea to wrap
the relational database in an object interface,
because you know what, how can your API, how can
something like Active Record be as performant, or as efficient, as handwritten SQL statements? We debated these things. And there were a lot of people like, "I'm never gonna use that ORM." Like, "You're just lazy if
you don't write your own SQL. "And by the way, you're
gonna hit all these problems, "and you're gonna hit all
these issues if you do that." Like, imagine all the queries
that ORM untuned can kick off. And it can. I know that because the
vast majority of pages, again, at Basecamp, are untuned. I've recently done a couple
of performance dives, and when I look at the
number of SQL queries that Active Record will kick off on a single page in Basecamp
it's sometimes hundreds. If you told that to
people 10, 15 years ago, that like, oh, we'd just be kicking off, willy nilly, hundreds of SQL queries on a single page for a single user, they'd be like, "You're out of your mind. "There's no way you
can make that perform." But we did. Progress both in terms of
technology and in terms of the API allowed it to move to a higher level. That higher level was one
where we no longer needed to deal most of the time,
most of our days, with SQL, even though, again,
the relational database is absolutely at the core of what we do. Now there's a pattern there, that even though something remains at the core of what we do, and even though at times
we do need to dive into it, and there will be use cases
where we need sort of the past exotica of techniques,
and people, and roles, most of the time we don't
need to worry about it. In much the same way that like, hey, the CPU is at the core
of a lot of what we do. We don't need to worry
about assembler anymore. We don't need to worry about things like garbage collection, most of the time. It used to be a huge thing that people worried
intensely about all the time. "There's no way a garbage
collector can be efficient enough "for us to be able to fit our system "into the memory that we have." And now, in the Ruby community, the only person who has to
worry about garbage collection, is pretty much Aaron, and
the rest of Ruby Core. That's real progress. We've taken all our problems
and given them to Aaron. And now if our Rails
program uses to much memory we can just shout, "Aaron! Fix it!" That's great. Right? That's real progress, that we can just always
be blaming one person, and we no longer need to really
learn these fundamentals. And that's what I love about
that word fundamentals, because usually programmers, when they speak about fundamentals, they speak in these tones about, "Everyone should really
learn the fundamentals." There's a lot of fundamentals
in software development that no one learns anymore. No one who just works
on information systems need to know the intricacies
of how a CPU works. They might, still, if they want to, or they might end up in a specialized role where they need to. And we're getting to that
point with other things. No SQL used to mean that people were using a
non-relational database, and losing all their data. Now No SQL really means you get
to use a relational database without writing any SQL. I'd be surprised if
most people in this room write SQL, fully-formed SQL
statements, on a daily basis. We just don't do that anymore. When I got started, again, 20 years ago, I would write fully-formed SQL statements at the top of my PHP script and I would embed the parameters straight from the web request. Thankfully we don't do that anymore. And generally speaking, we
don't need to write SQL anymore. It's not that we're not using it, just in the same way we
continue to use assembler. It's just that we don't see
it and we don't write it. In some ways we've moved
so far up the chain that SQL to some extent,
and in some capacity, is like a form of assembler. It's a low-level language that we occasionally need to dig into, but most of the time we
can just blissfully ignore and be all the better for it. In fact, I just, as I was
putting these slides together, looked through the Basecamp 3 code base, which is a relatively large code base. Hundreds of screens, and
multiple hundreds of models. We do not have a single
fully-formed SQL statement in any of that code. We used to. When we made the first
versions of Active Record we still sort of had a
preliminary early stage, and we still occasionally
need to dig down, and now we don't anymore. This is one of those things
that just become apparent when you look over the arc
of something like 20 years. Like, oh yeah, we used
to do all these things, and now we don't do them anymore. Now, some of that, as I
said, comes automatically, it comes for free. It comes because we get
SSDs, we get cheap RAM, we get faster CPUs, we get all this stuff that just sort of shows up,
and makes our lives easier. And all of a sudden
there's this tipping point that we may not even notice wherein certain things are
just no longer necessary. The other part of this, which is the part that
I'm really interested in, is the part that I
actually have an impact on, and that we have an impact
on, is conceptual compression. This idea that we have
a multitude of concepts that we need to worry about, entangle, and juggle as we're making applications. And at certain periods and times, certain concepts loomed very large. SQL used to loom very large, and you had to really study your SQL, and figure out how to write
it, and have that top of mind to be able to make applications. Today, again, if you ask me, can you write a fully
formed insert statement on the spot right now on the blackboard? I'd probably get it wrong. I'd forget where the parentheses went. And that's not even to
speak about join statements or any of the more sort of
complicated usages of SQL. It's just not something
that's top of mind anymore. I used to. I used to write
that stuff all the time. And then through progress, through ORMs, through Active Record, we've managed to compress that concept into something that's
maybe a 10th, or a 100th, of the size that it used to be. Now, conceptual compression, I think, is probably the most important thing that we're doing in the Rails development. It's the most important thing for me as I think through what should I work on, and how should we progress, because there are all these concepts. And I'll talk about how, in some ways, we're losing the battle
on this compression front. And there are more and more
concepts that are being forced upon us, that if
we don't compress the ones we're getting a greater and
deeper understanding of, we just won't have room in our head for the new ones we need to worry about. Now, up until this point I think it sounds not controversial. Like, we all want to compress
concepts, at least in theory. But I think in practice it's different. I think one of the reasons it's different is because a lot of programmers like to play with LEGOs. And I like to play with LEGOs. I mean, that's not
really saying that much, because I'm pretty much
nationally obligated as a Dane to like LEGOs. But nonetheless, I like
playing with LEGOs. It's fun to put things together. It's fun to build things from scratch. It's fun to build things
from individual small pieces. The problem, I think, comes in is once you get used to a
certain size of blocks. We have this 2x8 here, like this is the size of the
block I start putting together. You kind of start thinking
like that is your world, like this is a choice that I'm making about the size of the block
that I'm putting together, and that's really important, because hey, this is what I used to
be doing all the time, so of course it's important, because what I do is important. Now, sometimes the size
of the block changes. And a lot of people will be like, "No, no, no, no. That's too coarsely." Like, "That's a toy." Like, "That's Duplo. "Duplo is for fucking kids. "I'm an adult. I play
with goddamned LEGOs. "I like the size of my blocks." And I think that that's what
we went through with ORMs, controversy, with the idea that like you should be handwriting
your SQL most of the time. If you were used to writing
your SQL most of the time you went like, "What the fuck?" Like, "Now you're telling
me that I shouldn't "be putting these blocks
together individually anymore. "That's just wrong, because you know what? "I can build anything with my blocks. "I can build the goddamn
Millennium Falcon with my blocks, "and look at that. "Isn't that cool?" Yeah, it's cool. You're
building things with blocks. I mean, I appreciate the sort of memory that goes into that, and the dexterity that goes into that. But if we all just want
the Millennium Falcon, why are we all fucking
building it from scratch? You can buy that shit on Amazon. (laughter)
Pre-assembled! And like, look at the fidelity there. Like, what crude imitation of
the Millennium Falcon is that compared to that? That actually kind of
looks like the same thing. But we sort of get lulled into the belief that unless I build it myself, it's really not as brittle, and as ugly, and whatever, as this thing. We have this sense of
innate ownership, I think, that comes in from when we build something from the small pieces. But it's not that helpful, and we're doing it self-indulgently. You're not building the
Millennium Falcon out of LEGOs because you get a better
Millennium Falcon. It's a little bit like
what we used to call this home rolled framework. You can get something that kind of works and is fun to play with. But like hey, if you just put
industrial processes together and build on top of decades
of production techniques honed by people, you will
get a better product. And I think that that's
sort of the hard part. That's why this notion
of conceptual compression sounds appealing when you
talk about it in the abstract, but as soon as you start
applying it to real concepts, concepts that you used to
worry about all the time, it gets a lot more dicey. But yet we must. If you look at the
history of Ruby on Rails, it's been around for about 15 years now, and over that arc, when
I'm looking back at it in my rose-colored glasses, I like to think that what we've been doing is a lot of this conceptual compression. We've taken a lot of concepts that people used to worry about and have to figure out
from first principles and then we've turned them into something that most people
don't have to worry about most of the time. And by doing so, we've
pushed out the need for specialization and sophistication. That a single programmer today can start sooner, with less knowledge, and build better things. That is a monumental improvement. The fact that we've been able to sort of collapse things to a point where a generalist can do what a
team used to be required to do is real progress. Because I think the problem is when you push into these
areas of specialization, when you get concepts that are so large and uncompressed that they
have to occupy the mind of a single individual, or
take up a large (mumbling), you get too much mind space
to worry about that thing. The DBA who used to do
that as a full-time job had all day to think
about the risk factors, and all the nasty
scenarios that could happen if you just let these unwashed programmers write their own store procedures. All of these factors that
sort of could go wrong, they got to worry about that and tinker with it all day. That's just too much brain
to apply to one problem. And I think we're sort of standing on that balance
with a lot of concepts. That the concepts seem like, well this is really a whole thing. We need to make this a
person's job to do this thing. Rather than being, yeah, right now this concept is quite large and it will occupy most of
the brain space of someone. But if we compress it, it won't. We could fit it in alongside all of the other concepts
that we need to do. And that that's a better model. That it's a better model to search for ways to compress the concepts
that we need to juggle rather than search for
people who can fathom the complexity of the problem and the concepts that we're dealing with. So when I think about,
as a framework builder, what is it that I do, and where is it that I
want to spend my time, it is to think about it in the sense that can we take a concept and basically compress it in such a way that you can get 80% of
the value of that concept in about 20% of the effort, or better. Like that's just one compression rate. In many cases we've gotten
even better compression rates. I'd say the compression
rate around SQL right now is like one to 20. We spend like 5% of the time on SQL that we used to spend on it. And that's real progress. Because as I said, the list of things you ought to know as a developer grows all the time. That's some of where the sense of, "Oh, shit is moving so fast "and I can't keep up," comes from. Because there's so many things that are constantly popping up and mostly in forms of new concepts. Oh, all of a sudden I need
to worry about this too now? Security. I think security is far
more at the forefront of people's minds than it was 20 years ago when you just string
interpolated query parameters string from the request, most of the time, and you had all these ways of injection. And we just didn't really... It was there, the concept was there, most people just didn't focus about it because they were so busy
focusing on things like how to write a performant SQL query. Now when we free up space by compressing the existing battery of concepts
that we need to deal with, we have this space to
spend on other things. But yet still, the list of things you
ought to know keeps growing. And the problem with that is it increases the barrier to entry. The more shit, the more concepts that you're required to
know before you kind of feel like you're just basically proficient in this industry of
building information systems and web systems, the harder
it is to get started, the fewer people feel
like that's something that they could actually do. Again, if I look at the
history of Ruby on Rails, the usages of the framework
that I'm most proud of, the emails that I get that
makes me smile the most, is not some large company that wrote me, "Hey, do you know what? We measured this. "Rails made us 17.5% more
efficient and productive, "and that has really
helped our bottom line." I don't give a shit. I don't really care about
those forms of progress. What I care about is when
I get an email from like, "Hey, you know what? I
used to be a musician, "and I wanted to create a
website for other musicians "to do this, that, and the other thing. "I didn't think I could do this at all. "I was not a programmer. "Then I read this Rails tutorial. "I figured out how to do things. "And like, hey, look at my site. "There's like 10,000 musicians
on that now, doing that." You're like, holy shit,
that is really a change. Like if I go back 20 years and think about who were the people, who
were the organizations that were allowed to
launch information systems, and build them, and the process and so on that you were required to do. Those are not the same people. You did not get the amount of stories from people like that. The advanced bootcamps. The fact that you can take someone who just has a basic understanding, or none at all, about programming. And in about three to X amount of months you can turn out someone
who's juniorly proficient in what we do. That is amazing. And that is a real gift that I think we're not treating with the
respect that we should, as an industry. And the fact that we've
managed to compress so many of these concepts to the point where someone can not
only not need to deal with SQL on a daily basis, but not even really understand
what SQL is and how it works. That's amazing. That is such fantastic progress. Which is funny because,
again, if you think about it in the sense of the term fundamentals, there would certainly be a lot
of programmers who would say, "That is negligent. "You are not a serious
developer of information systems "if you do not understand the asset test, "or any of the other elements
of relational databases. "Certainly SQL is just
the bare minimum you need "to fully grasp to be allowed
to make applications." Fuck off. Absolutely not. The more we lower the barriers to entry, the wider the pool of
people we can attract and allow to build applications,
to start on the road. How is that not a good thing? And I think that there's sort of some insecurities wrapped up into this, that if you tie your sense
of self worth as a programmer into like, "This is really hard. "What I do everyday is really hard, "and you have to be so
fucking smart to get this," and then someone who just
goes through a bootcamp of three months shows up and does sort of kind of the
same thing that you do. Then if your ego is sort
of a little fragile, maybe that looks like a threat. But it's a good threat.
It's an expanding threat. It's not like there's 10,000 applications that need to be made every year, and those are the applications
that we're all competing to be able to be allowed to work on. Absolutely not. Most of these people who
are coming into the industry are expanding the pie, like
making more new applications. The number of new applications, in fact, that I've talked to the founders of, where they basically went like, "Yeah, I didn't know what
the fuck I was doing, "but this thing totally took off "and all of a sudden we were
getting lots of customers. "And then I hired a bunch
of real professionals "who kind of knew what they were doing." There's a lot of those stories.
And those stories are good. And that is a way, I think, where we've sort of helped progress, and where compression of concepts take us by lowering these barriers, by reducing the list of things
you really ought to know such that you can get a basic proficiency in a three month bootcamp. Now, my favorite technique to attack this problem of reducing the list of
things you ought to know is leaky abstractions. So, leaky abstractions
was originally coined, I believe, as sort of a derogatory term against abstractions, and
frameworks, and libraries, that did not yet fully
encapsulate and cover all the complexity of the
thing that they were wrapping. That, for example, the first
version of Active Record still required you to write
a substantial amount of SQL. You couldn't just use Active Record and expect to get your
whole application done if you didn't know SQL. It was sort of one step
up, and one level above, but it was quite leaky. A lot of times you had to deal
with the underpinnings of it. This is how all abstractions start. This is why we need to
embrace leaky abstractions, not hold onto the fact that no, actually, for all eternity, every
programmer in the world has to know all the
intricacies of this concept because that's what
makes them professional. No. Leaky abstractions is how
we get to solid abstractions. If you look at the path of
the history of Active Record I think it's a perfect parallel for that. It started out extremely leaky, and sort of just a leg up of making some things a little easier, and it ended up in this
magical place where it is now, where people can use it and
not know what the fuck SQL is. That is a progression that's amazing, and it came through
this leaky abstraction. We need more leaky
abstractions, not fewer, because the leaky
abstractions we start today are the solid abstractions
of five years from now. So unless we start planting these seeds, we're not gonna have
the trees that we want. Leaky abstractions, even as they are in the initial implementation of them, are a form of just-in-time learning. JIT learning. That maybe as a leaky abstraction
is sort of getting rounded there will be these obvious
pitfalls that you fall into, and occasionally you will
have to learn something. But we get to push that point out further. Again, you get to start, even with the first
version of Active Record, with less that you have to learn. The list of things that you
absolutely need to learn to make this basic form
work, there's less of that. A lot of the, I find, interesting critiques
of something like Rails, which has this unending
appetite for leaky abstractions, unending appetite for
conceptual compression, is that there's too much of that, that there's too many concepts in Rails, that we've compressed too many things which means that there's too much code, and if you wanted to
understand the entire framework and you had to read it
through from start to finish, that would take a long time. Well, don't do that. Like, who the hell in here understands the entire Rails framework? I sure as fuck don't. I have not read the entire Rails framework in a very long time, and there are plenty of
concepts in the Rails framework that have been compressed so well that I don't need to
worry about them anymore and I put them completely out of mind. If you ask me any questions
about the Rails router, for example, I just go, I don't know. I know like how the API
is supposed to work. I know how I want it to work. But how it's actually implemented? Ask Aaron. That's his problem. This is that buffet of
just-in-time learning. You don't need to understand all of Rails. Not on your day one, not on year one, and not, as in my case, on year 15. You can push that out and
reserve the time for learning whatever it is that you need to learn to the point when you need to learn it. When you need to do this specific thing, or you've hit this problem that you want to do better
at, or you want to change, or you want to upgrade, or
you simply have to deal with because your application
is crashing and too slow, that's the time to learn it. It's a perfect time to learn it. If we shove all the learning up front then you have to learn all the concepts before you're even allowed to begin, that list of things you
ought to know is going to be a five year curriculum. Who has time for a five year curriculum? Why is that even a good thing? It's like memorizing all the states, or the capitals of the world. Do you know what? I don't care.
I don't need to know that. It doesn't need to be in
my brain all the time. I don't need it on speed recall. I can look that shit up. Most of technology is like that. If you just have the rough outline of a concept existing in the world, you don't actually need to
internalize all that content and keep it in your working memory on a day to day basis. Now, the second part of this is, one thing is we want to
make it easy to learn. We want to make it easy to learn so that a bootcamp of three
months can be sufficient. Not even a bootcamp. A Rails tutorial for
someone who is interested and reading on nights, or whatever, could be sufficient for someone to learn just the bare minimum so
that they can get started. Because the corollary of that is we also make it easier to launch. The fewer concepts that you need to operate and juggle to learn, is also the fewer concepts that you need to operate and juggle to launch. Now, I think a great
example of this is Twitter. Twitter was launched on Ruby on Rails by a bunch of people who, by all accounts of what happened later, had no fuckin' clue what they were doing. No clue. Not on the business side. Not on the conceptual side.
Not on the technical side. Not on the architecture side. No clue. If such a motley crew of
characters can come up with Twitter and sustain it to this day, where we can all look at an application that had its root in
Ruby on Rails and think, "This might be how it ends. "The nuclear apocalypse
might come tomorrow "because of the thing we helped create." (laughter) Now, that is a deep sense of
satisfaction in the world. A sense of real imprint on the probability of the continuation of our species. Now, not a lot of people get to take such a pride in their work. The funny thing with Twitter, of course, is that it's sort of the most iconic case of someone
starting on Ruby on Rails, then hitting some
problems, some fail whales, that they took an extraordinary
amount of time to fix, and then when they fixed it, a lot of tales were spun
of whose fault that was, because surely it was not the motley crew of people who worked on it, right? There's much easier solutions. It was the color of the
LEGO blocks. Clearly. They were just the wrong color. They didn't fit together just right for the persons who were building it. And yet Twitter, supposedly, I think moved on from Ruby on Rails like seven, eight years ago or something and moved to a wonderful,
efficient Java platform. And then in about seven or eight years, nothing fucking happened. The entire application is exactly the same as the one they arrived at
through the experimentation of the early days with Ruby on Rails. Which I think goes exactly to
that point of easy to launch. When Twitter first got started, it was this thing where
you would SMS your friends such that they knew which bar you were at. They didn't have the concept
that this was, at one point, going to be the siren
of our impending doom. They didn't architect it in such a way that you'd have the
president send tweets out to 50 million people, and
then be spread further still. They didn't know what they were doing. They needed low barriers of entry such that a few people who
barely knew what they were doing could come up with a
concept, iterate on it, and get to the point like, okay, I guess this thing is good enough now. Let's pour the concrete and change nothing for the next seven or eight years while we make it fast and performant. That's a success story.
A huge success story. Because if you were thinking, like, hey, what if they had
applied the techniques that they're currently using
to operate the site on day one? What if they used the
tools and the techniques that they're now using, the
team sizes that they now have, to build the initial version and figure out what
this thing actually was. They would never have
fucking figured that out. It would have been a concrete version of like, let me send an SMS to friends so that they know which bar I'm at. Maybe that's nice, but it's not Twitter. And I think the summary of that point is if we want to have a broader set of people be involved in technology, we need to reduce the barriers of entry for access to that technology. Because it's one thing to
be a user of technology, and we can complain, and there's plenty of users of Twitter, and they certainly use
that service to complain. It's something else to be an
actual maker of technology and have the tools of
production in your own hands, and have an actual chance of charting out new and
alternative futures. And unless we widen the pool of people who will have access to those tools and who are working on that future, we're gonna get the future of tomorrow in the past of yesterday. I think that's how the math went. Then we cannot expect different outcomes if we apply the same people
to the same problems. If we apply the same
people within the same confines and constraints
of both technical systems, and economic systems, and
all sorts of other systems... We need a broader base. Otherwise we're not gonna get
a broader set of solutions. Now, some of this feels like
I'm rehashing old battles here. And it is, because that's kind of fun. But it's also really
not the important part. The important part is not to look like, oh what did Twitter user do, or oh, people used to think ORMs couldn't do this, that, or
the other thing, ha ha ha. It's more the sense that
we should use history, we should use the past,
to inform the present, and the future. That we should look back over this arc of 20 years of conceptual compression, and the advances that we've made, and ensure that at the very least, we hold our goddamn ground. We've gotten to a great place
with information technology. We've lowered the barriers of
entry so much, it's amazing. And it really is amazing when you look over that 20 year period and you look at the kinds of people, and the resources that are required, to launch something and
make something today. Those two worlds look
quite very different. And the one we have today, in
many ways, is so much better. So that's worth protecting.
It's worth guarding. What I see happening, though,
in large extents right now is a lot of backsliding. That we have these amazing
accomplishments and achievements and we're letting them erode. We're letting them sort of fall backwards. That the industry at
large is currently focused a lot on conceptual expansion. We're introducing a
whole lot of new ideas, which is great, in some sense, but we're letting them
balloon, and bloat to the point where it's so much harder to reason about and feel confident about,
"I can build a whole thing." If I want to build a so-called
modern web application today, how much stuff do I need to know? How many concepts do I need to juggle to be sort of on par? If you look at the supposed
requirements today, 2018, versus the supposed requirements
of let's say 2005, or 2008, they're much worse. We've made the list of
things you ought to know, or supposedly ought to know, much longer. Which is part of raising those barriers. Because yes, we've still compressed-- The compressions we did are still there. But if we impart the idea that you also have to do all
of these other things, it doesn't really help that much. Which pushes you into two boundaries. Either people just give up, and say like, "All right, this has just
gotten too complex for me. "I have to know what this SPA thing is. "I have to know what this
microservices thing is. "I have to build a native app. "I have to... "That's not for me.
Technology is not for me. "This is too complicated." Or people go the other
direction, which is like, "I should just specialize. "I'll just pick one thing "and I'll become the best
goddamned React expert there is." Now I can't do anything on my own because I just know this
one part of the puzzle, but at least I can get
hired by a big company making big software. Yay. That is a form of progress. It's just not the kind of progress that I'm particularly excited about, and not the kind of
progress that I want you to be excited about. Now, you have to be careful, of course. There's a lot of nostalgia about this, and I'm certainly not immune
to the charge of thinking like, "Oh yeah, you like 2005, "because that was sort of
like when Rails came out, "and there was a lot
of energy around that. "And now it's just nostalgia,
and we're just hearkening back "and wishing that yesterday still existed, "and it just doesn't, because
the requirements changed." And there's truth to that. But it's sort of not the whole picture. The problem is when we
sort of set a new baseline. It's not that new ideas aren't good. It's that we have to be cognizant of what it is that we're doing,
how we're approaching it, such that we don't end
up with this new baseline that is so much higher in
terms of the complexity, in terms of who it is we
allow to make new applications that can have an impact on the world, that we cut that off. We had these extraordinary gains. We made all these monumental leaps of conceptual compression. And if we wash all that
away by introducing just an avalanche of new
uncompressed concepts, and don't work on
compressing those concepts, and just work on finding
more and new ones, we're gonna lose. And I think it's kind of-- It's a loss that you don't
sense until it's too late. That's what sort of this look back, this idea of letting history
inform us, can help us with, be instructive, comparative. How was it to develop things in 1995, versus 2005, versus 2015? How does the curve look? In which areas were we
most welcoming, most open, most approachable, and
can we guard those things? Because if we don't guard these things, I'm pretty sure the WS-Deathstar
is going to get rebuilt. We defeated this monstrosity
back in the early 2000s. WS-Deathstar, which was, I think, my first presentation on Rails, ranted against this notion
that was going on at the time, which was this proliferation of crazily complicated and
convoluted protocols for how web services
could talk to each other. And you had like 45 standards, and they were getting
pushed by IBM, and Sun, and whatever, this was the future. And it was an incompatible,
overly complex, complete utter mess that
bred specialization, and it bred all the ills
that I've been talking about. And it represented one possible future. That this was the way and the
direction that web services, and web sites were going to go, in this complicated, overly
specialized sort of way. Then the rebels mounted an attack. And that attack took forms in
a lot of disjointed things. It wasn't necessarily a concerted effort. It was things like rediscovering REST, the basic architectural
principles of the web. Figuring out that, you know what, XML is actually not that great
and we can just use JSON. Like, it doesn't matter,
any of these specialization, and these attributes, and whatever, you can take that entire
ball of complicated wax and just say, "You know
what? It doesn't matter." Conceptual compression for sure. We could take the whole
set of convoluted protocols and basically just replace
them with things like WebHooks, which basically just says, "Hey, you know what? I'm
just gonna send you some JSON "to this URL when you're done." You hardly even need a spec for that. Again, conceptual, not just
compression, but counterattack. And I think we are at that point with a lot of the concepts
we're currently wrestling with in the industry, that
it can go either way. We can either continue to
rebuild the Death Star, and get more complicated,
and more convoluted, and more specialized, or we can mount a counterattack, again. That's where, again, you have to be careful with
this notion of nostalgia because it's not that we want to go back and think like, "Oh, these
things didn't happen." Native didn't happen, or
mobile phones didn't happen, or any of these things didn't happen. It's that you want to take
those things and embrace them with the principles that
we applied in the past. Not the actual past, but
the lessons that we learned. Anyway, that's some of the backsliding that's currently going on. Some of these lessons that
we learned in our community are sort of evaporating. And I think that that's a damn shame. Because I think what happens when we get into these deep dives of complexity and specialization is, in some part, it contributes to this idea of being alienated from
the product of our labor. When the product of our labor
and the things that we make become less and less tangible, and your specific input on it
becomes more and more diffused because you're just working on one isolated little box of it, it becomes so much easier, sort of, to lose your connection to that, what you're actually working on, and what that impact on
the world actually is. Harry Braverman has this
quote that I've liked since I've started a very cursory
dive into Marxist literature. It's an interesting dive in itself because there's certainly
a lot of history there, and some bad outcomes. But just because you don't
like someone's prescriptions of what you should do
about certain problems doesn't mean that you can't
recognize the insights that their diagnosis brings. And I think, as of right now, the diagnosis from Marxist literature is incredibly timely for our time. Harry was writing in the '70s here. The red shirt in the back. Thank you. (laughter) "While the social division
of labor subdivides society, "the detailed division of
labor subdivides humans. "And while the subdivision
of society may enhance "the individual and the species, "the subdivision of the individual, "when carried on without regard "to human capabilities and needs "is a crime against the
person and humanity." Now, the social division
of labor refers to the notion that we don't all know how to make shoes, and be plumbers, and whatever, that there are these broad
industries that we fall into, versus the detailed division of labor is when you take something like, oh, programmer can build (mumbling) system, and relegates it to, oh, spec
specialist on the WS-Deathstar spec number 42 regarding transactions. That is a detailed division of labor that alienates us from the
product of our own work and makes it harder for us to sort of invite it and broaden the base. Now, the more alienated we get from the product of our labor, the easier it becomes to
commit software iatrogenics. Iatrogenics is this concept from medicine, doctors trying to do well
ending up harming the patient. Nassim Taleb has written
a bunch about this and how iatrogenics applies to
a bunch of other professions, including economics and so forth, where supposedly specialized, wise people end up harming their patients,
and their constituents. I think software right
now is at its low point in that regard. Software has never harmed more people than it does right now. It's also never helped more
people than it does right now. But these two things
aren't invariably linked. We can help a lot of people without also harming a lot of people. And I think the sort of lack of acceptance
of that responsibility that we as software developers have, to not harm the patient, is minuscule, and relegated to sort
of a small subset corner that doesn't seem like it applies directly to what it is that we do everyday, when it's at the absolute core of what it is that we do everyday. And I think that these things are linked. The more specialized you are, the more deep and narrow you are, the stronger are your blinders, the harder it is to
see the bigger picture, and the easier it is to defend
for yourself and for others what it is that you're doing. Now, this plays in particularly, I think, in our time right now
because we've been colonized. The new world of the Internet has been colonized by a small set of very successful conquistadors. And they're taking this
promise, this new world, and turning it into
kind of a shitty place. Now they're getting fabulously
wealthy in the process by extracting our attention, our privacy, through monopolies and other forms, and that's bringing, oh, some
progress in some regards. But I don't think we've
fully understood the trade, that the conquistadors
showed up with cheap mirrors and shitty combs, and
traded us our most valuable aspects of humanity. And I think that trade needs a counter. That it doesn't have to be this way. And again, history is an instructive guide that it
didn't used to be this way. The internet didn't used to be colonized in the way that it is now. Yes, in some forms,
actually, it was colonized through Prodigy, and AOL, and
other portals at the time. But then we had sort of a
glorious time in the middle where there were far more options, there was far more competition, and power, and wealth, in some regards, was not concentrated in the
hands of this little elite. Now, this is all
happening in our backyard. This is not some external
thing that's going on. This is us. This is our profession. This is what it's being used for. We have a responsibility
to do something about that. Just to the point, Piketty, author who put out this very long book that basically justified this equation. That the rate of return
on capital is greater than the growth of the economy. In no place is this more
true than in technology. 89% of all new advertisement spending goes to two companies:
Facebook and Google. While they're also busy gobbling up the rest of what was of
that industry before it. That's not good for anyone, other than perhaps the
people who happen to own Facebook, and Google,
and their shareholders. Like, that's a regression for the world that we're concentrating wealth
and industry in this form. And again, we have a responsibility to do something about that. And I think it simply will not do that we, as the implementers
of these visions, and these systems, just close
our eyes, close our ears, and stop talking about it. These easiest thing we can do is just to step back, dive
into our specializations, dive into our technology,
and say, "No, no. "That's it. That's just my birth. "That's where I'm at." So when I look at what my mission is, what our mission should be, the mission that I want
to inspire people to join, is the idea of liberating the best ideas. So, when Rails first got started, I had some choice words,
let's call them that, for the Java and the J2e community. Those choice words were
not based on the fact that there weren't good ideas. In fact, they were based on the fact that there were good ideas, lots of them, but they were trapped inside
these conceptual cages. And that we could open those cages, and we could take those
wonderful concepts out, and we could distribute them more widely such that more people could use these level of progress, and patterns, and ideas for how to
build information systems, but that it had to be liberated. That the ideas trapped inside these cages were only accessible to a select few. Once we've taken these best ideas out-- And I want to take those best ideas out through conceptual compression,
leaky abstractions, these techniques that I've discussed-- then we can arm the rebels. And when we arm the rebels, we get a chance, at least
a chance, to fight back. Fight back on the technical level. Fight back on the societal level. Fight back on the economic level. Fight back, and return to a
notion of things that worked, and reject the things that didn't. Because software is eating the world. There's no denying that, and
we cannot turn that clock back. It's not like that's going to stop. But who's writing that software? You are. If you're writing that software
that is eating the world, how do you not have a moral
and ethical obligation to steer that? Of course you do. And being blind to that,
it's not gonna help us. It's just gonna delay the inevitable. So, let's do this work. Let's continue to compress the concepts that are worth keeping,
reject the ones that aren't, broaden the base of people
who can actually have a chance to write this software
that's eating the world, such that the software that we end up with is software the benefits the world. Thank you very much. (applause)
