Tip:
Highlight text to annotate it
X
>>Commentator: At 14, Jeff set a Rubik's record of 24.67 seconds and then wrote a book titled
Conquer the Cube, that detailed his method. He then worked as a software engineer and
moved to Atlanta. But as a Bronx native, he was so unsatisfied with the local pizza that
he decided to fix it. This meant hosting pizza tastings at his home, publishing what's known
as the Internet's number one pizza recipe, and finally opening Varasano's Pizzeria earlier
this year.
Please welcome, Jeff Varasano.
[applause]
>>Jeff Varasano: Hey. [laughs] How you doin' guys?
Thanks for having me, first of all. I haven't given a PowerPoint presentation in a long
time, so your you're gonna have to bear with me a little bit.
Yeah, so I just wanted - when I had the opportunity when Mike called me and asked me to speak
here - I originally was gonna talk just about the food. And I'll just give you a little
bit of background on the pizzeria. But then I did want to tie it into some of the other
things that I've done and just kind of show how they all relate to one another.
When I moved - I moved down to Atlanta I guess in early '98. So about eleven years ago. And
like a lot of people that are from the Northeast, I was suffering from some serious pizza withdrawal
- just withdrawal of a lot of food in general. I think the pastries, the cannolis, the - even
the hot dogs - even the Papaya King hot dogs; the bagels.
And I just started to make these things in my home. Or at least the pizza, I started
to make at home. And I guess I carried it to a little more of an extreme than I intended
to.
I started to go to all the top New York pizzerias every time I was back in New York. I hit Patsy's
and Lombardi's and all these old school pizzerias. And I noticed that they all baked their pizzas
very, very hot. And so I started to tinker with my oven and eventually kind of jerry-rigged
it a little bit so I could run it on the cleaning cycle. The cleaning cycle, a lot of people
don't know, you oven will hit a thousand degrees. So it's - you have a cleaning cycle - you
have a, the makings of a pretty good coal-fired pizza oven right in your house, if you're
willing to void the warranty and risk burning your house down.
And, but I just started to experiment. At first, first I was just using the basic generic
recipes, and then I started to experiment with all different kinds of flour, and all
different kinds of cheeses, and all different kinds of sauces. And gradually my pizza got
better and better. And as it did, I started to notice that there were a lot of similarities
between learning how to do the pizza and the software projects that I was working on; and
even the Rubik's cube; so and really learning anything.
So that's really the topic that I'm gonna, I'm gonna talk about today.
Eventually I put up a website on how to make pizza. Really just at the request of of one
person. Somebody said: "What's your recipe?" And I just threw up this website in just one
day and it, it became a little cult website where people who were really into pizza around
the Internet knew about it. And then about a year later, it just went viral. It became
one of these things that just got passed around the Internet and slammed my servers and brought
my servers down because of the traffic on this one day. It got picked up on CNET as
a news story and eventually on [ ] .com and blingbling.net boingboing.net as one of these
little strange stories that floats around.
And then I started having people say: "You should open up a pizzeria or you should help
me open up my pizzeria." I probably had about 40 people ask me if I could help them open
their pizzeria.
One of my favorite emails of all time – I've had about 2400 people write me letters from
the website. And my favorite letter of all time is: "You come China. Make pizza for profit."
[laughs]
[laughter]
So that's when I knew that it might be a good time to open up my own pizzeria, and that's
what I did and we just opened up a few months ago, and we were just voted Best Pizzeria
in Atlanta by Jezebel Magazine, and we have a lot of people who that come and say it's
the best pizza they've ever had.
So hopefully some of you guys will get a chance to try it at some point.
Well let me get back on the topic here.
So what does learning about pizza, software and Rubik's Cube have in common?
Well, actually mastering any skill shares a lot in common. So it doesn't really matter
what you're trying to master. If you're trying to master golf; if you're trying to master
the trumpet; if you're trying to master improv comedy; the Rubik's Cube; pizza; software.
There are a lot of things that, that are in common to learning any sort of a skill.
I just threw up a gratuitous picture of pizza over here.
One thing is that it takes a long time to master anything, and it's not a simple process.
It's not something where you just get an insight one day and then you can, then you can have
some sort of mass improvement. What you see instead, is you see this sort of a jump start
cycle.
So in the first step you, you take what you already know and you begin to improve on it
a little bit. And then you hit a point of diminishing returns. I call this stress, but
one way to think about it is you hit a point of diminishing returns.
And at that point of diminishing returns, you realize you have to really maybe even
back up and challenge your own assumptions about where you are.
And at that point, if you're lucky, you'll have some sort of a breakthrough where you
see a new way of doing things. And you'll jump up, but you won't stay up there. You'll
realize that there is - that the new thing - the new trick that you learned may not be
compatible with - you may have improved one technique, but it may not be compatible with
all the other techniques.
And an example that I give is, we were all on horse and buggy for awhile and then we
realized that wasn't gonna, that wasn't gonna work. So now we discover the car. And we have
a big jump up. But now we realize we don't really have the infrastructure for that. We
don't have gasoline stations every mile; we have, we have feed stations every mile.
So there's kind of a retrenchment while the - while you reorganize either yourself personally
or the culture has to reorganize around the new way of thinking. And there's a little
bit of a retrenchment and then you begin again, until that kind of wears out. Until - you
can make more and more improvements until whatever, whatever that breakthrough is - hits
its point of diminished returns.
Almost anything that you do has some sort of a diminishing return. I used to notice
when I did software that customers would want all these different features, and a lot of
programmers would just pile on feature after feature.
I've programmed a lot of verticals: so accounting systems; inventory; that sort of stuff. And
people would just add more features. We need this report and that report and this other
tool. But what would happen is, the programs themselves would just kind of sort of die
of their own weight.
So as the features increased, for a while there would be an improvement, but then after
a while it would hit a point of diminishing returns, and no one could even find the report
they had anymore buried among all the other features. And you'd have ten reports that
were designed for one person who doesn't even work here anymore. And it just cluttered the
whole system, and people end up consolidating around a small number of things that they
actually do use, and the whole system is actually functioning at a fraction of its, of its potential.
So pretty much anything you do, is gonna, is gonna hit a point of diminishing returns
and at that point you have to reorganize yourself.
Okay.
I want to talk a little - this is the main thing that I want to talk about. I want to
talk about the stages of mastery.
So in addition to having kind of a time sequence to it – there are, there's a certain look
- there are certain stages that mastering anything goes through.
And the first stage is what I call randomly connected. So what do I mean by that? It means
you just kind of just start where you are. So let's say that I wanted to learn how to,
how to play golf. So I just - I don't really know how to play golf. So I just put the ball
down and I just kind of sort of - I just hack away at it. And however my swing is, is probably
randomly connected to something else that I learned. So maybe I learned baseball when
I was a kid, and that's kind of the random bit of learning that I take into this, take
into this process.
At this point in time, I don't necessarily even know all the different parts or aspects
of golf. I don't understand and I'm gonna learn it the next step when I begin to separate
out all the different techniques. I'm gonna learn, well there's a certain way you hold
the ball. There's a certain way you hold the club, rather. There's certain way you hold
your arms. There's a certain way that your hip swings. And you begin to learn all these
different techniques.
And the majority of your time learning a skill is spent essentially in this stage here, which
is technique building where you're separating out the tasks that you're learning into finer
and finer and finer subtasks.
The problem is at this stage if you don't get help - if you don't see the next stage
- and some people don't. I compare this to almost every area of your life you can see
this.
You can see people on the Jerry Springer show where they don't understand their finances,
for example. And their finances are - kind of sort of random - randomly connected - they're
doing their books the way their mother did their books. Which has nothing to do with
getting them the financial success. And so they feel hopeless and they're poor and –
See you can almost see it, you can almost see it in any stage. And so what you want
to do with that person, the first thing you say: "Okay. You have your credit cards. You
have checks. You have your ins. You have your income. You have your budget." You begin to
separate and divide things out and this is the first stage at which you have any sort
of power. Where - this is kind of sort of it has you. And at this stage you begin to
kind of have it.
The problem at this stage – and you spend a long time at this stage - is that it's frustrating
because what works one day - what seems to work one day - doesn't work the next.
I mean anyone who has ever played golf - it's a great example - you learn a new technique
so now you've got this new stand that the guy taught you; and so now you go out there
and hit it and you have a great day. "I got this." And then the next day you go out, and
you're terrible again.
And it's because you don't really have control over it. And so it's very, very technique-based
and nothing looks smooth and nothing is smooth.
And the next stage – things are reconnected. So you have all the different tools that you've
learned, and now you begin to, to reconnect them. So now many if you're doing improv - maybe
if you want to be a comedian - at this stage you're learning different voices; at this
stage you're learning different inflections; you're learning different accents; you're
learning timing. And at this stage, where you can, is where you can combine them all.
And it is at this stage that you see people begin to be able to improvise something.
I saw this amazing video that I highly recommend - anybody looking up - it was Robin Williams
on Inside the Actor's Studio. He did this little improv number. It's on YouTube. He
did this little improv number with a woman in the audience and she had a scarf. So he
just picked up the scarf and he did like eight routines with this scarf. He put it around
his waist and he did a Japanese accent and he was Iron Chef; he put it around his head
and was like, he was a Muslim woman; and he had the - the thing had these little fringes
- and went through it like he was the car wash. He just had all this stuff, like right
at his fingertips. Like boom, boom, boom, boom, boom. And he, he was changing his voice
tone; he was changing the accent and the characters that he was in - and it was just one thing
after another. Really an exhibition of mastery. And h He makes it look easy.
And that's what you see at this stage. Things look easy because you can pull from whatever
is coming at you. You have the ability not only to have the techniques, but to control
them and to constantly correct yourself.
So, if Tiger Woods, for example, is swingin' a golf club - if I'm swingin' a golf club
and I was taught how to bring the club down - if I make a mistake at that point, at the
beginning point in time - well it's pretty much over for me. That's it. It's gonna, it's
gonna, I'm gonna slice it.
But if, when Tiger swings he probably in his mind has just the beginning part of that,
that swing divided into ten stages in his head. And if he makes a mistake at the first
stage, he then thinks and says: "Well, I'm gonna make this change." And then he'll make
this change. And he has - he might have five opportunities to make an adjustment. And whoosh
it goes and it looks like a perfect shot.
We don't have the ability to do that. You know when you see Jordan going to the hoop,
you don't see him like counting steps or anything - everybody makes it look easy once they've
reached that stage, because they can take all these disparate parts and connect them
back together.
Does that make sense?
Okay.
So we see this all over. We see this in - I've given the examples of performance. I want
to talk a little bit - I'm gonna talk – I's gonna relate it largely to programming.
So I'm gonna give some slides in a minute where I talk about the difference between
code that's randomly connected - I used to do a lot of vertical applications - data applications
- and a lot of these were programmed in the '80's and '90's and they were trying to improve
them. And a lot of the code was just pretty random code that was just coded by lots of
different people who weren't using, necessarily using the same tools and they were tryin'
to glue all these things back together.
And I'm gonna show a diagram in a minute to talk about the Frankenstein model. And then
we evolve them into took tool kits and them then I'm gonna talk about framework.
So I'm gonna come back to that in a little bit.
And you can kind of sort of just see - and this might be a chart to kind of - I don't
want to go over the whole thing - but you can maybe look at this at a later time on
the video.
And you can just see how different things in life all fit into the same pattern. It
could be a simple thing as, I want to clean my room. So the first thing is I just divide
everything into piles. I just separate them in piles. Then I have to decide where are
they - how are they gonna connect. The stapler should sit right next to the copier. Just
organizing things has this sort of a, has this sort of characteristic.
You see the same thing - if any of you have ever read Stephen Covey's The Seven Habits
of Highly Effective People - he talks about this. He says the first stage in getting control
of your life is you start off you're dependent. You're dependent on all of your history and
the past, and all the assumptions you made as a child, and your upbringing.
So the next stage is to become independent of all of that - is to take control of your,
your mental state.
But then the next stage, I think, surprised a lot of people, because a lot of people thought
he was going to say that the last stage is, now you're totally independent, now you've
extricated yourself and you're totally in control of what you have, of who you are.
But actually he talked about becoming interdependent - was the final and seventh habit.
So you can see it's very much the same thing of what, of what I'm talking about.
Let me give a concrete example. Okay.
Actually, let me, let me go over this little chart here.
So how does knowing any of this help? How does knowing any of this help?
Well for starters you know what to expect. First of all it takes a long time to master
anything. A lot of people think: "Oh, if I just learn this one thing, then I will, I
will, I will be able to achieve something." And it's almost never like that.
Someone just wrote a book that says it takes ten thousand hours to, to get good at something.
That's funny - I found this very funny 'cause I've always saying that it takes two thousand
hours to start, and then a lifetime to, and a lifetime to really master anything that
you want to get good at.
So no matter how - it doesn't really matter what it is. If you want to shoot free throws,
stand there for two thousand hours and shoot free throws, and eventually you'll be, you'll
be as good as anyone in your high school at shooting free throws.
Now if you want to be Michael Jordan, that might be good enough to be Shaq, [laughs]
but if you want to be Michael Jordan, you might have to do ten thousand hours or more
with it.
So a lot of times this helps because sometimes you're presented with an opportunity and you
have to make a realistic assessment of whether you're gonna go for it. And I know, I make
a decision if I'm really gonna commit to it or not. So someone recently said to me: "Jeff,
I wanna teach you how to be a pilot." He was all gungho. He said: "You would make a great
pilot." And I said: "I don't know if I have two thousand hours [laughs] to devote to that
right now. So I really don't wanna start, because I know I'm not gonna finish it."
The next thing you know, is that you know there is a cycle to it. So you kind of can
see what stage you're in. You know, you can be on the lookout for a breakthrough. You
can be on the lookout for separating things into different techniques. And you can be
on – you can be looking for how to make finer and finer distinctions.
You know, I talk to, to people in the pizza business all the time and most of them, they
just have a very simple recipe. So, they - some people put oregano in their sauce. Well I've
sampled 28 oreganos in the last, in the last three months. Because I am breaking that down
to finer and finer distinctions. And, and I know to do that because of these principles.
Somebody analyzed patents. Somebody went to the Patent Office and got a thousand patents
and just kind of read through 'em all, and what he noticed was that almost all the patents
have to do with taking something and breaking it into parts.
So it could be that you have a tire and the tire has one big air hole in it. So, of course,
if it gets one, one cut in it, the whole thing collapses. But if you divide it into thousands
of air holes - if you make it into a foam, for example, on the inside - then it can withstand
a puncture.
So, so pretty much whether it's, whether it's a logical breaking things down of parts or
a physical breaking things down of parts, you see that same thing over and over again.
Most things are broken into pieces.
The next thing is it can help you because you can look for a breakthrough by examining
the stress points. So, I'll talk about this a little bit more when I talk about the software.
Okay.
You can get a glimpse of what the final stage is like and this may help you get there faster.
So I'm definitely gonna talk about this as I go through, I'll definitely talk about this
as I go through the software.
When I first started to deal with these vertical systems, there is a natural tendency to want
to break the things into parts, and you would find that there were all these different tool
kits that help you do a task. But very early on I realized that unless those are all recombined
- so that separation is not the end, it's really the middle stage – and unless there's
a way to recombine those into something more powerful, into some sort of a framework, that
that can't possibly be the answer. That can't possibly be the final stage.
And we're definitively definitely gonna talk about this.
The other thing that's interesting is - and let me just go back a second here.
[pause]
And I didn't really, I didn't really talk about this - I didn't get this on a bullet
point here. I forgot, but –
Naturals. In any skill there are people who are just born naturals. For whatever reason
- and I don't really have a theory as to why that's so, but - people just have certain
natural gifts. And the difference between a natural and someone who is taking on a skill
for which they're not a natural, is that naturals do this task backwards.
So a natural starts off with the connections and then learns the techniques. So someone
like a Robin Williams probably was born a natural. He probably started at a very, very,
almost, almost as a kid noticing the connection between one thing and another. He may not
have had the ability to deal with a German voice and a Japanese voice, and a South African
voice, or anything that he might need. He might have learned those later, but I'm pretty
sure that he got that, he got the timing and how things connect probably from the very,
very, very beginning.
And what's interesting about that, is that even though we're, we may not be a natural
at something that we want to master, we can, we can take a cue from that and we can take
a peek at the end. We can take a peek at the end and say: "Okay. What are the naturals
doing that's different than what I'm doing? At least I have a vision for what it's supposed
look like."
And when, when I was doing software, I started looking at frameworks and even, even, even
as I was looking here, and even as I started here, I was, I was looking there. I was starting
really in a way from there.
And I'm gonna make that obvious in a second. So let's jump forward.
Okay.
Alright, let's give an example, here.
So as he mentioned, I held the world record for the Rubik's cube back in, back in the
day as they say, 1981 when it was, when it was the hot puzzle.
The problem with the Rubik's cube - and the reason that people are so perplexed by it
- is because the parts are so dependent on one another.
So if you look at the different stages of mastery and you talk about how things are
randomly connected - nothing is more randomly connected than a scrambled Rubik's cube.
So I don't know if this is gonna fly on the camera here. Is that the camera right there?
So I'm gonna try and do this so people can see.
I'm gonna show you just one move on the Rubik's cube, okay? Just so you can get a sense of
what I'm talking about.
So the problem with the puzzle - so let's take an example - let's say I have this red
piece right here, okay? So if I take this red piece out, so this red piece is sitting
over here. If I want to take this red piece and I want to complete this side, so I want
to move this piece over here. Obviously, I can turn the piece here and then move it up.
That would be the shortest path to getting it up here. The problem is, is that by moving
this piece up I've scrambled - I've moved these pieces out of the way. So turning just
one - there's eight corners on the cube - turning just one side turns half of all of the corners
on the cube. And obviously turning one side is kind of trivial - it's not going to get
me anywhere to do - pretty much, much of anything. I have to turn at least one side and at least
one other. So I'm moving six of the eight corners before I can do anything useful.
So pretty much everything is in motion all the time and that's why people struggle with
it.
So let me give you an example of how we can separate the pieces out, so that instead of
being totally dependent on one another we can perform some limited actions where the
pieces act completely independently.
So if you think about it, the Rubik's cube - most people like to think in terms of sides,
but that's actually a mistake - it's better to think in terms of the pieces. So there's
corner pieces and there's edge pieces. The center pieces never move. A lot of people
don't realize that, but the center pieces really never move. But I won't get into that,
I won't get into explain - that's just too - let's just assume that. Okay?
And really if I had just these four moves, where I have the x's, I could solve the whole
puzzle. If I could move any corner wherever I wanted it to be; if I could move any edge
wherever I wanted it to be; and then once they're in places I might need to rotate them;
I need to orient them or flip them around. If I can flip any corner or flip any edge,
then boom I could solve the whole puzzle. The problem is it's very difficult to do any
of these moves without pretty much scrambling all the pieces on the cube.
So let me give you an example of a move, okay? Let's look at this state a second. Okay. In
this state everything from here down is totally solved. Okay. We're gonna work on this one,
just 'cause it's the easiest one to do. Okay. It's the easiest one to visualize. Okay, we're
gonna work on flipping an edge.
So everything from here down is perfectly solved. And I have to flip this piece around
- this piece is in the right position - it's the red and white edge - I just have to take
it out and turn it around. Okay. Same with this yellow one - I have to be able to take
this one out and turn it around. Now how can I do that without scrambling? If I could perform
these moves in independently - if I could, for example, just switch two corners – or
just flip some edges - then I could move the pieces into position kind of one at a time.
Does that make sense? I wouldn't have - just trying to remove the dependence on it.
So watch just a second, okay? Just follow this red piece. First thing I'm gonna do is
I'm just gonna take this - I'm gonna separate this red from - the red edge from the red
corners by moving it out here, okay. Then I'm gonna take these red and move them around
to the back. And then this red can slide from front to back. So that's the way I'm gonna
reconnect these pieces. Okay? Not a very long move - you don't necessarily have to get the
move - but just understand that I've just done a very short, simple move to just take
this piece out and reconnect it.
The problem is, that in doing so I've pretty much scrambled the entire puzzle. And that's
where people get stuck.
So in an attempt to do what I'm talking about here which is to make the pieces independent
of one another, we have to be able to overcome that. So how can I then solve - how can I
restore the bottom of the cube? Does anybody want to take a guess at it?
[pause]
I'll give you a clue. I was just there a second ago. This was just - the bottom of the puzzle
was just perfect just a second ago.
[pause]
No. Okay. [laughs] Good.
Well, if I reverse every single thing I just did, then the bottom would be restored. Now
on the surface that seems trivial because, of course, then that would end up unflipping
this piece that we just did all this work to flip. But, the move I just performed had
no effect on the top side other than on this one piece.
Therefore, if I would were to turn this piece into this position - and there's no collateral
damage over here - I just switched which piece is gonna get the unflipped part. And now I
reverse all the moves I just did. So I move this to the back and I move the piece out
to the front. All this is, is the reverse of the move I just did. Then boom, the bottom
is restored and then the top is solved. I just move this piece back. So boom, I've just
done this one piece.
Instead of really - instead of having the pieces be dependent on one another - I've
essentially created a way to do just a very small action without a lot of collateral damage.
Does that make sense?
And I could just easily walk through all four of these moves. The corner is essentially
the exact - flipping the corner is exactly the same except one goes clockwise and the
other counter-clockwise, which makes total sense. And believe it or not, moving the pieces
is even a shorter move. But it's actually just part of the move we just saw. So it's
even shorter. But I won't walk through 'e,, because I don't think it makes good TV here.
But you get the point.
If you could do these four things - if you could separate your, your , your overall randomness
into just - into just these four components, all of which by the way based on that same
principle - which is I'm doing something forward and I'm doing something reversed. Essentially
one single concept; one single move really, can solve the whole puzzle.
So how does this help me in the pizza business? How does all this separation help me in the
pizza business?
Well, I'll just give one little simple example.
When I moved from my home kitchen into the commercial kitchen, I changed the way that
I store my dough. So most people if you go into a pizzerias they'll have these trays
- they'll have a tray - and in the tray there will be a spot for six or eight different
dough balls. And the trays will stack up and they'll have a couple of hundred dough balls
in there. And then as they're making pizza, they just take a tray out and they scoop up
one dough ball and that's the one they're making.
The problem is, is that if I take the lid off of - take a lid off of a tray to pull
out dough ball number one, and then I don't have to make another pizza for another five
or ten minutes, well then dough balls two through six are drying out. So that there
- one pizza becomes dependent on the next.
So, I made the decision very early on to put all the dough balls into separate containers
just so that they would have their own individual life cycle.
And as soon as I - as soon as I thought of that - it immediately, it immediately just
fits into this. You know what I'm saying, mentally for me I was sure - I was like: "Oh,
is this gonna be the right move for me?" Because it seemed like a lot of extra work; and it
is a little bit of extra work.
But of course, I knew it was the right thing because anything like that is I know - anything
type of a separation is an advance over - I mean how random is it? We talk about things
being randomly connected. Pizza one is not randomly connected to pizza six, which could
come at any time - depends on when some random person comes through door. You can see how
these things collide with one another, and by separating things out, I make - I go a
long way to preventing that.
Similarly, we have one big pizza oven right now. And with one big pizza oven, every pie
you put in affects the pie right next to it. So if I put in a pizza pie on one, one slot
then the next pie that goes in right after that - the stone that it is sitting on is
cooler, because the pie, pie number one took all the heat off of that stone. So again,
similar sort of a situation.
Okay.
Alright let me talk now - now I'm gonna go into the software aspect of this. And I'm
gonna try and relate all of this.
[pause]
Like I said, I started doing - I started dealing with databases - a lot of different vertical
applications. And I immediately noticed that a lot of these, these legacy systems that
I came upon, and even systems that were being developed new, were being programmed in a
semi-random way, to be honest with you.
So just - I'll give an example here. So let's say that I have a sales screen. So I've got
a little water processing screen where someone can - I've got a warehouse full of stuff and
I've got a person on the phone taking calls from customers, and they get a call and they're
gonna punch in an order for product x and it's gonna come out of the warehouse and it's
gonna go, it's gonna go to my customer.
And so let's say behind this screen there are ten pages of code to do all the management
behind this screen. Well, very quickly we realize, well we don't just have that one
task - we're not just selling things - we also are doing repairs. So repairs are a little
different. We're pulling items back from customers and they're going into a different location.
They're still part of our inventory. You can't let things get stolen. We still gotta know
where they are, but they're going to a different sort of pot, blah, blah, blah, blah, blah.
So some things are the same; some things are different.
So for example, sales might have sales tax, whereas, repairs don't have sales tax. Both
have a shipping address. So some of the things are similar, and some things are not so similar.
So we see that there is variations on that theme. And in addition to repairs, I might
do service orders which don't have physical goods, but may be judged by the hour. I'm
doing contract work, which are fixed prices. Whatever.
So I have a variety of different tasks and I immediately noticed that a lot of the way
these things were programmed in the real world where people would take the ten pages of code
and found it difficult to figure out how to get all of those to coexist without these
big branching case statements.
So instead they would really just separate the screens and end up a sales screen, and
a separate screen for repairs and a separate for service and contract.
Next up I noticed that there were different audiences looking - looking at that order.
So the customer service rep was looking at the order; then the salesman may want to go
online and look at the order; the guy in the factory may be looking at inventory aspects
of the this, that order; and then the customer them self themselves was is gonna get some,
is gonna get a copy of the order, either in an email or a printout or something.
But each of these might be seeing something slightly different. For example, the customer
service rep on his screen, he might see a credit score come up for that customer, or
credit limit or something like that.
Well, the salesman might see that, but the guy in the factory probably shouldn't see
that. And the guy in the factory might see inventory and information that you don't necessarily
want your sales guys to be privy to.
So, so each person is looking at a slight variation on this - on this order and they're
doing it not just for the sale, but for all of these.
And then in addition to that, we have different outputs. So some people are sending things
to the screen; others to the printer; the guys in accounting want everything downloadable
to Excel; you might have an HTML version.
So you end up with a lot of versions and in the real world what I saw was code exploded.
I've seen companies that had pretty - like a simple company I saw that had a, had a - they
sold like packaging, like the plastic that you can't cut off [laughs] when you buy a
tool; they sell that sort of packaging and they had 135,000 pages of code. Eight million
lines of code running their order processing and inventory systems. And this is why, okay?
And so of course that's just the sales module, then you have all these other modules. You
have distribution receiving; and you have finance; and you have customer themselves;
and HR; and then factory and purchasing and inventory.
You have all these different modules, many of which often times are coded by separate
people. What'll happen is you'll get a, you'll get a one of these big firms - an accounting
firm - I don't want to name any names, but [laughs] but you all know who you are - who
will come to you and they'll say: "Oh, you want inventory? We have inventory." And they'll
show you an inventory module that was coded by somebody who doesn't work there anymore.
And, "You want purchasing? We do, we have a purchasing module." And they show you this
other module; they don't mention the fact that they're coded totally separately. And,
"Oh, we have everything you need, all we have to do is reconnect it."
And of course it's in the reconnecting of them, that you end up with this, with this
mess that I call the Frankenstein model, which is really my example in this, in this presentation
of things that are really, truly, randomly connected. Okay?
[pause]
So what was the solution to this? So what was, what solutions were proposed? Well, I
saw a lot of people gravitating toward these tool kits.
So - a tool kit like something like a power builder. This is early on. Let's take something
like a power builder. So a power builder - if you just were to use a rough tool, like just
C++ or something like that, then you really would have - you'd have no tools available
– so you would be just doing everything from scratch.
So people coded these tool kits something like a power builder where they took all these
data management tools and tried to encapsulate them into, into different little tool boxes
that you could use.
So for example, there would be SQO SQL query tools. There would be a tool for drawing tables.
There would be reporting tools. But they didn't get it all, and so what ended up happening
was that as, as these things were coded - as individual modules were coded - there was
a lot that wasn't, wasn't up here and so you'd end up seeing a lot code down here.
So for example, if you're - if you're typing in the name of a customer you could have to
look up that customer to make sure - you might just decide - you're typing in Google and
you might type "goo" and you hope that it's gonna find Google. So you have to do a lookup.
So is that done on your individual screen? Well, a lot of times it was. And then the
guy in inventory might need to do the same thing for a product. And the guy over here
might have to do the same thing for something else.
So you would see that there's a lot of duplication of effort down here.
But then over time, people would take the best of these - would be put them into a separate
little tool kit that'd be sold as a separate product, and then eventually a lot of these
end up getting rolled into the product itself.
But what you still have at this point in time, is a bunch of separate tools that do not interconnect
in a powerful way. Okay?
So I, I knew instinctively at this point - observing this over and over and over again in multi-million
dollar projects, that there were just - that this wasn't the answer. That there was another
level or another phase of this. Okay?
Let's look at this screen for a second. I'm gonna begin to break it down.
So this is a very, very typical data view screen. So this is a screen of order items,
alright. So we got a whole bunch of people who order a bunch of stuff and so here I have
order number one and here I have order number two, and order number three, and these are
the individual line items within that.
So we see the name of the customer, the order item, the product codes, product description
and size and prices. You see all these different things. Okay?
And this would be coded, back in the old days - this would be coded one off by a developer.
So if you wanted the screen to look like this, you had to have a developer that would actually
code something like this.
So he would get a search tool, so built into these tool kits, you'd see a search tool.
So at least he's not connecting - creating his own connections to the database, he's
got a tool to do that. But he's got to write a lot of code.
So he calls his search tool and he puts in his query; and then he initiates some sort
of a grid tool; and then goes through all the data, all the different rows and takes
individual pieces of data out of his query, and pushes them into the grid; and at the
end he goes column by column and he specifies what formatting.
So for example, the currency's gonna be formatted – and he gives, he gives the formatting
that he wants to see displayed for the currency.
And so this is what you would see, kind of at this, at this middle level of how data
would be, would be displayed. Okay?
But I knew when I was looking at this situation that this left a lot of room to be desired,
because once the data was pushed into this table, there wasn't a whole lot you could
do with it other than manipulate the data that was actually here.
So for example, let's say that I have a - a product code over here. Well my actual join
to this product table is not through a code or through the description, but it's through
some sort of a secret hidden key number.
Well that's not - wasn't put on this screen because it wasn't part of the display. So
essentially you couldn't do a join from here. It There was no interface, for example, for
a user to do a join from this point in time.
You'd even have problems at this point doing - well,
[pause]
Okay.
So anyway, I noticed that there were, that were a - even though this has a certain degree
of complexity - I noticed that there was a lot more complexity and a lot of things in
computers that were being handled a lot better.
So if computers really are all about handling variations, if you think about it. So I have
different image formats: JPEG's, PIF's GIF's, PNG's. I have different video formats. I have
different types of data: foreign keys, money, dates, images, barcodes. I have different
GUY GUI controls. I have check boxes and radio buttons and sliders and scroll boxes and combo
boxes, menus, pull downs and pop-ups.
I have all these different - so if computers - one way to think about computers, it's just
taking vast amounts of variations and getting them all to work together.
Well there's a formula for making these things work together that really is what makes them
into plug and play. So plug and play itself has a formula. And what you see is that these
end up getting - these variations end up getting bundled together and being dealt with via
the construction of frameworks, and that frameworks have very, very specific - a very, very specific
architecture - and that's what I'm gonna talk about.
I'm gonna talk about a very specific architecture that I call a mature framework. A lot of times
what you'll see is a mature framework will start off as an immature framework. So that
power builder, like what I was talkin' about where you , you would start with a tool, you
would start with a tool down at the leaves and then they would work their way up to the
core eventually. That's really the beginnings of a framework, but it's really not a mature
framework.
By the time you get into handling this the way the operating system does, it ends up
having a very, very specific structure.
And so what I wanted to do, is I wanted to take the elements of data: the different outputs
methods; those different tasks; the different audiences. These were the three I saw in the
Rubik's cube; and, and then many others. And I wanted to roll them into a framework and
I knew that the framework - if it was properly structured - would reconnect these and that
that reconnection is what creates that level of mastery. It's creating these so that they
powerfully interconnect.
So let's talk about this for a second.
Move backwards a way.
Okay, so what is the difference between the - doing things in a framework versus doing
things with tools? So let's take for example, the operating system. Something for which
we probably all are most familiar.
So the operating system deals with a lot of different things, but I think that the two
primary - it could be argued that the two primary things it deals with are: threads
and windows. So it has a lot of other things like fonts and all different kinds of hardware
stuff, but the primary thing - you could make a case - is it deals with HWDNs hWnds, it
deals with windows and it deals with threads.
And I want to talk, for example, about windows as a good example.
So you don't own your own windows. All the windows are just data that is registered with
the operating system. So you might have a wrapper - if you're coding in C++ you might
have a CWnd or something - you might have a wrapper around your agent. But basically
all that is, is a pointer or a handle to the operating systems version of your hWnd.
So, the benefit of that is that nothing happens to that hWnd outside of - that the operating
system doesn't know about. You don't have access to the hWnd to change a variable that
might be contained in the HWND structure. You can't move it to a new position.
There's an API call that somebody else wrote – that, that the same person that's responsible
for the operating system wrote - and they will move it for you. So you can, you can
make a request to move it but, - and then they will change their own data and then do
all the housekeeping associated with that, and that's how things happened.
And that's why you can, for example, log on to a machine and change your themes. Even
though you have like ten programs running, you can change the theme of the bars on the
windows because the operating system really owns all the windows, no matter what programs
you're is running. Okay?
So what you end up with then, is an API - you end up with the operating system holding these
tables of registered objects, and you end up with a bunch of API's that you can call
that will, will modify these. And then if you're operating at this level, what you get
instead of holding your data, is you get events pumped down to you. So the events are pumped
down to you. If you want to respond to an event you have to make an API call which then
affects the data, and then AIP the API call does whatever cleanup is necessary to run
at this stage. Okay?
Let me blow this out in a, in a different way. Actually let me do this slide. Okay.
So here's, here's a kind of a blow out of one of those layers. Okay?
Okay.
So this is a - if this is a, this is a framework layer. So this is my layer and I now own all
the data. So instead of, for example, creating a tool for you to search on data, and then
another tool for you to display your data, like we were doing in that, in that list of
order items.
Instead I'm gonna create a framework where the framework is gonna own all the data. So
you can make a request to create a data - a list container, for example - a table container.
And then you can pass a query or select clause to that container, and then you can make changes
to the container by, by having an API call that would, that would make a change to the
size or the number of rows or anything in that container.
But basically, the level above you really owns the container. The framework owns the
container and everything you do is really at its permission. Okay?
So over here you have an API managed list of data. So this could be hWnds if you're
an operating system; it could be database tables; it could be point us to records on
the database, if we're at the level that I was talking about.
Then over here, we have all the tool kits that you can call to change the data that's
being held by the container. And we can modify these in some ways - several ways.
So here, for example, we have a, we have suite number – we have suite A - and what I can
do is I can (I'm just gonna dance a little bit) I can, I can make an addendum on to that.
So maybe, it may be that, maybe when a message comes down here and ninety-nine percent of
the time I let the default handler handle it, and the default handler calls back this
suite. Well maybe I want to make one little addition to it so I can change this layer
and I could either do it down here - I can make my codes change down here directly - or
possibly I can go over here and change the handler and make an addendum to the tool itself,
so it that it can handle it for all the layers that get created down here.
So for example, if I'm wanted to do lookups a certain way that was maybe a slight modification
on the way that the framework did a lookup, I could go over here and create a generic
lookup manager that would apply to all of the screens that I've created. And that that
would get its - that would get its call as the default handler and then would pass the
bulk of the work down to the handler below it.
Or I could completely substitute a tool if I wanted to. We see this in the operating
systems. This is what startup things are all about. You have all these different, different
- if you think of these as different components of the operating system when you start up,
you add on to certain components; you change or swap out certain components.
Let's see.
Go back a layer here a second.
Okay.
Okay.
So in addition to having the operating system or having your framework layer handle the
data, it also handles lists of functions. Is there a white board in here or - I guess
I noticed a long time ago that a lot of people wanna code things in hierarchies. And hierarchies,
where essentially you have hierarchies of - if you look at an object orient - an object,
you have data and function, if that's the essence of each object. Because you have a
bundle of data and then you have the functions that go with it.
The problem is, is a lot of times you really want multi - some sort of multiple inheritance.
Where I might have a data object here, and then I might have two children, and then I
wanna have a data object here that pulls both from this and from this. Especially a lot
of times the functionality.
So what ends up happening is you end of taking that functionality off, and you end up putting
it on lists. And that's really what this is. This is [inaudible] is a financial function.
I'm gonna, let me give you an example. Let's say that I right mouse click on a file on
my desktop. Well, a menu pops up where I can do - I can - if it's a folder I can search
on it. But maybe I've added functions that didn't exist in the operating system. So maybe
I have a backup function. I'm using Carbonite or something, so I can set the Carbonite settings.
Or I'm using SVN Tortoise or one of these, or one of these sorts of things that, that
will sync my files with something else.
Where does that code - where is, where is that code? When I right mouse click, how does
it know that Carbonite can affect that file? Well, essentially the operating system has
lists of functions that can apply when you right mouse click on something. And you can
add your list - it might start off, start you off with a list - and then you can add
your own items to the list. And you don't just provide the code; oftentimes there's
a whole table of parameters that goes with that - that's telling the operating system
when and where that code can be used. So that a lot of it gets managed without having the
– any, any interaction with the code itself.
Let's see.
Let me go back a slide.
[pause]
I'm locked in this – I'm locked in this little thing here.
[pause]
It must be one of these. [laughs]
Alright.
So let's see what that would look like for our screen. Okay. So let's see what that looks
like for the screen.
So before the screen there was a whole bunch of code. Okay? And that code was - it was
semi-random in the sense that the guy who wrote that code might not even be here anymore,
as I said - as I, as I keep giving that as an example.
And in order to modify that code, we'd have to actually go into the code; crack the code;
read the code; compile the code; etcetera.
Here's another way of constructing the screen really without a whole lot of code. Instead,
the screen is going to be created by the framework which interconnects all the parts. So over
here, for example, we have a column registry. So here, for example, we have an order item
SKU.ID. So that's the name, that's the name of a column. And we can see that that's a
foreign key. That that points to the SKU to our product. And this is the specific column.
This is the name of the column. This is order item. That's SKU ID and this is the column
it points to which is SKU.ID, okay?
Then over here we have another order - we have an order item that has the a unit price
and that unit price is gonna be handled by a code - by an object called currency.
And then I have an order item called total price and this is also managed by currency,
but unlike unit price this one is summable. So if I had a list of unit prices I wouldn't
want to see them summed, but here on the list of total prices, I might.
So basically the framework sets out what it's willing to handle and what it's willing, and
what it's not willing to handle. So it creates a standard by which all the people that come
next - all the users of the framework know what information is needed.
Then over here I have a table registry. So here I've defined my product; my SKU and I've
said that the its ID column is ID. The code handlers the default one for handling tables.
And then over here just to give an example of a column that I might have on this table,
is that I'm saying that the default join - anytime someone joins over to this column, table they
probably really wanna see not just the, not just, not just the ID, but they probably want
to see the style code, the style name and the size.
So if you see over here - and it's color-coded but you probably can't see in the screen - that
these three columns: the produce product code, the style name, and the size all, all exist
here. And they're all kind of sort of colored together and you probably can't see that but
Then over here I have a registry for the view. So that's what actually creates this. So I've
registered this view - the table is the order item - it's given a name; it's given a default
handler; and then I have a select clause. But within the select clause, woops-a-daisy.
[pause]
Not what I wanted. Okay.
Alright.
So anyway - so the currency obviously is gonna to be applied to the unit price and in the
select clause and then this default join is gonna be applied over here. So that all I'm
saying is I want the default and then it will build this - it will build and construct this
view for me.
So there's no coding involved. Everything is handled in an interconnected way through
a series of framework code which can loop through these lists of information.
If you compare this, for example, to the code that had to be written before to create the
exact same screen - which is here somewhere - you can see this was an awful lot of uneditable
code, whereas, the other thing was - whereas with the framework everything is totally generic.
And yet you have the same functionality.
But now you can go beyond this functionality. Let me give you an example of where you're
gonna go beyond the functionality.
So I always talk about how in the, in the last stage of mastery where things are powerfully
connected, you have the ability to improvise.
So I talked about Robin Williams improvising or Tiger Woods improvising.
Let's look at how this can - can help you improvise.
So, let's see what do I have? Is this the screen I want? Okay.
So because this screen, now, this is the same screen - because this screen is not owned
by the person that programmed it, but rather is simply something that's is registered with
a framework, the framework can now manipulate it in a, in a powerful way. In fact, I could
write - I could have written this whole function that I'm about to do, after the guy that wrote
the screen doesn't even work here anymore. I can add functionality to a thousand back
- I can make it backwards compatible with a thousand old screens because I haven't - I'm
not really asking for much new information. I'm certainly not asking for any new code
to be written.
So as part of this little demo thing, what I did was I created a new table called the
Reward Program. So we've got our customers and we want to divide them into gold, gold,
platinum or silver rewards, or something like that.
So just prior to this screen running, this table was created. So it didn't even exist.
The table - the rewards table - didn't exist 10 minutes before this demo, and nor did the
field called Company.Rewards Program. There so So there's another - this is the table,
the table that we're looking at here is the company table and then the reward program
is a point - the reward program idea ID is a pointer on to yet another table. So essentially
we're, we're starting on the order item table we're two joins away from seeing the word
gold or platinum. Make sense?
Okay.
But what I've done here is now I've provided a completely generic interface to bring up
a table like this that will let me drill in to, to these things that have a relation - to
these columns that have a relation.
And now we're gonna select the Reward Program. In fact, we've selected two columns: we've
selected the Reward Program and we've selected - that we also want to compare the Reward
Program versus the type of the, of the product.
So we originally had the product code, style and name, but we really weren't seeing the
type of the product - whether it's an earring or whether it's a necklace or anything like
that.
So I specified that I want to see both the Reward Program and the type. And then I hit
this little button over here called the ten append columns and I can go back through this
data table that it owns - it's owned by the framework - and it can go back, find all the
hidden data that's behind here that it managed, because it's the one that does the queries
in the first place, so you always make sure that the data it needs is available and stored,
and then it goes back and pulls up those additional columns that didn't exist a minute ago.
Now we can actually run yet another function on this – which is we can actually run a
summary. So there were hundreds of rows, there were 207 rows behind me, so nine of those
were silver pins. And then a sub - then you have a sub-totals of all the different items
that - all the different columns that specify themselves as having the summable characteristics.
Does that make sense? And then you can continue on to hit a button called show detail where
you can then actually highlight the columns that you're interested in and then it would,
it would then pull the detail up from the summary.
So to actually have coded this on an individual screen which was being done before when you
had a tool kit, was basically impossible. No one was gonna code all this functionality
into, into it using raw tool box tools. But as a framework where things are managed at
a higher level, that's what – that, that this is the kind of sort of thing that becomes
possible. That does make - is this making sense?
So the interesting thing about this though - from what I'm tryin' to project - is that
when I was dealing with the individual tools to construct things like this, I was very
cognizant because of the mastery principles that - I had an idea of what it would look
like before - and I could compare it - I could, I could find, I could find things that I have
done, or things that I was proposing, and then compare them and say: "Is this gonna
create a way for people to generically edit this at the end? Have we handled all the exceptions
that we need to handle? Have we handled all the rules that we need to handle? Is the,
are the boundaries or the layers between the way things connect properly structured?"
And If you can answer yes to those, then you're goin' in the right direction. If you can't,
and you're still kind of building tools - you just know you're not at the right stage, and
you don't want to code yourself into a corner, which I've seen a lot of times happen. Does
that make sense?
So anyway, so that's the point. That's basically what I wanted to talk about today. Just to
give a little flavor and now we end with a picture of pizza. And that's it. [laughs]
So that's it. Any questions?
[pause]
More than you thought you were getting out of pizza? [laughs]
>>Voice in audience: [inaudible] >>Jeff Verasano: Yeah. I'll give an example.
So, when you are - when you're doing something that's not - when you're at the early stages
and you make a mistake early, you can't self correct. There's really - you don't have the
tools or skills to do that.
And my pizza's really good when I make it myself at home in a very controlled situation.
Opening a the restaurant is a whole another level. It's a whole 'nother ball of wax. We've
got a lot of people touching the dough; the dough goes through a two-day cycle; and there's
a lot of - no one works two days straight - so there's different people workin' on every
little aspect of this.
And so while we, while we try to get things right the first time, of course, there is
that understanding that, that that's not real – that’s not really possible at the stage
that we're at right now. And it may never be possible.
So we have to be - we have to be more flexible so that we can correct situations later. A
lot of pizzerias, they don't really care – they, they fix this problem - because they don't
really care what their dough tastes like so they just - they make the dough and then two
hours later they can use the dough. We age the dough for a long period of time which
creates all these different potential problems. So, so we've had a variety of breakdowns and
sometimes what I've done is I've simulated breakdowns so that people can learn how to
recover from certain situations.
So we had a situation, for example, where the dough was over-proofed and it was just
warmed too long and was kept in a warm - so the air conditioning didn't work properly
- it was kept in a warm spot or whatever, and so now we needed to learn how to stretch
dough that wasn't, that wasn't ideal. And -
[pause]
That could be a train wreck. [laughs] You have customers coming - if you have customers
coming in the door.
So some of the things that we've done, is we've actually simulated that in advance,
so that we could look for processes at every stage of the game. Saying: "Okay, how could
we correct horrible dough? Is there something we can do to horrible dough?" And it turns
out that if you - if becomes very hard to stretch and it gets holes in it, but if you
warm the dough - if you microwave every single dough, for example - then it becomes a lot
easier to stretch. If you pre-examine - if you take the dough and kind of triage the
dough and look underneath it, you can see the beginnings of holes forming and you can
get rid of those early in the day before customers start arriving en masse.
So there is a variety of just kind of sort of pushing yourself - pushing yourself to
the next level of things because you know that you're gonna experience this.
And then, and then some days, honestly, it - it's not helpful, but it's just comforting
to know that, that this is part of the process. That part of the process is, it works one
day and it doesn't work the next. And it doesn't matter whether it's software; it doesn't matter
whether it's golf; it doesn't matter whether, whether it's pizza. It's just that's the process
that you're going through and that there's a lot of time involved.
I mean another thing that it helps with really, is, is just going deeper I think than most
people will - into the ingredients – is the example I gave. We're just continually
testing. Because a lot of people they get a, they get a, they get a tomato from a supplier
and then that's it. We know that every batch that comes in might be a little different.
That every season of tomatoes is a little different than the season before. That we
have to, that we have to look at the batch codes and notice these, these sorts of things
- breaking things into finer and finer distinctions.
>>Female voice: [inaudible]
>>Jeff Varasano: [laughs]
[laughter]
>>Female voice: [inaudible]
>>Jeff Varasano: Right.
>>Female voice: [inaudible]
>>Jeff Varasano: Yes.
>>Male voice: [inaudible]
>>Jeff Varasano: No. No definitely not. No, no absolutely not. I mean I've only been at
it for a few months. And, and mastery, mastery is a process though.
So, so let me talk a little about this just for a second because a lot of people say:
"Oh you know, Jeff, you're a perfectionist." But it's actually - perfectionism and mastery
are almost opposite, if you think about it.
Perfectionists - both look the same because they might be trying to get to a specific
point. But a perfectionist is really someone who's kind of emotionally attached to things
being one way. A perfectionist never looks like he's in control. He's always stressed
out because things are not the way they're supposed to be.
It's almost the opposite of a master who looks cool and collected even when things are changing
around him. Does that make sense? So like the example I always give is a, a - James
Bond - he's - we were fascinated by looking at masters because it's - the more you - because
they can do anything and because the more - even in odd situations - and the more you
look at it, the more depth you see in it.
So James Bond - there's an alligator coming at him; he looks around; he can kill it with
a bobby pin and a razor. [laughs] Somehow he can like figure out to make that, how to
make that, make it work. He's not tryin' to pre-plan everything. He's just walking through
the situation and taking what comes.
You see this with Louis Armstrong. If you listen to Louis Armstrong play the trumpet,
which I highly recommend. A true master of the 20th century. And you listen to it - you
can listen to it a hundred times - it's like – how, how did he do that exactly? Right?
How did he know that that exact timing? You know when Frank Sinatra waits a little extra
second to sing that note and he's off timing, it sounds perfect. When you and I do it, it
just sounds like, like crap.
So [laughs], so, so how does that, how does that, how does that happen? They're not trying
to sit there and make it work one particular way. Instead they have this power to, to,
to, to improvise based on how everything is happening. Louis Armstrong used to just let
guys in the band just rif and then he would just rif off of that.
Just like Robin Williams does with the audience. And in a way, that's the whole point really
of, of this exercise. Is that this summary, this sort of summary data, is an improvised
thing.
And, which isn't possible at, at - trying to get everything just right. This is why
in a way - one of the things I had on the little - the little chart - was I talked about
the, the very first chart where I talked about the different stages – is, is that I had
the economy. A planned economy is perfectionism. It's utopianism. It's trying to get everything
just right. You can't get everything just right.
Whereas, whereas a free market is, is self-correcting and because there's thousands of people looking
at individual prices all the time. The price becomes the, the interconnecting part that
connects all the different aspects of the economy.
Almost any time, therefore, you engage in price fixing to distort prices in some way,
which is what you do in a planned economy - it's just a series of one type of price
fix after another. Things never really work out. And even if something looks it's a cap
- it's a free market cap if it's heavily regulated or heavily, heavily price fixed, then, then
it won't be flexible.
[pause]
>>Voice in audience: [inaudible]
>>Jeff Varasano: Sure.
>>Voice in audience: [inaudible]
>>Jeff Varasano: Yeah.
>>Voice in audience: [inaudible]
>>Jeff Varasano: Yeah.
>>Voice in audience: [inaudible]
>>Jeff Varasano: Yes.
>>Male voice in audience: [inaudible]
>>Jeff Varasano: Yes.
>>Male voice in audience: [inaudible]
>>Jeff Varasano: Well, we're learning. [laughs] That's all I can say. What's that?
>>Voice in audience: [inaudible]
>>Jeff Varasano: Well, no we have - we have our processes like any business does. When
I make - decide I'm gonna make a change - I write it down. I have a, I have lists of all
the employees that I have to - if I decide that this is - that the specification on a
weight of cheese is going from 130 grams to 150, then I, I literally have every person
in the kitchen have to sign off on that.
So that - because we did have problems early on where people were like: "Well, I didn't
- you told this person, but not this person."
So we do these - we do simple things. Not everyone works every shift, so it's hard to
communicate. So we just do written, written sort of processes. But I would be lying if
I said that we are at stage three. We are, we are not at stage three. We absolutely,
positively at stage two.
And even when you're at stage three, you're continue - stage two never really ends doesn't
ever really end, but, but, but there is some sort of a shift at some point, where you can
see that you've hit stage three.
This sort of programming is clearly at a different level than just building, then just building
a screen one day would be and just hoping.
I mean I look at this all the time. I was on - I'm on my bank screen all the time. I
reconcile my bank book every day. And -
[pause]
And, all my check registers on the bank is all in HTML. You can't even copy it into a
spreadsheet without the tabs goin' on [laughs] - without the things wrapping and all this
other, all this stuff. So, clearly, there is a, there is a dearth of thinking about
how that can be usable in an improv situation - in multiple situations.
There's,the tools haven't been constructed or haven't been utilized properly to, to allow
for that. And we're a long way from being able to highlight three checks and comparing
them to the - to checks to the same vendors at a time.
Like that would be a feature that I would love. Click a check and then it would know
everybody else that I sent that check to; subtotaled; maybe not just even one, but maybe
multiple checks. I could see things in a group. If I highlight about how all my cheese vendors
that I pay through the computer - that actually are paid on the, my bank's website. I could
highlight three checks and say: "I want to see all the checks that match the vendor on
this check."
They don't have that. They're not, this - with this, that's easy. That's easy - it's easy
to say, for example, that I want to highlight this necklace and then I want to right mouse
click and have it highlight all the other necklaces.
That, that's a function that could be built generically, but it can't be built generically
if, if what you've displayed doesn't contain all the information. All your information
has been put into a display and there's nothing behind it, in some sort of a framework. That
make sense?
>>Male voice: Yeah.
[pause]
>>Jeff Varasano: Anybody else?
[pause]
Well you guys gotta come and taste the pizza. That's the bottom line. So [laughs]
What's that?
>>Male voice in audience: [inaudible]
>>Jeff Varasano: Yeah. I think, I think Mike was talkin' about that. So, that would, that
would be great.
We're gonna do a little pizza and beer thing – I've been to done a lot of these tastings
and - and that's an interesting thing too, because we did tastings, for example, with
a beer vendor. And they had like 40 people come and they have had six beers and had us
compare the beers. And they said it was like the best one they'd ever done. Like we've
just opened. We shouldn't be the best one they've done in years, as well as other restaurants.
But, one thing that we have that a lot of other guys don't have, is we just taste everything,
so it just, it sensitizes our palate. So like just the fact that we've tasted 28 oreganos
and over 50 tomatoes, and, and over 50 kinds of cheese, and almost a 100 types of olive
oil, gives us a little bit of a different palate, and we have an ability to mix and
match things in a way and even to create - we actually created a couple pizzas that didn't,
that the beers didn't match any of the things we had in the menu.
We were able to create and mix and match certain things, between Heather and I, because we
have, have built up those techniques and have that, that more defined of a palate.
And definition is all about separation.
What's that?
>>Voice in audience: [inaudible]
>>Jeff Varasano: She's got a good beer palate.
>>Female voice in audience: [inaudible]
>>Jeff Varasano: Your belly, maybe.
>>Voice in audience: [inaudible]
>>Jeff Varasano: [laughs] Anything else, guys?
[pause]
Sure, absolutely. [laughs]
[applause]
[techno music]