The following content is
provided under a Creative
Commons license.
Your support will help
MIT OpenCourseWare
continue to offer high quality
educational resources for free.
To make a donation or
view additional materials
from hundreds of MIT courses,
visit MIT OpenCourseWare
at ocw.mit.edu.
PROFESSOR: Just very
quick-- very quick
what we're doing today and what
we're doing next on Wednesday.
Phil's going to start with
an estimation lecture.
We're going to follow that
up with a lecture from me
on Sprint Backlogs
and Task Lists.
And then we're probably
going to take a break.
You'll come back and you'll have
essentially a Sprint planning
meeting here in class where you
will create a Sprint backlog
and a task list,
hopefully with estimations
down to how many hours you
think all those tasks are
going to take you.
Then we'll ask you
to come up and give
a very brief two minute
presentation on hey,
how did the process work,
and what was it like?
How did it work for your team?
We're not actually interested
in hearing about your game
or what the top task
you have to do is.
We trust that you have
a good game in progress
and that you've got a
reasonable set of tasks.
But we actually want to hear
about how that meaning worked.
So we'll also give
you about 10 minutes
to have a little sort
of post-mort review
to talk about the process, after
you've made your task lists.
Andrew will then come in.
He'll be leading a discussion,
sort of a review discussion
on good software to see
what you've been doing
and see if you've remembered
anything he said from earlier.
And you should have turned
in your product backlogs.
And you should have code
running on your machines.
We're not going to walk around
and inspect all your laptops
to find out if you
have running code.
But to be on target, you really
should have something running,
and if not playable,
at least pokable.
For Wednesday, we'll be
talking about testing.
And you'll be running
a focus test in house.
And Genevieve Conley,
yes, from Riot
will be also giving a guest
lecture after the focus test.
And I believe she'll be here
to wander around and help out
in the focus test a little bit.
So I think that's everything.
Now!
Those were my two slides.
Now you can have the controls.
PROFESSOR: Do try to come
in on time for class.
If you are unsure about whether
you can get your game set up
in time, come in early.
And make sure that
your game is ready.
When we have guests
coming to our class,
we really will
prefer that people
don't walk in terribly late.
It's just kind of embarrassing.
All right.
So over the weekend,
I found myself
in an unenviable
position of having
to teach-- prepare for
a video game class,
and not having a
working computer.
So I had to prepare
for the possibility
that I wouldn't have a
computer as of today,
and redo my entire
presentation in analog format.
But it turns out that IS&T
actually does miracles
and got my computer back
and working on Monday.
If you happen to
be working at IS&T,
give yourself pat on the back.
You are doing God's work.
But I'm going to try to
do the analog thing anyway
because might is worth a shot.
I'm going to do
to be very clear,
this is the first time
that I'm doing this.
I'm going to need three
volunteers to come down.
Come on down.
Come on.
Come down.
All right.
OK.
So on Wednesday, we asked you
to split things up into small,
medium, and large
features, right?
Small, medium, large.
And I'm going to give you
an idea of what your product
backlog currently looks like.
Your product backlog currently
looks like a bunch of features.
All right.
Now I'm going to assume that
all of you have sort of already
assigned small, medium, large
things to your features.
Sort of small, medium, large
categories to your features.
But I want to try doing
it slightly differently.
I'm going to give each
of you three cards.
These are the large currents.
Medium.
Can people see this from
the back, by the way?
The letters on the card?
Small.
So this is what's
going to happen.
I'm going to pull
something out from here,
and you all are going
to all look at it.
And you are going to
figure out whether that
is going to be small, medium,
large without actually
discussing anything.
All right.
So you keep the cards hidden,
and only you can see it.
And then when I ask you to
reveal it, show it all at once.
Show me what you've picked.
All right.
I'm not going to tell you
what's small, what's medium,
or what's large.
I want you to tell me what's
small, medium, and large.
All right.
So everyone clear
on how this works?
OK.
Don't show it to anyone yet.
Make sure everyone's picked.
Yes?
AUDIENCE: [INAUDIBLE].
PROFESSOR: Good question.
Hang on to that.
Is this a small,
medium, or large feature
with no frame of reference?
So everyone's got one?
Show it to me.
Medium, medium, medium.
All right.
I'm going to put this here.
Next one.
Can everyone see this?
All right.
Everyone's picked one?
Show it.
Medium, small, small.
OK.
Why is this a medium?
AUDIENCE: Looks similar.
PROFESSOR: It looks similar.
All right.
AUDIENCE: [INAUDIBLE].
PROFESSOR: OK.
The other one does
have a hole in it.
If you haven't seen it.
OK.
I'm going to put this
one aside for now.
This one.
It is red.
All right.
Still being picked.
Small, small, small.
OK.
So this is unequivocally small.
And this piece.
This one also has a color in it.
All right.
Show it to me.
Large.
OK.
Going back to this
one, what do you think?
Everyone show me
what you're thinking.
Everyone thinks
that now is small.
OK.
All right.
So, don't go back yet.
But I want to say thank you very
much to all of our volunteers.
Why did I just make you
all go through all of that?
That seems like a very,
very inefficient way
of sorting out features.
Like if I just gave
you this entire box,
this is what I
want you to do now.
Sort this whole box into
small, medium, large.
All three of you together.
You don't need the cards.
Go for it.
AUDIENCE: [INAUDIBLE].
PROFESSOR: OK.
Thank you very much.
If you can just hang out here,
just a little bit longer,
that will be great.
Now that is probably a fairly
good analog of how most of you
figured out small, medium,
and large on Wednesday.
Which was you just compared
features next to each other.
Figured out which one's
seen on the larger end.
Which ones was on the small end.
And just kind of
put things in place.
But there was some
discussion going on.
Is this small?
Is this large?
It's just like do
two of these put
together make one
medium, for instance?
Now think about the first
method of first choosing
whether this was small,
medium, large and revealing
it, was that I forced you
to actually voice out why
you thought that was different.
I believe you picked a medium.
And the others picked a small.
For a lot of these other pieces,
you didn't voice anything out.
And one of the reasons why
we can do this so quickly,
is because human
beings are actually
pretty good at reasoning
about spatial volume.
You're pretty good
at-- and being at MIT,
you also understand geometry,
3D geometry, in a sense
pretty well.
So you can make these spatial
reasonings pretty well.
But when it comes to things
like time and complexity,
human beings tend to
have a tougher problem.
So I'm going to say,
for instance, I'm
going to give you three blocks.
This represents for you,
seven hours of work.
OK?
This represents for
you, six hours of work.
This represents eight
hours of work for you.
All right?
So you know you've got
16 hours of work to do.
Pick out features that
you're going to implement
in your next print.
AUDIENCE: So this is how
much time I have in my life.
PROFESSOR: That is
how much time that you
spent on the last feature.
If all three of you worked
on identical features--
AUDIENCE: OK, so
this is already done.
This is already done.
PROFESSOR: Yeah.
This is done.
This is a known value.
You spent seven hours on that.
You have 16 hours.
AUDIENCE: So I spent
seven hours on this.
And then there are the
two small triangles.
AUDIENCE: [INAUDIBLE], right?
PROFESSOR: The first
one is just a reference.
And the little feature.
OK.
All right.
All right.
What did the cube
represent to you again?
Seven hours of work.
And you picked?
And you think that that's
a reasonable amount of work
to get done in 16 hours?
Not including that one.
So this is about 16 hours of--
assuming volume equals time.
Sorry, volume equals
effort, actually.
All right.
And over here?
AUDIENCE: How long did it
take me to do the other block?
AUDIENCE: Six hours.
AUDIENCE: Oh.
I guess I could have
done a little bit more.
Well, that's fine.
I'll just do
[INAUDIBLE] like them.
And then if I have leftover
time, I'll do more.
PROFESSOR: If you went for more,
what would you try to pick on?
AUDIENCE: I guess
maybe this one.
It's a little bit
more than perhaps I
could do in exactly 16, but
it wouldn't hurt to touch it.
PROFESSOR: It's the smallest
thing that you can find.
OK.
All right.
And for you?
AUDIENCE: This exactly
fills my estimate.
But realistically, I'd
probably go with this.
PROFESSOR: So you're using
kind of programmer patterning.
You got a question?
AUDIENCE: Sometimes you do not
[INAUDIBLE] the small things,
for example, adding balls
to your game set is small.
But bringing out
the framework itself
is a large test
that must be done
before you have the choice
of choosing smaller tasks.
PROFESSOR: That's true.
That's true.
I am not indicating
priority in here.
I'm assuming that you're
picking up high priority tasks.
The next thing that
needs to be done.
Thank you very much.
And you may have a seat.
Big hand to our volunteers.
[APPLAUSE]
I'll be going back to
this example shortly,
as soon as I get my
presentation going on.
I want you to hang
onto these examples
because I'm going to come
back to them during the talk.
On Wednesday-- and what I first
asked our volunteers down here
to do was to do a small, medium,
large, extra large feature
sizing, basically.
The reason why we use
these broad categories
is because actually
it can be pretty fast.
And on Wednesday a lot of
you did it pretty quickly.
However, what I
noticed on Wednesday
was a lot of people weren't
actually discussing how big
or how small these
features were.
Like you all using your
own little metrics.
So that was a good question.
Small, medium, or large to
what frame of reference?
And everybody had their
own frames of reference.
When I forced people
to make the assessment
and then declare it in
front of the entire team,
and then discuss if they
disagreed with the entire team,
then assumptions
started coming out.
You had to vocalize why you
thought a certain feature was
a bigger or smaller.
You could adjust your
assessment after the discussion.
But it very, very important
to get that discussion out
to everybody.
So as long as you're discussing
with your entire team,
I don't really care what method
you use to split things up
into small, medium, and large.
But you need to be
discussing as an entire team.
In fact, every single
member of the team
should be in on the
discussion, because somebody
in charge of sound design,
or somebody in charge of art,
or in charge of art of
the code architecture
would have very different
perspective on any given future
from other people on the team.
And you want all of those
perspectives in the same time.
There's oh!
Playing a sound effect.
That's going to take no time
at all, because we already
have sound effects
in our game, and we
know how that code works.
That's what a programmer thinks.
The sound designer
says wait a minute.
I need to create
that sound effect.
I don't even know what this
is going to sound like yet.
I have no idea.
And that's going to be larger
feature from my point of view.
And you want that
discussion to come out.
So each row should try
to lend its perspective.
And is very important to listen.
The reason why I forced everyone
to do this-- the volunteers
to do this-- right
at the beginning
was because it was a
very turn-based method
of getting that discussion out.
I had to force everybody
to listen to everybody.
And something that I didn't
ask our volunteers to do
was to offer
alternate solutions.
However, they kind of did that
automatically by themselves.
When I just left them
to their own devices,
I said, sort these
out into features.
They started
discussing well, this
is how I look at a problem, this
is how you look at a problem.
And they quickly came to
some sort of consensus.
Of course, something I
mentioned on Wednesday
was if you've got a really,
really huge feature that's
kind of hard to figure out.
It doesn't really fit neatly
into any of these boxes.
Break it up into
smaller features.
You want to converge.
You want to converge
down in to a consensus.
But there are right ways
and there are wrong ways
to go about that.
Every time you have
that discussion,
you're getting new information
into the team about how
complex a certain problem is.
Maybe sometimes
through a discussion,
you discover a certain
problem is easier--
a certain feature is easier
to implement than you
had originally expected.
And then you redraw a C.
Other people's estimates is
actually new information.
And that's actually
what happened here.
There was small, small medium,
and the people on the volunteer
team figured out how other
people were seeing the problem.
Here's something
that's very important.
Don't negotiate.
Don't say I think it's
small, you think it's small,
most of the team
thinks it's small,
somebody thinks it's medium.
Just change your
estimate down to a small.
I suppose it's kind of adamant.
No, I think this is a bigger
problem than you think it is.
Don't try to negotiate
with that person
because that person has
a valid point of view,
and this starts to
focus a discussion
on changing the person's mind,
not focusing on the feature.
You actually want
to figure out how
complex a certain feature is.
For the same reason,
don't take an average.
Someone thinks it's
a small feature,
someone think that's
a large feature.
That doesn't make
it a medium feature.
That means that your team has
no idea what this feature is
because you aren't in agreement
with how complex something is.
So what I did--
does anyone remember
what I did when-- let me see.
Which feature was the
weird one that people
were kind of hung up on?
I think it was this one.
When we got to this one, and
there was some disagreement,
can anyone remember what I did?
Yeah.
I just put it aside, right?
I actually gave it away.
It is a very, very easy to
get into a long drawn out
discussion about how large
or how small a feature is.
It's usually much more
clearer if you sort of
tackle the easy ones first,
and then come back to the ones
that you disagreed on.
But you remember
that you disagreed,
and you got new information in
the process of talking it out.
So that's a role for
the Scrum Master.
The Scrum Master says we don't
want this feature estimation
process to take too
long, so we're just
going to put that
feature aside first, look
at the other features, do
the estimation on that,
and then review it later.
But a Scrum Master
does not decide
what size that feature is.
The whole team has to
come to a consensus.
You want to converge
on a single estimate.
So if you put together
your product backlog,
and you never really discussed
with the rest of your team
what those size estimates
were, then that's
something that you're
going to do later today.
Before the end of
today I want you
to have a discussion about
whether these things are
actually small,
medium, or large.
And the reason is
because estimation--
it is not just a process of
just putting down numbers
or letters on a spreadsheet.
There is a goal for the
process of estimation.
And it's this.
It's to get a clear enough view
of the reality of your project
so that you can make
informed decisions to control
your project in order
to hit the targets.
Now what's a target?
A target is a goal that
you wish would happen.
It's your fondest desires
is to get this project done.
Entire product backlog of
all features into your game
before the deadline.
That's a target, right?
Maybe your target's a
little bit closer term.
What can you get
done by this week?
What can you get
done by this spread?
It's still a target, and
something that you want to hit.
But you can't base
all of your decisions
on your fondest desires.
You have to base it on
what your team's actually
capable of doing.
An estimation is a
process of actually trying
to understand what your
team is capable of doing.
Not whether what you want to
happen, but what can happen.
So what are you estimating?
This is where you
are at right now.
You have a product
backlog, and you have size.
You have feature size that
is going to get broken down
into a bunch of tasks.
Each feature is going
to be broken down
into individual things that
individual people can do.
Maybe a certain
feature like jump
involves art, involves
code, involves sound,
involves debugging,
involves integration.
All of these are
individual tasks
that might be carried
out by different people.
So what you're really
doing in the second step
is to figure out how much time
something's going to take.
Remember what Drew said on
the very first day of class.
It's not so much how
hard something is,
how hard a feature is, but
how long it's going to take.
And what you want
to do is figure out
how long it's going to take.
Now that's a process of arriving
at a number of how many hours
this is really going
to take, and is it
going to fit within
the amount of time
that we've actually
given the team?
And you need to translate
it first from size
into effort, which is like,
total amount of effort that's
going to be used to
tackle the problem.
Split it up among the
people who are actually
going to work on it,
and then each person
has an individual
amount of efficiency.
So for instance, I gave
exactly the same cube
to all three volunteers.
But I told them this
meant different things
to each one of you.
And when they picked off
tasks off the product backlog,
they picked it based on
their own personal metric.
That's what you've
got to do too.
When you decide that you're
going to take on a task,
you have to assess it
based on your own ability
to actually execute on a task.
Say it's an AI
problem, and you're not
very well versed in AI.
It's going to take you longer
than somebody that has done
artificial intelligence before.
But that's OK because
maybe the person who's
doing artificial
intelligence is busy
trying to solve or harrier
problem establishing the base
framework of code.
And that needs to be done first.
And that needs to
be done sooner.
So that person is busy.
You can start working
on certain features,
even though you may not be
the best person to do it.
That's fine as long as I
make an honest assessment
of how long it's going
to take you to do it.
Size estimates are pretty easy.
You're just sorting
things into buckets.
Very large buckets.
Time estimates are very much
like hitting a moving target.
As you start to
make estimates, you
are going to discover
that many of those
estimates just flat out wrong.
You're going to say
oh, that's going
to take me four hours to do.
And it takes you
four days to do.
And you're going to have to
communicate that to your team.
Giving an estimate is not the
same thing as making a plan.
It is part of the
same process, but I
want to be very
clear about what's
the difference between
estimation and planning.
Say somebody on your team
asks you for an estimate.
[INAUDIBLE] alarm
bells going off
when he says, how long is
this going to take you to do?
Everyone starts to get worried
because you're not quite sure
whether they're actually trying
to ask you for how difficult is
something, and how
much time do you think
it's really going to take.
Or are they asking you, can
you get it done by Monday?
That's kind of like
the hidden question
that they're not asking, but
they think that they're asking.
So you need to be very
clear when you respond,
whether you're giving
an estimate or a plan.
You plan to reach your targets.
Obviously, none of
you-- I hope none of you
are planning to not
hit your targets.
I plan to get this done one
week after the deadline.
(WHISPERS) No.
But once you've made your
plan-- here's our entire product
backlog, and we think
it looks reasonable,
and we think that
it can actually
be done by the
deadline-- you need
to start making estimates to see
whether that plan is realistic.
You can say, yeah, I think
that's a reasonable estimate
when you think that
assessment is accurate.
I've done something
similar before,
so I figured that
this is something
that we can get done
before the end of the week.
You can commit to that estimate.
But you haven't
committed to the plan.
You haven't said, I'm going
to take responsibility
for getting it done by
the end of the week.
That's a very different thing.
When you accept
the task and say,
all right, put my name
on that spreadsheet,
and I have decided
that I think I'm
going to be able to get
this done in four hours,
so I'm now committing
to this plan.
Of course then everything goes
wrong, and you re-estimate.
You're allowed to
make re-estimations
while you work on tasks.
You have to because no
plan survives first contact
with actual development.
So here's a quick quiz.
Here are four
statements that you
might hear in the middle
of a team meeting.
OK.
I want you to tell me what
each one of these things are.
I've already used
the words describing
each one of these things
in my talk so far.
It has to be done in two days.
What is that?
It's a deadline.
I used another word
to describe that.
It is a deadline.
Is it a plan?
It's a target.
Someone.
All right.
So the next one.
It'll take about
two days to do it.
You're talking in
a team, you say,
this feature looks like it'll
take about two days to do it.
That's an estimate.
That's right.
I'll need two days to do it.
That is a plan.
That is a plan that you're
committing to, more accurately.
It's like, I will take
two days to do it.
You might take
three days to do it.
You might be able to do it
faster than [INAUDIBLE].
But I'll need two days to do it.
And of course the last
one is, actual reality.
It actually took
two days to do it.
I mean, in reality it'd be like,
it took four days to do it.
So I want you to
be very, very clear
that when you're
communicating with your team,
what you are trying to say.
Are you giving estimations?
Given all the information
that you know,
this is how tough
something is going to take.
And this is how long
it is going to take
to get this feature working.
Or are you making a
personal commitment,
saying this is my
responsibility now?
I'm going to get it
to you by Monday.
Just a quick side
note, you've probably
seen these two words come up in
numerous engineering classes.
The difference between
accuracy and precision.
Which one is more accurate?
Raise your hand in the
direction that you think
is more accurate.
OK.
That's actually-- OK.
I think that's a
majority on this side.
Which means that that
one is more precise.
OK?
So that's right.
This is more accurate.
It's closer to the target
that you're trying to hit.
Even though it's kind of
like broadly spaced out.
None of them actually
hit the target,
but if you took
the average of all,
then you get pretty
close to the center.
That one's a really
nice tight grouping.
Anyone here do pistol,
or archery, or rifle?
So we always talk about
how tight the grouping
is when you're shooting.
That's very precise.
That can be corrected by say,
fixing the sites on a pistol,
or on a rifle.
But for time estimates, this
is consistent underestimating.
Right?
It's like, yeah, it's going
to take me two days to do it.
I'll get it done in two hours.
Really, it took four
days and four hours.
And you're always doing this.
When it comes to estimation,
accuracy is more important then
precision because you're going
to work on multiple tasks.
And if your estimates are a
little bit off all the time,
but sometimes you're
under, sometimes
you're over, that
kind of averages out.
Which means that you can still
make some effective plans.
But if you are consistently
underestimating or consistently
overestimating, you need
to figure that out quickly.
You need to learn that about
yourself during this class
so that you can start
to correct that.
And if you can't figure
it out, hopefully
somebody else on your team can
realize that your estimates are
always off in a
certain direction
and then adjust the
plan accordingly.
It's also important to
know what the uncertainty
of your estimates are.
It's very valuable to know
how imprecise an estimate is.
It's like, this could
be done in a week
if I find someone else who's
implemented a feature just
like the one that we want.
If not, I'm going to have to
implement it from scratch,
and it's going to take
four weeks to implement.
I mean, that's a
fairly common scenario.
So it's very valuable to know
how imprecise an estimate is.
But while I welcome that
kind of discussion in a team,
don't just give a range.
Don't just say,
well that's going
to take anywhere between
one week and four weeks.
That's too wide a range.
You can't establish
a plan on that.
How many of you have
been in this situation?
Two minutes remaining.
And it just kind of sits there.
And it's really
four minutes later,
and it's just what
the heck's going on?
It would be much better
if you had actually,
that progress bar.
And that progress bar
is actually giving you
a single point estimate.
This progress bar is
kind of telling you
this job is about 15% complete.
And it's telling me there's
two minutes remaining.
And that bar still has
a long way to fill up.
So you realize this
estimate may not
be terribly accurate,
because it not working
on a lot of information.
It may be a
pessimistic estimate.
But you still need to commit
to a single point estimate,
if you want to make
a plan around it.
Don't just use the
average of a range.
The difference between
a one week estimate
and a four week estimate
for the same feature,
is not somewhere in between.
It's not like it's going to
take two and a half weeks.
With the one week estimate
and a four week estimate,
are two very different
circumstances.
One week, if you found
somebody else's code
that basically does
the same thing.
Four weeks if you had to
write it from scratch.
One week in, you know exactly
what situation you're in.
Either the code is done,
or the code is not done,
and you know it's going
to take four weeks.
Your estimate is not like,
two and a half weeks.
You're not halfway in between.
The good news is that
the time estimates are
entirely internal to your team.
No one outside your
team needs to know this.
I don't need to know this,
Sarah doesn't need to know this.
None of the graders need to know
what your time estimates were.
We're not holding you to-- your
grade is not dependent on this.
This means that you can revise
your estimates over time.
And I'm going to
encourage you to do that.
You are not Neo.
You aren't going
to be faster, just
because you want to be faster.
So it's important to
actually understand what's
your actual pace of work.
Now this is something
that I'm going
to recommend that everybody
do starting from today.
And that's to track
your own estimates.
This is one way
that you can do it.
It's not the only way,
but it's good enough.
Where you write down the
feature that you're working on.
Say it's the jump feature.
And you have the task
that you took on.
I'm a coder, so I'm
going to say I'm
going to put some upward
velocity when the player hits
the space bar.
I'm also going to
write some code
to play a sound effect
when that happens.
These are two separate tasks.
And with the
original estimations,
that was going to
take eight hours.
It's going to take five hours.
And then you actually
write down how many hours
you spent on this task so far.
For the first task, it was done.
It took me 10 hours to do.
Or longer than I expected.
So my eventual estimate
was 10 because I actually
knew it took ten hours to do.
If I ever have to do
that same feature again,
let's say a feature
of the same size,
again, a task of the same size.
Again to be accurate,
then I'm going
to estimate, next
time if I think
it's going to be eight, I'm
going to write down 10 instead,
because that's what previous
history has taught me.
Let's say I'm in the middle
of writing my jump sound code.
I thought it will
take five hours.
I've spent two hours on it.
And I look at it, and
I think actually this
is a little easier than I
thought it was going to be.
So I'm going to say probably
only another two more
hours of work on this.
And my current
estimate is actually
being revised downwards.
So this is going to get faster.
And if I put this in a public
location, where my Scrum
Master to read this,
it can actually
see my progress on my work.
You might be able to also do
this on certain task tracking
tools.
Don't estimate in
ideal work hours.
Don't say, if I had
four uninterrupted hours
to just work on
this game, I'm going
to get this jump thing working.
How many of you ever have
four uninterrupted hours?
Really?
Is this like between
midnight and 4 AM?
OK.
OK.
Uninterrupted?
You're not like, checking
Facebook, or having
to get a snack in between?
No?
Really?
If there are distractions,
if there are team meetings,
if there are other problems
that [INAUDIBLE] that you
expect to have to do,
you should count it.
You should count it
in your task time.
You should be able
to account for this.
Because say so you've
blocked off 12 hours of-- No.
Let's say six hours.
You are going to spend six hours
on this project over the week.
And you know you've got
that, because you're
going to have to spend
the rest of your time
going to other classes,
and doing other work.
And you know that
you've got a one hour
meeting somewhere in there.
Part of your task is actually
going to that meeting,
and figuring out how a
certain feature should
be implemented,
before you actually
start writing the code.
Or actually start
doing the art for it.
You want to factor that
into your task estimation.
You don't want to say
that's a separate thing.
At least if you do count
it as a separate thing,
make sure that
you've actually got
that as a separate task with
an actual time estimate on it.
Count all of your distractions.
Do try to schedule and time
box all of your meetings,
because it makes
estimation easier.
If you know that a meeting's
time boxed to one hour,
you can't spend more than
one hour in a meeting.
And you can actually account
for that in your estimations.
Don't just always have ad
hoc meetings, for instance,
like on Skype.
Because then you're
just stealing
a couple of minutes from
everybody's schedule
all the time without any one
being able to plan for it.
So you've got
something like this,
where you're tracking
all of your progress,
then you just add up all
of your time estimates
when a feature is done.
And then you can go
back to your original
small, medium, and large
and say this thing took me
seven hours to complete.
And if I get another feature
that looks like these two
features, for
instance, and say it's
about two half features
compared to that seven hours.
I said, OK, three and a
half, three in a half.
And you can use that.
It's not going to be perfect.
It's not going to be accurate.
But you're basing it on real
evidence of how fast you
personally work.
So all of this information helps
you become a better estimator
of your own performance.
And in the future, you
can use those numbers
for future sprint planning.
So when you finish one
sprint-- say it's project 4,
and you've got multiple sprints.
You finish one sprint, and
you know that this takes you
eight hours to complete.
So the next time you get
this size feature, well
it took me eight
hours last time.
So I'm going to say that that
feature looks like a eight hour
task.
You should
re-estimate every day.
So you animate your jump and
say that's too big of a feature,
so I'm going to split into
two tasks, the animate,
the jump take off, and the
animate, the jump landing.
Since they are two
very similar tasks,
I'm going to put the same
time estimate on both of them.
And then I'm going to start
working on jump take off
since you have to go in the
air before you can come down.
And I'm going to
start working on this.
The task is a little bit
harder than I expected,
so actually it was a
five hour estimate.
So I'm going to increase it
up to a six hour estimate.
And then eventually,
I got it done.
Down to zero.
I have no more hours
on this feature.
It works.
It's tested.
It's integrated.
Everything's fine.
Now I have to do
the second feature.
Animate the jump landing.
What should I write
down for that?
Let's say by the time I
actually came to the situation
where I wrote down I
had six hours remaining,
I had already spent eight
hours working on the feature.
I spent eight hours
working on jump take off,
and it wasn't done.
Then I wrote down I
had six hours left.
So what's my new
feature estimate?
14.
A lot bigger.
Because that's real evidence.
It may be that during the
process of doing this earlier
feature, you've learned
certain techniques that's going
to speed up your next thing.
However, that's
wishful thinking.
That's hope.
That's what you desire
will happen in reality.
The actual information
that you have
is that actually if you add up
all the hours I actually spend
on this, it took me 14 hours.
So I'm going to revise
the next feature
and let the rest of
my team know that I
think this next feature
is going to 14 hours.
Divide and conquer.
If you've got a very big
feature and very, very big task,
break into little bits,
and do your estimations.
Don't forget to
account for debugging.
This is one of the very
first actual bugs found
by Admiral Grace
Hopper, stuck in a vial
somewhere in a computer in 1940,
that actually caused a program
to fail.
That's one theory of where
the term debugging came from.
Don't forget integration time.
Taking your code and your
assets and your writing
and your dialogue
and sound effects,
and making them work
with other people's code
and contributions.
Don't forget that
some of you are
going to get very exhausted
and overloaded while you're
working on this project.
And don't forget to take breaks,
and to account for those breaks
in your time estimation.
If you know that you
don't tend to work well
on a four-hour
stretch, and you tend
to work much better
with one hours,
with a five minute or 10 minute
break, and then another hour,
then use that in
your time estimates.
Try to estimate so that
you can work efficiently.
Not just how you wish
you could be working.
Any questions?
I thought that was
kind of fire hosey.
We'll probably get
back to this-- actually
we will actually have
you practice this
later on in class.
Five minute break?
All right, so right now we'll
do a five minute break while we
switch our computers around.
Be back here by 1:53.
OK.
We are back on.
So we're back on.
Hopefully this will actually
not be terribly long,
because at least some of
the stuff I'm talking about,
Philip has already
really touched on,
and discussed in more
detail than I need to hit.
Since he just talked about it.
I'm just taking a
lot of the terms
he has introduced and
explained and talked
about all the estimations
and tasks and so forth,
and stuffing them back
into our Scrum framework.
So you can think about-- given
that data, about estimating,
what do you do with it?
How do you show it?
How do you share with it?
How do you record it?
But first, let's have
a really quick review.
Remember I said there
would be a quiz later?
Here's our quiz.
I want to see how many of
you actually still remember
we talked about on men day.
So can I get some volunteers
to give you some definitions
up here?
One per customer.
AUDIENCE: All right.
[INAUDIBLE]
In charge of the vision of the
products, and also in charge
of maintaining the backlogs
of the team's [INAUDIBLE].
PROFESSOR: Yep.
Specifically prioritizing
the backlog, but yeah.
OK.
Someone else?
This is going to be a
really long lecture.
AUDIENCE: [INAUDIBLE].
PROFESSOR: Great.
Next?
Grab them while they're easy.
AUDIENCE: The product
backlog is a list
of features to be implemented
to have the whole product done.
PROFESSOR: OK.
And I saw someone.
AUDIENCE: [INAUDIBLE].
PROFESSOR: OK.
You're already a
repeat customer.
AUDIENCE: The
sprint is the period
of working on one
installation of the product.
It should be kept short,
so we can [INAUDIBLE].
And each sprint should
have [INAUDIBLE]
that can be published,
or that's running,
so that you can only
do incremental work.
PROFESSOR: OK.
Somebody else.
Somebody else.
We got two meanings left.
Grab the meetings.
Team members?
Don't make me do the
whole lecture over again,
because I don't want
to give it, and I don't
think you want to hear it.
AUDIENCE: The retrospective is
the meeting at the end where
you review your processes.
AUDIENCE: Team member
is really easy.
PROFESSOR: Nobody's
grabbed that.
AUDIENCE: Team
member is everyone
on that's on your team.
PROFESSOR: Well done!
Do I have anyone that
will take Scrum Master?
You've already answered twice.
Thank you for noble
participation.
AUDIENCE: A Scrum
Master is in charge
of just making sure
the Scrums go quickly,
and everyone knows
what they need to do,
but he doesn't actually
have to do anything.
He's not actually in charge
of planning anything.
He's just in charge of making
sure everything goes smoothly
during [INAUDIBLE].
PROFESSOR: Yep.
Yep.
Coach is a great
description for that.
OK.
Now I think we have not hit
the sprint review meeting,
but other than that, I
think were pretty good.
So the sprint review
meeting is the meeting
that you're going to get
to do in class today.
No it's not.
Sprint planning meeting.
Ah!
Sprint planning
meeting is the one
you're going to get
to do in class today,
where you go ahead, look
at your product backlog,
decide what you can get done,
and make a sprint backlog.
And then break that down
into sprint task list.
And don't think anybody
gave sprint review.
OK.
And sprint review is just
at the end of your sprint,
when you were
evaluating your project
for how close it came to what
you had intended to make.
And it is a chance to change
and update the product backlog
by the team, usually led
by the product owner,
since they're the
person with the vision
and a lot of strong opinions, to
modify any changes to the plan
that you guys have
realized now that you
see what you've actually made.
I'll stop torturing you now.
So backlogs, task
lists, and tasks.
First step is creating
a sprint backlog.
It's pretty basic.
It's pretty simple.
Usually a product
backlog ends up
having lots of
really big stories.
Big fancy features.
The things that you
want your game to
do when everything is in and
it's all working at the end.
By nature, these are
usually big stories.
We want to have physics so
that the game feels realistic.
I want the player to
be able to develop
lots of different
powers through the game.
I want to be a long
complicated story.
I want there to be lots and lots
of characters to interact with.
I want a fully immersive world.
Never ever put
that in a backlog.
But I want a fully
immersive world.
These are all somewhere
passed extra large, often.
But in a product backlog,
it's OK to go that big.
But when you're
actually thinking
about what you're going to
do this particular sprint,
and this particular
iteration, you
got to get a lot
smaller than that.
For example, I want a fully
immersive world is not
getting done in one sprint.
Even if it's the only
thing you're working on.
So clearly you're going
to have to break that down
into smaller stories.
And the place you do that is
usually your sprint planning
meetings.
So as you break those really big
stories into smaller stories,
you can leave some of them
on the product backlog,
because oh my gosh.
We're not touching those yet.
And then you can decide which
of those pieces of the story
are complete enough
and small enough
that you can get them
done in the sprint.
Be it one week, or
two week, or a month.
And again, the size of
stories you're grabbing
is really going to vary, based
on how long your sprint is.
By definition, the sprint
you guys have coming up
is one week.
Because your project
is due next Monday.
So once you've got your
stories broken down
that you've pulled out, and
you've got your sprint backlog,
then you can start taking
a look at the tasks.
Except that's not
quite how it works.
Because it's kind
of easy to grab
too many stories onto your
sprint backlog at your first
pass.
And when you actually are going
through and estimating things,
and you realize just how much
work each of those stories
take, you may find you have to
put some of those stories back.
You may even realize that
some of the stories that
were at the bottom
of your priority list
are actually more
important than you thought
because you've got other stories
higher up that depend on them.
So while you're
doing your planning,
and while you're making
your sprint backlog,
and making your task list,
all a little bit-- you're
going to go forward
two steps, back a step,
forward three steps as you
both reorder your backlogs,
put stories back, take
stories back off as you're
trying to figure out how you
get all those dependencies
and squished into
what is actually
a really short amount of time.
You guys don't even
have what a sprint
team thinks of as a full week.
You do not have a 40 hour
work week ahead of you.
You have, per person, probably
a 10 to 12 hour work week.
Because that's about
the amount of time
the class expects
you to put into it.
So small.
Small stories.
Small tasks.
OK.
I just went through
all of that, didn't I?
How do you break things down?
When you're breaking
down your stories,
think about what's the
most important part of what
your breaking down into?
Because your stories have
a because, or so I can,
you can start
thinking about what
is most important
part of that story.
And which portions of those
stories you can just dump.
You don't need a
full physics engine
to create realistic driving.
Because, what the heck
does realistic driving
mean in this case any way?
Does it mean that it
accelerates, and it really
feels like it's
accelerating properly?
Doesn't mean that when
you handle curves,
you can feel it
spinning out on you?
What does feel mean anyway?
Does it mean that
the computer is
playing really realistic
sound effects for me?
That I'm getting really cool
sparks off of the wheels.
I'm getting this view
of the car spinning out.
When you understand
what you actually want,
then you can create
smaller stories
that let you break it down
and sign up just for that.
You can also take a look at what
the abilities of your team are.
And what you can actually do.
If you have somebody who's
really get at sound effects,
maybe you really
want to try to create
a realistic aural environment.
You're not going to worry
so much about the physics.
You're not going to worry so
much about the sound effects.
But boy, is it going
to sound sharp.
That's OK.
That's working within
your capabilities
and your limitations
to do your best
to fulfill your overall vision.
Philip really already
covered this pretty well.
I will zip right through it.
Tasks.
Think of them in terms of
going down to a half hour
is probably a waste
of your time if you're
looking at a whole
bunch of tasks
that are a half hour long,
that's a really small amount
of time.
On the other hand,
eight hours is probably
the biggest you want
to look at, given
that that's most of a week.
Ideally, you don't
have one task that
takes up your entire
week's worth of work.
If so, you're rolling some
really big dice there.
Because you're assuming that
your estimate is pretty good.
And especially the first
time you start estimating,
your estimate probably
isn't that good.
It is more common for
people to overestimate by up
to twice as much.
So, I can get this task
done in eight hours
often means I can get this
task done in 16 hours.
Think about that as you
are tasking things out,
and as you are creating
your sprint task lists.
So I think I've
mostly covered that.
Finally, once you have this
big pile of tasks on an Excel
spreadsheet that no
one actually ever wants
to look at again,
because they're
kind of hard to pick out there,
what do you do with them?
I mentioned Scrum boards.
I mentioned them
being preferably
there a physical Scrum board.
That's really not
realistic for us.
So you're going to
want-- and I really
strongly do recommend that
you use-- a visual Scrum board
solution.
Two that I have used
on projects that
work well for
different situations
are Trello and Scrummy.com.
Don't feel like you have
to use either of these.
If you find something better,
use it and tell me about it.
Because I want to know.
Especially if it's free.
So let me show you
very quickly-- let's
see if I can pull them up.
So here it is-- is that showing?
Here's scrummy.com
which I actually-- I
think it's kind of the easiest
and quickest one to use.
This is always going to be more
work for your Scrum Master.
So when you're
thinking about tasks,
set some time aside for your
Scrum Master, who's probably
going to create this board.
It's going to be
your responsibility
to maintain it, and
move things over,
but somebody's going to
have to type tasks into it.
And it would work
best if everyone
could be relied upon
to type in their tasks,
but it rarely works
that way, especially
since you often have a
whole bundle of tasks
that haven't been assigned,
at least at the beginning
of the sprint, because
people start picking them up
as they discover that
they've gotten stuff done.
So pretty much it works much
like a Scrum board ought to.
So you can create
all your tasks.
It divides things up
naturally by stories.
Although if you'd like to
put it by user, you can.
They're two standard ways
to organize a Scrum board.
Either organizing all
your tasks by the story it
belongs to, or by the
user who's working on.
Feel free to do it how
ever works well for you.
Scrummy, because
it's free, and you
don't want to pay for
the upgraded version,
won't let you change the
names of your columns.
But it's pretty hard from
the end of the world.
So if my stories demonstrate
so many of the [INAUDIBLE],
I have recorded the URL,
so I can get back here.
That's done.
I've made a new board.
That's all done.
And I confirmed the
board was there.
I've assigned a
task to Philip, so
that there can be a task there.
And it's a really pretty
quick and easy-- ah!
No, don't delete it.
It's really pretty quick and
easy to go ahead and edit
things.
It changes color, so you
can have different colors.
Easy to tell apart.
And it's really just
sort of a click and grab.
Click and drag, except
that I don't have a mouse.
Sorry.
I don't have a track
counter, and so it
takes these fancy two-fingered
maneuver to actually move it.
So I'm going to fail
to move it over,
but they're pretty easy
just click and drag
to the various things.
To the various sides.
So that's Scrummy, which has
less functionality than Trello,
but it's actually, in exchange
for that, it's quick and easy.
You type in a task, you
type in a name, you're done.
Trello-- and I apologize
about the resolution here.
Let's see if I can close this.
Trello let's you go ahead
and create as many columns
as you'd like.
You can name them
whatever you want.
You can put in all the
information you want.
If you want to track
your estimations here,
if you want to have a checklist
of subtasks that are related
to it, if you want to put
on pretty little labels
so that every user
has a different color,
or every story has a different
color, as long as you only have
five stories-- but
on the other hand,
you can also waste a lot of
time organizing your project
on Trello.
And it will look really nice,
and it will have all the data
there, and you will have
sucked all those hours
that you could have been coding,
or drawing, or actually making
a game.
So Trello can be
really nice to use,
but don't let it steal
your project from you,
if you choose to use it.
I was told that there's a cool
Scrum-free download extension.
Runs in the Chrome browser
that makes it work better
for Scrum because
it adjusts lists,
and it does some
previous set up for you.
I haven't tested that, so
I don't know how it works.
If you'd like to try it out, do.
But don't do it this project,
because you don't have time
to waste mixing it
around and fixing that.
Do that on outside
time, if you really
want to is my advice to you.
I don't want you to
spend a whole lot of time
getting the perfect
system together.
I want you to get a system that
works well enough and use it.
Yay.
Back to the slideshow.
So that is Scrum boards.
Ah.
Don't use PowerPoint either.
Apparently it has
to be difficult.
So the classic line
up on a Scrum board
is you've got all the
tasks in your to-do pile.
You've got the in-progress.
And anything in-progress
should be assigned to someone,
should have a name
attached to it.
It can't be in-progress if
someone isn't working on it.
And it should have a time
estimate attached to it.
Ideally, the time remaining.
Although, it's good to
keep track of how much time
has actually gone by on it.
The task cards are
really good places
to keep track of your
estimates as they change.
Then it's all in
together in one place.
Once you get finished, it
should not go over to done.
It's going to testing.
Someone who is
not the person who
did it should test it, and
then move it over to done.
That way you've got
a second set of eyes
on every piece of code and every
feature, just confirming it's
working.
Many Scrum boards also
have another column
called Blocked or On Fire.
Which is to say this
is a task that someone
can't get done until someone
else gets something out
of my way.
It's nice to have.
It's not required.
And if you're working on a board
that you're having a hard time
fitting everything
into one screen,
Trello has always a problem
for that with me, it's
OK to leave it off.
But it can be really
helpful to have.
That sort of is a Scrum board.
And I do really recommend them.
They are useful.
I know it feels like a
lot of extra time often,
when you're setting them up.
But if your team is
actually looking in there
and checking it every
day and updating,
it's a really good
way for the team
to know where it's at
without having to spend
a lot of time talking about it.
Because all the really basic
stuff is there to be seen,
which means you
could freeze you up
to talk about any real
problems that are coming up.
OK.
So that said, it's your turn.
You've got a week
left on your project,
so let's try creating a
sprint backlog and a task list
from that backlog
for what you're
going to get done for Monday
when you have your turn in.
I'm going to give you--
like all meetings,
they should be time boxed.
So I was going to give
you half an hour to do it.
I will check in at half
an hour, and if people
are screaming oh no,
we're nowhere near done,
I will give you another
10 minutes or 15 minutes.
Not actually a
whole lot more time,
but I'll give you
a little more time.
This is probably
doable in half an hour
if you guys have been
working on your project,
and you've got your product
backlogs in good shape.
But it's the first
time you're doing it,
so it's always-- it's
hard to know what
the right amount of time is.
After that, I will give
you five or 10 minutes--
probably call it five minutes
to talk about the process,
and have someone come up and
give a very short presentation
of what the process was like.
What worked, what didn't,
whether you liked it or not.
It's OK to come up
here and say bleh.
I don't feel like
this helped us at all.
Just come up and tell
us what happened,
and how it works for your team.
[CHATTER]
PROFESSOR: OK.
So [INAUDIBLE] meaning
we used Scrummy
to try to organize our product
backlog into our sprint task
list.
We found Scrummy to be a little
annoying, because it doesn't
automatically update instantly,
you have to refresh the page.
And whatever happens
last, we find,
is what it shows
as what's edited.
So it shouldn't break, but
it's not the most useful thing.
I think more useful would
be to Google use the Google
Doc of the product backlog.
Section out the stuff that
you do in that sprint,
and then just update it there.
We had it all color coded,
and so it looks really nice.
And that's much easier to look
at and do than importing that
into some other program,
and then doing everything
there and then going back.
It just seems better
to use Google.
PROFESSOR: OK.
Thank you.
[APPLAUSE]
[INAUDIBLE]
AUDIENCE: OK, so we used
Trello for our Scrum planning.
And we liked Trello
because you can just
create cards that
have lists of tasks
and easily move them around
between different columns.
So when someone takes on a task
they can move it to in-progress
and assign their name to it.
And it' really easy
to look at and see
what's going on at a glance.
Trello does have a lot of
features like checklists
that you might not want to use
a lot of, especially if you
have really complex tasks.
You don't want to put all of
those inside the checklist
because that gets confusing.
The thing that we had
the most problems with
was doing time
estimates for the tasks,
because no one in our group
has used Phaser before.
And so we have a very kind
of shaky grasp on how long
things are going to take, so
our guesses were mostly random
at this point in time.
But we will update that as
we get more experienced.
One thing that we did
find was really helpful
was when we were
drawing up goals,
we broke down all the
features that the game
needed into as fine
detail as we could
because we know what
results we need to have
to get the game to work.
But we don't know
Phaser yet, so we
don't know exactly what the
processes are going entail yet.
But having like
the list of things
that need to go into
the game gives us
some guidance on what we
should be developing towards.
PROFESSOR: Thank you.
[APPLAUSE]
Sparkling Redemption.
AUDIENCE: Sparkling Redemption.
We basically just
opened up Google Docs
and made a whole bunch
of Excel spreadsheets.
I think we're kind of
trying to use Scrum Do
and see how that
works, but we figured
it'd be best to just
kind of finish the thing
first, and then
take a look at that.
So no thoughts there yet.
I guess we basically
just took a look
at what we wanted to
get done by Wednesday,
and what we wanted to get
done by the end of the week,
and then broke that
down into the tasks,
and then worked with that.
I guess estimation
was-- it wasn't too bad.
Because some of us have
worked with Phaser before,
but there was also
a lot of things
where we realized oh, well,
assuming x is finished first,
then y would be really
straightforward.
But do we count x's
time inside of y?
Well maybe, but
maybe not really.
So that was as complicated
as it got, I think.
PROFESSOR: Thank you.
[APPLAUSE]
Blundermans.
AUDIENCE: So for
us, we started out
with a fairly detailed plan.
And we used Asana, which
is multi-player to-do list.
So, similar to Scrum.
But ultimately, our
entire team more or less
got sick over the weekend,
and we didn't actually
get much work done.
So we can't speak
to exactly how good
are estimates would have been,
or how useful our plans would
be.
So all the planning in
the world doesn't help
if your entire team is in bed.
PROFESSOR: Yep.
Thank you.
[APPLAUSE]
Blind Aliens.
AUDIENCE: So our team used
primarily Google Docs.
What we did was we had
our product backlog.
And we were a little confused
about the product backlog.
So we made it way too detailed.
But that really
helped with this.
So we ended up copying and
pasting our product backlog
into our sprint task
list, deleting everything
we'd already finished.
And then adding based
on what we had done.
And we found that because
we were further along
in our project, it was
really easy to tell
what needed more
work, and to get
the tasks more
detailed and better
estimates, just because we
had done a lot of already.
[APPLAUSE]
AUDIENCE: So we started out
planning on using Trello,
but did the product
backlog in Google Docs.
And since it's sort of this
information repeated twice,
we just stopped using
Trello, and ended up
using Google Docs anyway.
And that sort of helped us
out now, because all we did
was sort the things in
Google Docs by priority.
So we looked at the things that
were highest priority so we're
doing this week, and then
we just sort of thought
about each one.
How can we break this down?
What are the specific tasks?
You started working on this.
What's left to do here?
And then we put that into
the sprint task list.
PROFESSOR: Thank you.
[APPLAUSE]
AUDIENCE: So we've been using
Google Docs from the beginning.
We decided to not
use any other site,
because we had already started
working on Google Docs.
And it's worked out
pretty well for us.
We were able to take
our product backlog
and take the highest priority
that hadn't been completed yet,
and just split them up
into a finer detail task
that we can use for
the sprint task list.
And I think that that
worked fine for us.
It helped us really scope out
how much time we had-- helped
us reevaluate how
much time we needed
to complete the task
that we had to complete.
That is going to
help us for planning
for the rest of the week.
PROFESSOR: Thank you.
[APPLAUSE]
All right, so I have in fact, as
we say, iterate on everything.
I've iterated on
this presentation.
And been changing
the order of it.
So it may be I get
confused a couple of times.
I hope not.
We'll see.
We're going to talk a little bit
about high level and low level
here.
But as we said, in
this class we want
to iterate on as to the
every process you might use.
This is how you
control your team.
This is how your game works.
Everything.
And this is actually
not a bad philosophy
to do everything in
your life, that you
might want to consider
trying stuff, fixing
what doesn't work, embracing
what does work, and moving on.
But this also applies to
how you write your code.
And I can talk about-- on a
high level and a low level.
The where you put
your parentheses,
and exactly what kinds of
variables you use is a process.
And you make decisions on
that basis every moment
that you're coding.
And it's a really good idea
to think about what you did
and how well it worked
for you, or someone else.
And this is the kind
of thing that maybe
in your early
programming career you
don't want to think
about too much,
because just getting
the stupid thing to work
in the first place
is kind of hard.
But I'm going to try to convince
you that it's worth your time
to get these habits
going, so it's
easier for you in the
future to debug your code,
or someone else's code.
So I want to talk a little bit,
very briefly, about something
I mentioned in the
review on the lecture
on game engines, which is
that all software sucks.
And it sucks in different
ways and all that, right?
Well, the problem with this
is is that yours does too.
Your software is going
to have bugs in it.
And your job is to
try to make that
happen as little as possible.
You want your software to
suck as little as possible.
Now we also talked
about one reason
we use a game engine
is just so that you
write less code overall.
You spend less time doing that.
That's because everything that
you do when you're running code
is slow.
And in particular,
debugging is the slow part.
It's not too hard
to write new code,
but it's actually pretty
hard to go into old code
and fix what happens.
At it varies, depending on
the complexity of your task,
but generally speaking,
when you've written a bug,
later, you have
to spend the time
to figure out that there was a
bug, figure out where it was,
and then you actually have
to fix the stupid thing.
And that is actually where most
of your time is going to go,
when you're trying
to develop code.
So again, figure
out the problem,
and then change the
code to fix your bugs.
But I acclaim that most of the
time, figuring out the problem
is more of your time.
Now this isn't true for
the small bugs, when you're
typing something
at your computer,
and it doesn't work when
you compile it or whatever,
and it runs.
You go back and
fix it right away.
Yeah, that part of
debugging is not so much
figuring out the problem.
Because you just wrote it.
It's fresh in your mind.
You know what's going on there.
But if it's been a couple of
days or a couple of weeks,
then actually the hard
part and the slow part,
is figuring out what went wrong.
And so one of the
things that you
need to think about when
you're writing your code,
is you want to make it
as simple as possible
so that you're less likely to
write a bug in the first place.
Or once you've written
a bug, it sticks out.
It's easier to see.
And the important
thing to remember here
is that all this
code you have written
is not as easy to read
as you think it is.
And the right way to do this is
to make it as easy as possible.
And the way I like to think
about it, at least today,
is to make it require as
little knowledge as possible
to figure out what's
going on in your code.
If you use some really
fancy language features,
that's really cool, and
it feel like you're really
smart when you're doing it.
But a week later you
back to look at that code
to try to figure out, I don't
even know what I did there.
And heaven help you if someone
else tries to read your code.
So ideally, you don't want to
go too obscure into the computer
language fancy features.
You don't want to go too much
into your subject matter.
But there are
exceptions to this.
If for example, you work
on a very specialized
piece of software
where everyone has
to have an arrow engineering
astro degree to actually work
on the project, you can assume
some level of competency there.
But generally speaking,
in game development,
and most application
development,
you want to assume was
little knowledge as possible,
so that when you want
to debug your code,
you can look at the little
part of the code you're
at right now, and see if you
can fit what's going on there.
If possible, you want to assume
no knowledge on the part of who
was reading your code.
And I'm going to talk a
little bit about why that is.
This is a useful thing to
think about for user interfaces
or really any problem solving.
Humans can't hold that much
in their brains at once.
And if you're
trying to write code
that requires you to think about
10 different things at once,
you're in trouble, because
humans really don't do that.
Now generally we get
around this problem
with what's called chunking.
So when you started with math,
you thought about the number
five wasn't even
a numeral to you.
It was five objects.
But you couldn't really
wrap your brain around 12,
because you can't
look at 12 objects
and think oh, I understand
what that means.
But as soon as you practice
with your numbers more,
you begin to think of
number 12 as a unit.
It's not 12 things,
it's one thing.
It's the concept of 12, and
that's really useful to you.
And then you started
working through algebra
and you got variables.
And now you're using calculus,
and all the other cool things.
You talk about vectors in math.
A vector represents three
numbers, or a direction
or position in
space, but you don't
think about all three numbers.
And you certainly
don't think that 35
is one of those
numbers, and that
means that there are 35 things.
Your brain isn't
wasting time on that.
Instead your brain is
thinking, it's a vector,
it's a point space.
That's all I need to know.
So your brain is ignoring
a lot of information
by clumping a bunch of
information into one spot.
I often use phone numbers
as an example for this.
And it's an
increasingly poor thing
to use, because
I bet most of you
don't memorize phone numbers,
because why would you?
But when they started
[INAUDIBLE] phone numbers,
there are three parts
to a phone number.
First part is an area code, the
second part is a sub area code.
The third part is
the four digits
that are more unique, right.
It's really hard to
remember those 10 numbers.
But actually, once you
learn the area code,
the area code is three numbers.
You think of it as one number.
Boston is mostly 617.
The second set of numbers
is also three numbers.
You clump that as well.
And the last four numbers, yeah,
you have to memorize those.
But basically instead of
remembering 10 things,
you have to remember six things.
The four numbers and
then the two prefixes.
And another problem with coding
is that as you keep doing it,
you're making decisions
constantly in your coding.
What's the right way to do this?
What's the right variable
you're going to use?
Et cetera, et cetera.
And as you do this,
you get tired.
Humans only have so much
decision making in them
before they need a break.
So a couple of
things we can do is
we want to reduce
the amount of things
you have to remember while
you're looking at your code,
and we want to reduce
the number of decisions
you're going to have to make.
And to some extent, although
I'm not really clear
on a psychological
basis for this,
I'm going to make a crazy
claim that figuring something
out and deciding what this
thing must mean is a decision.
So even if you're just trying
to figure out something,
that also is a
burden on your brain.
And what you want to
do is keep your brain
alert and hopping as much as you
can, for as long as possible.
And to do that again, we want to
simplify your code if you can.
So to go back here, simplicity--
when I say simplicity,
I mean you want fewer
things to think about.
Should be easy to
read the code, so you
don't have to memorize
what the code is doing.
You can just quickly
glance and get
a reminder of what it's doing.
You have fewer bugs
because there's
just fewer moving parts.
Fewer things to go wrong.
I'm going to say this
hopefully a couple of times,
but a short variable name is
not simpler, it's just shorter.
If you start thinking about
what you spend time doing when
you're writing code, and
trying to get something done,
what takes the most time?
I'm willing to bet it's probably
going to be debugging part,
but maybe you think
it's going to be getting
the stupid thing to compile in
the first place or whatever,
but I'm willing to
bet almost none of you
think that your typing speed
is the thing slowing down
your coding.
If only I could type
80 characters a minute,
I could double my coding speed.
It doesn't work that way.
You do a lot of thinking, and
just a little bit of typing.
So if your variable name
is 12 characters long
instead of four characters
long, that is not cost you time.
It just costing you
eight keystrokes.
And in a modern
development environment,
you've got auto complete.
You type the first
four characters,
you hit control space,
and you get all 12, hey.
You can't even claim that
you've saved eight characters,
you've only saved six.
So anyway, I'm going to
talk about that a lot,
because I believe that
the longer variable
names are really useful cues to
remind you what you're doing.
And one of my favorite
things to talk about
is write once, read never code.
Who here has used Perl?
Anyone?
Have you tried to read
other people's Perl code?
Yeah.
Why would you try?
Have you tried reading
your own Perl code?
He goes, no.
That's right.
You just write it again.
Absolutely.
So, Perl if you're
not familiar with it
is this cool scripting language
that's not used as much now,
but it was once the
open source darling.
PHIP is kind of modern
equivalent of, my god,
don't try to read that code.
Perl had the nice feature
where pretty much every symbol
on your keyboard has a meaning.
And if you want to
do something, there's
probably three
different ways to do it,
with three different obscure
characters on your keyboard.
Worse, each of those characters
has a different meaning,
depending on what
you're using it on.
But this is an example
of APL code, which
a stands for A
Programming Language
developed in the late
'60s, early '70s.
And it's really painful
because in APL not only
does every character
on the keyboard
have meaning, they've
minted special keyboards
with an extra three
characters per key,
so that you could
have more characters.
And this is awesome if you think
of writing code as if piece
of paper with your pencil
and you're doing math,
and you're writing fancy
integral symbols, and this
and that, sure.
It's handy in math to chunk
those concepts this way.
But for coding,
generally speaking,
we're stuck on our
alphanumeric keyboard
with a couple of symbols.
And I advise you to use as few
of those symbols as possible.
Try to stick with your
language if you can.
All right.
Who here thinks that you write
enough comments in your code?
Wow!
Some of you do.
But almost none of you-- maybe
a quarter of you are like, yeah,
I'm proud of my comments.
It's cool to be proud
of your comments
if you're writing them.
And if you're not writing them,
don't be so proud of them.
But sometimes I see comments
that are just duplicating
what the code is saying.
If your if statement says,
if x is less than 5--
don't put a comment up there
that says if x is less than 5
do something.
That's a waste of time.
I can see that in your code.
But I want to know why you
care if x is less than 5.
That's the kind of comment I
would like to see in your code.
And we'll get to this
a little bit later,
but I also talk about longer
variable names, longer function
names.
Those are useful ways to
dodge writing comments
if they are correct.
But really quite
frankly, if you're
trying to figure
out gosh, I don't
know if I should comment
this or not, write one.
It's not going to hurt you.
So here's an example.
These comments don't mimic
the code, but what they do do
is they tell the story of what
the code is actually doing.
Random aside, font
is actually very
important with your editor.
Make sure you use a fixed
width font because pretty much
all programmers do.
And sometimes you use spacing to
have everything line up nicely,
and you want to have that
be crystal clear to anyone
else using your code.
But there's another way to this.
So this is code.
You can figure it out.
Go ahead and figure it out.
There's no rocket
science going on here.
We're using the
Pythagorean Theorem
to calculate a distance, and
make sure that if it's small,
we return 50.
There's nothing hard here.
A programmer can
figure this out,
but the programmer shouldn't
have to figure this out.
And that's my argument.
If you takes you-- I don't
know, maybe you're great
and it takes you two
seconds to figure that out.
Maybe it takes you 30
seconds to figure that out.
It doesn't really matter.
It should take you less
than that if the code
has been written correctly.
So for example, I'm just looking
at the 900 to 30 times 30.
Because why?
The compiler doesn't care.
It's a little bit
easier to read.
You can say if the distance
is less than 30, as opposed
to, if the distance
squared is less than 900.
AUDIENCE: And it's also the bug.
This also has a bug.
PROFESSOR: This does have a bug.
Good catch.
There's a bug here.
This code doesn't work.
Because we're saying y0 minus
1 instead of y0 minus y1.
So there's a better
way of doing that.
This is even easier to read.
We are using a vector instead.
The vector class has
some internal knowledge
of what it needs
to attract vectors,
and what the length
of a vector is.
Not only is this less bug prone,
but it's just easier to read.
And that bug that you
caught there can't happen.
Now this code is a
little bit cheating,
because I used v for the name.
So you can guess that they're
vectors, but that's fine.
Here's comments.
Basically the same code.
I'm saying, hey,
here's some context.
This is a lot more code.
In some ways it's harder read.
In some ways it's
easier to read.
That's one of the
things that you're
going to have to figure
out for yourselves.
What coding styles
make sense for you?
Obviously, simpler is
a subjective question.
But I kind of like
the style of code
because what it does
is it means that even
if you don't comment your code,
your code still is commented.
Because you can read this
and know what's going on.
More importantly--
and this is the one
I've change since the last
year I gave this presentation.
I thought that the
comments saying
why, and then the code that did
it was probably the better way
to go.
But a friend of mine
pretty quickly convinced me
that actually as codes get
maintained for a year or so,
you might change the code and
forget to change the comment.
And this actually happens a
lot in real software projects.
With the kind of
commenting or the kind
of self documenting code
that I'm using here,
that can't happen.
If you change the code,
you change the comment.
It's innate.
They're intrinsincally
linked because they
are the same thing.
If you can do this, it
actually helps a lot.
So I'm going to go through
a variety of tips and tricks
and things that
might make things
a little bit easier to read.
But before I do
that I want to talk
to you a little bit about to why
and who it is you're helping.
So a while back, I was
complaining to my grandmother
that wow, you know,
last year I made
a bunch of stupid decisions.
I didn't do this right,
I didn't do that right.
I'm so much smarter now this
year than I was last year.
It's amazing.
My grandma said, yeah,
I feel that way too.
All the time.
She was 84.
And I thought oh no, when I'm 83
I'm still going to be a moron.
So one of the people
that you're writing
code for-- one of the people
who will be reading your code
is not other people
on your team,
although they're very
important, but it's you.
You will read your code later.
Have any of you
looked back at code
you wrote six months ago yet?
You're early in your career,
so not many of you have.
But I'm willing to
bet when you look back
at the code you wrote six months
ago you think yourself a couple
things.
One, wow, I was an idiot.
And two, you're going
to think to yourself,
I could write this better now.
And three, you're
probably also thinking
even if the code works,
the algorithm is solid,
this is decent, it
could be more readable.
Maybe you're not
thinking that yet.
I want you to start
thinking that because you're
going to forget the
code that you write.
And again, when you're
just starting out,
that seems impossible.
That you can't forget
code that you just wrote.
But I guarantee you after you've
been writing code for five
years or more, a
lot, you're going
to discover that you don't
remember what you wrote
yesterday, or last
hour, as well as
now when you're just learning
and getting deep into it,
you remember a lot more
than you're going to.
But keep in mind
that experience.
And you go back to
your code and you
don't remember what
you wrote, that's
the experience your
teammates have every time
they look at your code.
They didn't write it.
They cannot remember it.
Your code is a communication
opportunity to talk your team.
To let them know what it
is that your code does.
So one way to make code more
readable, shorter functions.
You hear this
sometimes, all of us
are eventually write
that 500-line procedure
that does this, then
that, then the next thing
to the next thing.
We all do it, because it's
the easy way to do it.
You think, I'm going to do this
thing, so I do step 1, step 2,
and you march on through.
It's reasonable.
It's a way to get things done,
especially when your work is
in progress.
But if you ever want to
go back and fix that code,
and now you have to figure
out what pretty much
all 500 lines are doing.
And that's kind of dangerous.
The easiest thing I
can recommend there
is really if it is a step 1,
step 2, step 3 kind of thing,
why not divide steps
and sub functions?
The subfunction may only get
called once, but that's OK.
The reason this
helps you is twofold.
One, it gives you a nice name.
For this section of
the code is where
I am going to tell all the
planets to do build spaceships
this turn.
I make that a function call.
I don't have to worry about
what's inside that function
if I'm trying to
debug a war mechanic.
Because probably, the
part where all planets
are building spaceships isn't
relevant to the gigantic space
battle somewhere else.
But 2, when you
subfunction this,
inside that subfunction
you are guaranteed
that the local variables there
are unimportant for everything
in the big function.
The scope is such that they
can't affect the big functions.
They are local variables.
You don't to worry about that.
So this is a tiny couple
little class of bug
that you can kind of dodge
by something as simple
as subdividing a function.
Two-- and this is the
other important thing--
you've got this function, you
strip it down so hopefully you
can see it on a
page in your editor,
and you can read in English
kind of, what it's doing.
You see here the five steps.
There they are.
It's a little bit easier.
And that's kind of a simple,
straightforward example,
but it's that way
of thinking again,
that I want you to think about.
If you ask five programmers,
what's the right thing to do?
They're all going to
give different answers.
And that's fine.
But the thing I
want you start doing
is thinking about
what is it that you
think is the right thing to do?
Why would you consider doing
it this way versus that way?
And if you just write the
code and don't think about it,
you're not going to get
better as quickly as you
will if you think about why
you wrote the code that way,
and how it's working for you.
Here's another fine example.
Making wrong code look wrong.
This is perfectly valid code
unless I make my variable names
a little more descriptive.
And then you discover
that that's wrong code.
That code is terrible.
Degrees times radians
is a classic mistake.
Centimeters and inches
has destroyed Mars rovers.
Milliseconds, kilometers,
and miles per hour.
That's probably not
going to work so well.
And these are actually--
you say, I never do that.
But again, I kid you not, we
have lost billions of dollars
to unit conversions because
people didn't do this.
It's going to be
annoying to you,
when you're typing
it in, perhaps.
But I guarantee you, you'll
be safer if you do it.
Again, random stuff.
You've probably heard all this.
And we you're doing
games, you get
a chance to really
experience it firsthand.
Try to avoid sticking
numbers deep in your code.
No magic numbers.
You want to stick it in
a variable somewhere.
This has a couple good features.
One of the biggest is, you've
got someone else on your team
can easily look up that
number and change it.
They don't have to
find it in your code.
They can just look at your
list of variables somewhere,
and figure it out.
Immunity, it's
even more awesome,
because you can just go to the
editor and change it around.
Also, you can change
it globally everywhere.
If the number 50
is magical, great.
But call it something
else so that you
can change it to 51 when
you're tweaking your game plan.
I've talked with this before,
and I will talk about it
again if I get half the chance.
You want longer variable names
that say exactly what they are.
You don't want to have to guess.
They should be pronouncable.
And this isn't true for
everyone, but most people,
will tend to in their mind, to
say a variable name out loud.
And so if it's a bunch
of random consonants
that don't go anywhere, it's
a little bit harder to read.
If they look similar,
you don't want
to have a typo
kill your project.
Spell them correctly.
And this is actually
really important,
especially in
interpreted language
that just doesn't do anything
except running at run time.
In Python, for
example, I believe,
if you declare a variable
that's never been seen before,
it probably has a valid value.
No.
OK, good.
I'm glad that's true.
JavaScript.
That's what I'm thinking.
But JavaScript--
be very careful,
especially if you're
using Phaser JavaScript.
If you mistype the name, it's 0.
That's no good.
More and more modern
languages are rejecting that.
But the other thing is just
it's easier for your teammates
to know how to spell it.
If you all agree on a spelling.
And if you're all going
to agree on a spelling,
you might as well agree
on the correct one.
And then reusing a variable name
is also a little bit dangerous
sometimes.
If you're exiting a
loop, and you've maybe
failed to initialize
the thing properly.
You reuse a variable
name elsewhere.
You got this weird
value coming in,
and that's a bug
waiting to happen.
And it'll be kind
of hard to find.
Function Names.
All the same rules
basically apply.
You want to have it be
distinctive, spelled correctly,
you want them to
say what they do.
It's tempting sometimes, to
make your function name really,
really short.
Again, that doesn't
speed you up.
If a function is
longer, you get a chance
to read what it actually does.
But the other thing about
function names-- and this
is even more true than it is
for other parts of coding--
is that your function name tells
your other programmers what
the heck you just did.
I wrote this function.
Well, what does it do?
Well, read the function name.
It's right there.
That's ideal.
You can't always pull that off.
And when your function does
something more complicated
than you can describe in
four, maybe five words,
then you need a lot of
comments to describe
what that function is doing.
Ideally, your function
should be simpler than that,
if you can manage it.
By the way, I took to mention
variable names and links,
and a lot of you are
probably thinking right now,
yeah, a longer
variable name sounds
like a good idea in principle,
but I don't want to type that.
It would slow me
down to read it.
There's actually been
research done on this topic.
8 to 20 letters on average, is
often a marker for good code
that works with fewer bugs.
So I'm not talking
a little bit longer.
If you can push
it, push it harder
to be as long as you can stand.
And then you'll be a little
bit happier with that.
If you are coding in
VI or Punch Card still,
you could complain about
a 20-letter variable name,
but you aren't.
You're using a modern
development environment,
with auto complete, I hope.
Variable scope and names.
Ideally, and this is a
thing we strive to do,
and don't always succeed at,
you should name your variables
so that you can tell by looking
at them where they come from.
By which I mean is
it a global variable?
Is it a local variable?
Is it an argument
to the function?
That kind of thing.
You can sometimes do this by
prefixing, or post fixing,
or camel casing, or
not camel casing.
That kind of thing.
It doesn't matter
which system you use,
as long as you're
mostly consistent.
Trying to be consistent
among different programmers
is often difficult, because
everyone will horribly
disagree as to what
the correct answer is.
But if you can try to sort of
remove that from your brains
and say, actually it doesn't
matter what it is this time,
I just need to know
what you're doing.
That's the important bit.
Parallel rays.
These are free arrays.
And number 3 in each
array is related.
This is something
that you're going
to find yourself very tempted to
do a lot, especially in a game.
And I recommend against it.
Even if you only have
two parallel arrays,
I recommend making a
container classic that
contains both pieces
of data, and have
them stick in one array.
Just because you're going to
get bit sometime by having
these arrays get out of synch.
You just want to avoid
that if you possibly can.
Order of Operations.
There's an expression up
there, which is probably
legal code in most languages.
And we are taught in algebra
that we should memorize
the order of operation so we
know what gets multiplied when,
and all this.
But in computer language
we've got a lot more,
we've got incrementation, we've
got raise to the power of,
we've got modulo, we've
got all this crazy stuff.
And my argument is don't.
Why waste brain
space on memorizing
the order of operations for
the eight different kinds
operations you have, when
you can just use parentheses
and remove all doubt.
Plus, you could also even
divide that-- I'd divide that up
into a bunch of
statements, actually.
There's no reason to
keep it like that.
There's no way that someone
looks at that expression
and thinks, this is
the most intuitive way
to understand this.
If you're writing on
paper in math class,
you might find that because
you can use two dimensions,
you actually can make your
equation more intuitive.
But in code, you mostly
only have the one dimension.
And so it's kind
of hard to really
make your math intuitive.
So I would put extra effort
into just split it up.
I also mentioned this last time,
I'm going to mention it again.
It's very important.
Warnings should always
be treated as errors.
I can could repeat it again,
but basically every new warning
is a hint something
might be wrong.
And if you let your build
be cluttered warnings,
you will not notice when the
important warning pops up.
And you can lose hours
to that, just because the
build wasn't at zero warnings.
Backwards Conditionals.
Which of these looks wrong?
The second one looks wrong.
I agree.
The second one totally looks
wrong, and yet it's useful.
Because what happens
if you mistype
the equal to equal sign?
If you mistype the
equal to equal sign,
that second one doesn't compile.
Depends on your
language of course.
But generally speaking,
it's a handy little trick
that I find useful, and everyone
else I know thinks is terrible.
So don't necessarily
use it, but try
to find tricks like this that
cause to be the case, that when
you mistyped your code, you
get a compile error instead
of a bug in your code.
AUDIENCE: Do you think
what the signal equals
might be a client warning?
PROFESSOR: It will be
a warning, absolutely.
Which is an even better
reason to not to go down
to zero warnings, right?
Doesn't help you if it's
a warning that you just
let go by.
And it should be a warning.
I'm glad they added that.
When I start programing,
it wasn't a warning.
Wasn't that wonderful?
I mentioned splitting
up the math.
I think that that first
thing is, you can read it.
You can figure it out.
I think that the second
thing might be a little bit
more comprehensible.
Again, it depends
on who you are.
This is one that
I'm emphatic about.
I mentioned order of
operations before.
Bar minus minus.
That's fancy.
In some languages, and I
assume most of the modern ones
these days, bar
minus minus means
do the math, and then
decrement bar by 1.
If I'd said minus minus bar, I'd
have meant decrement bar by 1,
then do the math.
And this is pretty cool.
It's this nice little
language trick.
But if you don't happen
to know what that means,
you just confuse your
fellow programmer
with your language trick.
That second thing
is perfectly clear.
You know exactly what happens.
Do
The math, then
decrement the variable.
And if you really
want to get pedantic,
I guess you could say
bar equals bar minus 1.
But you have to draw
the line somewhere.
I'm a fan of Booleans
being asking a question.
Like the Boolean purple
probably means is purple.
The Boolean hungry probably
would mean are you hungry.
But the Boolean desk
might not mean anything.
But in any event, try
to make your Boolean
into a question that has an
unambiguously yes, no answer.
Which way is true?
Which way is false?
Status is a
particularly bad one,
because I don't know
what that means.
Is status true good?
Is status true mean that
something bad happened?
I don't know without some help.
You've probably heard this
before, mysterious constant,
don't do it.
Ideally, if you can define
it in your language,
you get an error.
When you mistype it,
and that's much better.
Mysterious string constants
is particularly the worst.
And you're going to be very
tempted to do it in JavaScript.
But you should probably
have a defined of some kind
at the top, so you
don't get that problem.
This is a language construct
which is very handy,
but I recommend
using it sparingly.
If you are asking
a question-- if you
want to set a
variable to a value,
it's often very convenient
to do this syntax.
But really, you don't
want to ever nest these.
If you nest them it becomes
unreadable gobbledygook.
And if your expressions
become complicated,
it also becomes
unreadable gobbledygook.
Again, I'm not saying
you can't figure it out,
because I'm confident
that you can.
But why do you want
your future you
to have to spend 30
seconds to a minute,
figuring out what
the heck you were
saying instead of two
seconds figuring out
what you were saying?
Goto.
We are told that goto is
evil all the time, always.
I claim it's not always evil,
but you should be careful
when you use it.
It's particularly
useful when you're
exiting a horrible set
of nested if statements.
But the main reason
goto is evil,
is because of a thing
called proximity.
Which is that you should
use things near each other
in the code.
If I declare a variable,
and it's two screen pages
up from when I use it, that's
kind of a difficult thing
to figure out.
That's one reason to keep
your functions short.
But instead, if I can
clump it together,
I'm less likely to make
simple little errors.
Right here, I'm doing the
same thing to x and y,
and I'm interleaving it.
Because I'm thinking of it
as, I want to prepare them,
I want to calculate
it, I want to print it.
But it's a little
bit easier, I would
say, to debug and
think about it,
if you treat each
one separately.
And if you get a lot of these,
write a loop or something.
There's no reason to
actually type it all out.
All I'm saying is
keep it simple.
As simple as you possibly
can, so that later,
when you go back to it, you
can figure it out quickly.
You're going to very tempted
to make complicated systems
in your prototype games,
even though you're
game spec is changing,
probably daily.
So you might want to be a
little bit cautious about that.
Rather than making a
complicated system, solve
the problem you have today, and
then maybe two days from now,
when you know for
sure you're actually
doing that, you might want
to put more effort into it.
This is advice that's not
good for all projects,
but it is good for
very short projects.
It's tempting to create
a complicated system that
will do everything you need.
And it's tempting to
create one solution that
will solve all of your woes,
but you might very well
be borrowing trouble and solving
a problem that you're never
going to have.
So given that you're probably
talking about fast iteration.
Your game is changing
all the time.
Don't-- and this is counter
to my architectural design
thoughts-- but don't
design too much,
because you're going to
change it all anyway.
Other things that cause
bugs are recursion.
Recursion is awesome.
Recursion is fun.
Recursion is really
hard to debug.
Try debugging someone
else's recursion,
and you'll be very sad.
To try debugging two things
that call each, other sadder.
And it looks really cool,
but I recommend don't do it.
Similarly, optimizing.
Wait.
You think you know what
slow and what's fast.
Chances are, you don't.
If your development
system has a nice profile,
it'll tell you exactly
where the bottlenecks are,
exactly why your code is slow.
Wait for that, and fix
the actual problems.
Don't waste time chasing ghosts.
Particularly this
happens a lot when
you're trying to do some code,
and you're thinking oh, this
is really important.
It ends up being
called once per second.
Well, once per second in
computer time is never.
So don't bother optimizing that.
But the nice thing here is
that a profile can tell you
what you need to actually fix.
I've mentioned fixed treat
warnings as errors before.
I'll mention it again, probably.
But similarly, you want to fix
a bug as soon as you find it,
if it's in your head.
Don't think oh, that
bug is easy to fix,
I'll get to before
the end of the sprint.
Because you might
not remember it
four days from now as
clearly as you do right now.
Also, if you've just
written the code,
it's much, much easier for
you to actually fix it,
because it's all much
more fresh in your mind.
Strongly consider not fixing
bugs that don't matter.
And this is a tough one because
I just contradicted myself
by saying fix them right away.
And I'm telling you
sometimes don't fix them.
But basically, if fixing the
bug is going to cost a lot time,
and it's not going to
improve your game enough,
then consider leaving it.
That's going to
be a thing you'll
have to talk about with
other people your team.
But hey.
So for example, if you've
got every j in your text
renders green for some reason.
And to fix that, you need
to go into the font library
and do some crazy code.
Well don't.
Claim it's a feature.
J's are green.
Obviously, if you're
doing Microsoft Office,
you can't do that.
But we aren't.
We're doing games.
So we can cheat like that.
Use a debugger.
If you do not yet know
how to use a debugger,
take advantage of this class
to learn how to use a debugger.
I can't really say
more about that.
Do it.
When you're also try to figure
out a bug, talk to a teammate.
Even if your
teammate has no clue
about your part of the code,
the act of putting into thoughts
and words, this is what
my system is doing,
will, a good third of
the time, cause you
to realize where the bug is.
It's kind of silly,
but it totally works.
So if someone comes to you
on your team and says hey,
I need help.
You're like cool.
I'll listen to your problem.
And they talk to for
15 minutes, and then
say, I got it, and walk
away, don't feel useless.
You just saved them an hour.
And it cost you 15 minutes.
And that's a bargain.
And don't feel
embarrassed about it,
if you're the person
talking about your bug.
It's great.
They may ask you questions
that are irrelevant,
and you're like, no, no.
That's OK too.
You have to explain it.
That orders it in your head, and
then you can solve the problem.
And then of course, take a walk.
I have solved more bugs going to
get my lunch, or in the shower
in the morning, or whatever,
than I have at my desk,
I would say.
At least more tough ones.
Binary search is a thing that's
kind of hard to describe.
But rather than
necessarily saying,
this could be the
problem, I'll test that.
This could be the
problem, I'll test it.
If you can do a test that
says, well, roughly half
of the potential problems
that could cause this bug
are over here, and half
of them are over here,
and I can do one test
that won't tell me
where the bug is, but will
eliminate this entire tree,
that's a good test to do.
You can quickly narrow in on
where your bug actually is.
And this one happens a lot
too, with beginner programmers.
If your bug goes away, it
probably hasn't gone away.
It's just hiding now.
So be sure you know
why the bug went away.
If it's the green j's, you might
not need to worry about it.
But even then, you might
want to think about it.
Because you thought you knew
what the green j's were,
and they went away,
and you didn't fix it,
but who knows what's
going on here.
It's worth putting a little
bit of time in to make sure
that it isn't some serious
bug hiding under the covers.
I'm not going into
source control again.
We've already done a
little bit of that.
You need to do source control.
If it all possible,
everyone on the team
should be able to just get
the code and do a build.
That should be as hard is it is.
And on that realm, daily
builds are awesome.
If you can afford to,
have some on your team
whose job it is, once a
day, midnight, pick a time,
do a get, a fresh
get, do a build,
make sure everything works.
This sort of forces
all the programmers
on the team to sort of be
more careful about making sure
their code works.
And also if something
gets checked
and it breaks
everything horribly,
you know about it right
away, not three days later.
There are automated tools
that will do this for you.
At least they'll check
the compilations step.
That might not check that
makes sure everything is still
working, but, you know.
It gets there a lot.
Coding Standards.
Why we use them.
We like tidy code.
And obviously, the braces
go in one place or another.
Those are terrible reasons
to have coding standards.
Instead, these are the reasons
that I like a little bit more.
Which is my code--
don't touch my code.
Well, you're on the same team.
I'm going to touch your code if
I need to, and it's midnight,
and you're asleep and
I need to fix the big.
That's the way it is.
You shouldn't be mad about that.
We're trying to fix the game.
The fact that that you wrote
the first pass in the code
doesn't really matter.
And then, of course
decision fatigue
is a thing I mentioned earlier.
We talk about what
variable names to use,
and what algorithm to
use, or this or that.
We got plenty of
decisions to make.
Where you put your
curly braces should not
be something you waste
time stressing about.
If you have a coding
standard, use that.
If you don't have a coding
standard, be consistent.
If you're modifying
someone else's code,
stick with their
coding standard.
Because if nothing else,
when you do the check in,
it will look like
the entire file
has changed just because
you changed the indentation
strategy.
And that's not very
useful if I want
to know what changes you made.
I'd much rather have a
minimal set of changes
that I can look
through and see what
the actual meaningful
changes you made were.
And of course, easy to read.
Easy to debug.
A lot of things I've
been talking about
are things you can
read a lot more about.
There are people that
have written serious books
on the topic of making your code
as easy to read as possible.
Steve McConnell
in particular, is
at this point-- his
books are older,
but they're still
perfectly valid.
Because the science
of writing code
has not really changed much.
Joel Spolsky also has
a much easier to read
set of blog posts that talk
about this kind of thing.
It's much more
accessible and it's free.
And he's the person who--
his company is behind Trello.
Which kind of indicates that
his method of thinking kind of
matches with our
method of thinking.
There's a lot more things to
think about in these realms,
in terms of ways to
make your code easier.
But again, I want to go
back to the core concept
we talked about before.
You're going to have a couple
projects during the semester
where you're going to see
a bunch of different coding
styles.
Yours and other people's.
Yours might even change over
the course of the semester,
and that's good.
But you should include, perhaps
as part of your post mortem
process, what
kinds of things did
you like in the code you saw.
What can you pull into
your coding style that
is going to make your
code easier to read,
or easier to debug?
And maybe you can try to
influence other people
to write prettier code.
You're not always going to
agree what pretty code is.
Try to let that go
when it happens.
The important thing is you
should think about what you're
seeing, so that after
your project is over,
you are better
programmer for it.
And I think at this point,
unless you have any questions,
we'll go on to have this project
time with the remaining 15
minutes.
[CHATTER]
