►
Description
As we scale our continuous delivery processes for a large development organisation, developers get more and more updates every day regarding automated test results, performance regressions, code coverage, etc. Would we design our feedback loops the same way if we put the developers first? Let's optimise the cognitive workflow of our developers; and design our supporting CD tools from this angle.
Laurent is Technical Product Owner at Spotify, in charge of the client continuous integration infrastructure. He is passionate about software development effectiveness, as it involves both people interactions and technical tooling. He likes to develop in Python.
About Satellite:
GitHub Satellite 2016 was a celebration of the latest and greatest in development. Watch the recordings to learn how engineers, founders, activists, and beyond tackle the latest and most difficult challenges in software.
For more, join us in San Francisco on September 13th-15th for GitHub Universe, three days filled with the creativity and curiosity of the largest software community in the world.
For more information, go to githubuniverse.com.
A
Thanks
everyone
for
coming,
my
name
is
Lauren
I
work
for
Spotify
for
about
two
years
and
I'm
passionate
about
development,
fast
development,
efficient
development
and
human
beings.
Today,
we're
going
to
talk
about
what
does
it
take
to
scale
continues:
delivery
continuous
integration
when
well,
when
you
have
a
lot
of
more
information
than
before,
when
you
have
a
lot
more
developers
and
actually
the
stuff
you
learn
in
school,
they
confuse
delivery.
So
on
doesn't
quite
work
so
well.
So
all
of
us
here
all
of
us,
we
are
humans,
your
arguments.
What
does
that
mean
ready?
A
It
means
first
we
build
relationships,
I'm
building,
something
with
you,
you're
building
some
with
other
people
in
your
team,
you're
building
relationships
with
your
customers,
but
also
means
that
you
learn.
You
learn
from
your
mistakes.
You
learn
from
your
successes.
You
actually
learn
a
lot
more
from
mistakes
and
from
successes.
You
learn
from
your
peers.
That
also
means
you
can
make
concepts.
A
You
tell
stories,
that's
what
I'm
doing
now
I'm
telling
you
a
story.
Hopefully
you
can
remind
that
you
can
remember
it.
You
probably
think
stories
to
people
around
you,
including
your
kids.
Maybe
you
dream
you
dream
of
new
solutions.
We've
heard
like
this
morning
that
people
in
github
dream
of
new
solutions
for
open-source
development
in
Spotify.
We
dream
for
like
the
best
music
at
the
best
time
for
you
and
that
enables
you
to
create.
You
create
new
things.
You
can
like.
Imagine
you
ideas
and
actually
do
it.
A
So
you
know
that
you
have
a
fantastic
team
in
your
startup.
So
of
course
you
want
to
enable
all
your
developers
to
create
new
stuff
together
and
for
that,
because
you
know
you
read
that
you
open
a
book,
you
created
a
perfect,
continuous
delivery
system,
so
you
know
that
you
don't
write
continuous
integration.
Now
you
have
liked
1,
2,
3,
10,
15,
different
agents.
Running
builds
for
a
given
commit.
You
had
tons
of
information
that
come
back
to
you.
A
Of
course,
you
saw
like
you
need
test,
because
you
know
right,
I
mean
unit
NC
work,
the
deliver
you
good
value
is
a
fair.
You
should
fix
it
immediately.
A
result.
Fine
you
created
performance
test
by
the
way,
every
single
test
is
a
performance
test.
You
do
just
to
see
how
long
it
takes
to
run
and,
of
course,
you've
got
more
test
integration
system,
tester,
like
whatever
you
want
to
call
them.
You've
got
tons
of
tests
that
have
been
pushed
into
your
system
and
the
delivers
like
value.
To
certain
extent.
A
They
tell
you
if
something
goes
wrong,
a
right,
mostly
when
it
goes
wrong.
You
know
you're,
you
know
how
to
do
that.
You
create
small
increments
and
you
deploy
that
with
containers
or
some
sort,
some
dog
or
whatnot,
and
you
well
your
orchestrator
of
that
and
you
think
you're
going
to
be
able
to
scale
pretty
well,
because
you
deploy
that
each
and
every
time
you
can
like
potentially
several
times
a
day
or
even
several
times
an
arrow.
A
But
really
what
you
realize
is
that,
after
a
while,
you
move
to
more
like
100
to
one
hundred
developers
and
when
you
hire
more
developers,
you
actually
don't
go
any
faster.
Something
is
wrong.
You're,
you
sort
of
a
plateau,
see
what
I
mean
like
it
doesn't
quite
scale.
So
it's
probably
a
problem
of
information
overflow.
A
A
A
You
also
realize
that
the
teams
which
are
really
fast,
our
autonomous
from
each
other,
so
it
typically
means
that
if
I'm,
a
team
and
I
need
to
upgrade
some
schema
somewhere
in
a
database
and
the
other
team
is
not
ready
to
do
that,
then
we
basically
have
to
wait
for
each
other
and
we
slow
down.
So
it's
much
better
if
we
all
have
our
own
part
of
the
database
that
we
can
upgrade
when
we
want
or
switch
another
language
or
whatever
other
things.
So
you
want
to
avoid
adding
synchronization
points
between
the
teams.
A
Dependencies,
it's
a
myth
to
think
that
teams
don't
depend
on
each
other.
They
do
in
Spotify
everyone's
want.
Everyone
wants
to
access
like
how
to
play
music.
It
helps
so
you
want
to
like
create
an
environment
where
the
different
teams
are
kind
of
do
not
depend
on
each
other
too
much,
and
if
there
is
a
bug
in
some
other
part
of
the
system,
we
don't
want
them
to
impact.
You
we'll
look
at
that
bit
error
large
code
base
you're
going
to
work
as
a
developer
for
about
30
years.
A
A
If
you
need
to
read
that
from
the
beginning
to
the
end
and
spend
an
average
time
of
10
seconds
on
every
line
to
and
really
understand
it,
it's
going
to
take
your
entire
life.
Think
about
it.
It
means
that
if
you
want
a
developer
to
be
able
to
fix
a
problem
in
five
minutes,
you
need
to
shrink
30
years
of
work
in
25
minutes.
That's
what
it
takes.
So
you
cannot
let
you
cannot
force
people
to
understand
about
like
a
million
lines
of
code.
It
just
doesn't
work.
A
The
thing
that
works
pretty
well
in
a
team,
if
you
want
to
scale,
is
that
people
need
to
be
able
to
keep
track
of
what's
happening
around
them.
It
does
to
do
with
like
the
size
of
the
team,
meaning
like
I
understand
everything
around
me
understand
the
world
I
live
in
I,
understand
that
this
other
person
is
doing
something
on
the
database,
while
I'm
doing
something
on
the
front
end
and
I
sort
of
keep.
All
of
that,
in
my
mind,
I
understand
those
things.
A
The
thing
is,
people
make
mistakes
and
the
impact
of
a
mistake
has
to
be
small.
So
let's
say
you
have
200
developers
and
each
of
those
developers
make
what
mistake
every
second
year
like
a
bad
mistake,
something
that
breaks
your
code
badly,
potentially
in
production,
because
you
deploy,
of
course
well.
That
means
that
you
have
a
pretty
bad
situation
every
second
day
on
average.
A
We
cannot
underestimate
or
overestimate,
or
the
importance
of
the
coffee
machine
one
for
me
at
least,
but
because
the
person
you
talk
Wiz
on
the
coffee
machines,
that's
if
you
cannot
talk
directly
into
the
deep
problem,
like
in-depth
into
your
problem
with
the
person
you
have
in
front
of
you
in
at
the
coffee
machine,
then
you
got
a
problem
of
communication
with
the
other
person.
If
you
stay
at
like
a
high
level
of
oil,
we
got
this
type
of
problem.
A
You
know
high
level
whatnot
fine,
but
then
you
not
really
get
good
information
at
the
coffee
machine.
The
person
you
see
at
the
coffee
machine
you
need
to
be
able
to
go
deep
into
your
issue
with
them.
That
means
that
it
needs
to
be
kind
of
constrained
in
terms
of
complexity
and,
of
course
we
need
to
cross
people,
but
that
basically
means
that
I
know
that
if
I'm
asking
someone
to
do
something
and-
and
they
don't
do
it-
I
know
that
is
because
they
have
a
good
reason
for
that.
A
It's
just
not
because
it
ceases
all
the
team
in
this
other
room
somewhere
and
of
course
they
don't
make
priorities
correctly,
because
that's
my
priority
that
counts
so
and
also
like.
Of
course,
we
got
10
million
lines
of
code
or
whatever,
if
you
build
that
it's
going
to
take
a
few
hours,
and
it's
really
really
bad
for
velocity
of
your
team.
A
So
we
have
to
rethink
basically
millions
of
like
the
code,
hundreds
of
developers,
you
have
a
real
problem,
so,
let's
think
about
it.
Do
we
have
limitations?
I
mean
we
can
dream.
We
can
do
fantastic
things,
but
we
also
have
some
limitations
and
the
problem
so
far
has
been
that
we
have
all
built
or
continuous
integration
continues,
delivery
systems
based
on
technical
assumptions,
but
it
will
really
take
the
human
into
account.
So
we
also
have
some
limitations
that
we
need
to
introduce
in
that.
A
First,
one
is
I'm,
sorry
to
tell
you,
but
your
short-term
memory
is
kind
of
small.
That's
what
it
is.
Not
I'm,
not
saying
that
just
google
that
basically
that
means
that
when
you
build
like
notions
into
your
brain
and
you
try
to
understand
something
which
is
new
to
you,
that's
the
number
of
things
you
can
put
in
your
brain.
You
have
what
we
call
combined
knowledge.
A
What
is
combined
knowledge
is
the
knowledge
that
you
don't
even
realize
you
have
you
basically
execute
like
you
when
you
see
it
a
problem
on
the
screen,
you
sort
of
nowhere
where
it
comes
from
so
quickly
technically,
and
you
go
directly
to
the
place
where
it
is
like
you
solve
some.
Some
people
call
that
culture
or
experience.
If
you
want
that's
basically
the
same
thing
you
want
to
help
people,
as
is
a
get
used
to
I,
mean
use
these
combined
knowledge
that
they
have.
A
You
cannot
multitask
like
stop
that
you
cannot
multitask
period
like
stuff
people
say
they
can
it's
not
true.
So
if
you
can
multitask,
if
you
can
look
at
your
phone
right
now,
it's
probably
because
you're
overpaid,
because
if
you
can
/
multitask,
is
because
you
don't
do
something
smart
enough
or
complex
enough.
You
cannot
context
which
so
far
really
well.
If
you
have
two
contacts
which
you
will
typically
text,
seven
to
ten
minutes
to
get
into
something
complicated.
So
if
you
read
your
email,
every
15
minutes,
you
do
nothing
during
your
day
or
nothing
smart.
A
You
can
go
to
the
level
of
abstraction
levels,
but
not
that
far.
If
I
pro,
if
I
produce
data,
you
can
probably
compute
the
average,
you
can
probably
compute
the
distribution,
something,
and
you
can
also
take
one
step
further
and
say
well,
I'm
going
to
be
able
to
compute
the
probability
that
my
average
is
right
or
how
right
it
is.
But
if
I'm
asking
you,
what
is
the
probability
that
your
probabilities
right
you're
like
really?
What
does
that
mean?
A
It
doesn't
meaning
from
a
mathematical
point
of
view,
but
it
doesn't
really
mean
anything
for
us,
so
you
need
to
avoid
having
to
you
to
go
too
far
into
abstractions
and
you
hate
uncertainty.
I
mean
if
you
develop
something,
and
you
have
a
bug,
you
don't
want
to
question
the
compiler
or
the
OS.
You
want
to
question
your
code.
Some
people
say
select
is
not
broken.
Don't
try
to
check
if
the
Select
is
wrong
in
your
database
is
not
right.
Look
at
your
code.
A
We
tend
to
remove
the
pain.
If
we
do
something
really
difficult
and
at
the
end
of
the
day
we
realize
that
we
wasted
our
time
and
consciously.
We
will
try
to
avoid
doing
those
things
again.
We
will
I
mean
we
will
try
to
okay.
Maybe
I
should
read
that
email
first
before
I
go
into
that
problem
because
last
time
I
did
it.
It
was
so
painful
and
we
like
treats
right
like
everyone
else
when,
when
it's
funny
to
develop
something
we
like
to
do
it.
A
So
this
is
like
the
limits
we
have
to
deal
with
and
we
need
to
introduce
that
into
our
development
processes.
Continuous
integration
confuse
delivery,
so
here
they
are
so
we're
going
to
look
into
like
what
we
to
do
and
what
we're
doing
right
now
in
Spotify.
You
know
that
you
like
to
use
these
things
or
take
them
into
account.
A
So
first
is
you
need
to
be
really
really
fast
at
giving
feedback
to
your
developers
when
it
comes
to
building
or
to
testing
or
whatnot,
and
by
really
fast
I
mean
seconds,
not
minutes,
not
not
half
an
hour.
It
has
to
be
in
seconds.
So,
if
you
can
so
you
need
typically
to
use
basil
or
black
or,
like
incremental,
builds
of
some
kind.
You
need
to
be
able
to
to
start.
The
testers
are
most
likely
going
to
fail
and
so
on
and
so
forth.
Why?
That?
A
Typically,
what
we
do
is
that
we,
like
we
monitor
the
time
it
takes
to
build
stuff
on
the
developers
machine
like
and
we
like
make
average,
and
you
know
press
on
ties
and
so
on.
We
try
to
shrink
shrink,
shrink
shrink,
even
if
you're
talking
about
millions
of
lines
of
code,
we
also
money
to
offer
instant
the
time
it
takes
for
a
developer
when
they
submit
a
PR
that
it
gets
approved
should
be
in
minutes
if
possible
hours
may
be,
but
certainly
not
days.
A
A
Of
course
nobody
ever
tries
to
build
with
the
latest
from
the
internet
right.
You
don't
do
that
right.
No
one
builds
NPM
stuff,
javascript
stuff
using
the
latest
version
of
any
software
on
the
internet.
Do
you
like?
No
one
does
that
right,
but
for
those
who
do
that's
a
bad
idea?
Why
is
that?
Because
you're
going
to
build
things
twice,
it's
not
going
going
to
give
you
the
same
results.
It's
really
really
bad.
So
let
me
give
you
one
example.
A
So
we
make
statistics,
and
so
these
are
the
different
builds
on
the
x-axis
and
the
y-axis
is
the
results.
So
green
is
good.
Ever
is
not
green
is
not
good.
That's
really
not
something!
You
want
to
deal
with
right.
I
mean
whenever
there
is
a
new
build
on
the
same
shower.
You
get
different
results.
You
hate
it
as
a
developer.
You
don't
know
what
you
look
for
right,
so
you
want
to
avoid
that
thing.
A
A
You
need
to
consolidate
information
from
multiple
places,
so
why
is
that?
Well
you
get
from
CI
you
get
a
unit
as
visual
performance
results.
Log
files,
whatnot-
okay,
although
that
comes
from
from
Jenkins
from
density
from
bamboo,
from
whatever
you
use
circle
CI
or
it's
fine,
but
it
typically
come
in
different
places.
A
So
if
you
have
ten
instances
of
Jenkins
you're
going
to
get
to
click
ten
times
to
go
to
the
different
places-
and
you
also
have
to
click
on
one
side
to
go
to
the
unit
test
and
the
other
tab
to
go
to
the
two
logs
and
so
on.
So
as
a
brain,
it's
really
hard
to
go
everywhere
and
make
sense
of
all
that.
What
you
need
to
put
is
you
need
to
produce
all
this
information
together
so
that
you
can
make
sense
of
them
together.
A
So
you
need
to
give
people
context
context
as
to
you,
okay,
I'm
running
my
test
in
my
PR
and
I,
get
a
red
sign.
Something
is
wrong.
Something
is
broken
in
my
test.
Thus,
this
result.
Okay
on
the
top
right
here,
got
a
broken
test
right.
So
BL
goes
this
way.
That's
a
history
of
my
my
branch
and
the
other
side
is
all
the
tests,
so
one
of
them
got
red,
of
course,
is
one
needs
to
be
fixed
right.
You
understand
this.
One
is
is
red,
but
this
one
is
red
as
well.
A
A
You
know
you
need
to
know
if
the
test
was
flaky,
if
it
was
not
flaky,
if
the
reason
for
because
it
felt
the
same
one
as
before
or
not,
if
all
the
tests
are
failing
as
well
or
not,
is
that
the
only
one
it
does
a
brand
new
test
that
just
got
created
and
you
need
to
fix
it?
But
you
see
what
I
mean
it's,
it
doesn't
tell
you
anything
to
you.
Have
a
snapshot
of
one
built,
one
state
of
your
code.
A
You
want
people
to
look
at
stuff
that
matters
we
have
hundreds
or
actually
thousands
or
dozens
of
thousands
of
tests
that
are
that
are
run.
The
only
one
you
care
about
us
are
the
risky
ones.
Do
you
want
that
contain
lot
of
problems
so
race?
You
really
don't
care.
So
what
do
you
do?
Well,
you
just
order
them
to
you
see
that
the
one
on
the
top
arm
more
problematic
than
the
one
at
the
bottom
right.
So
why
do
you
need
to
send
all
that
information
to
everyone
in
a
random
order?
A
Another
thing
is
like:
if
I'm
a
developer
and
I
get
a
performance
regression,
for
instance,
I
need
to
know
what
does
that
tell
me
to
have
a
performance
problem?
Well,
I
need
probably
to
talk
to
someone
or
maybe
I
just
need
to
fix
it
myself.
But
basically,
let
me
give
you
an
example
what
you
actually
need
you
need
that
you
need
that.
Okay,
something
has
been
wrong.
Suddenly
you
gotta
drop
in,
say,
I,
don't
know
whatever
memory
time
to
do
something
whatever
something
is
measured
and
something
changes
brutally.
A
That's
usually
what
happens
when
you
make
a
preference
test?
You
have
got
big
big
changes
in
one
go.
Well.
What
you
need
to
know
is
who
did
that
I'm
talking
about
tests
on
on
master
here?
Who
did
that?
Why
we
stick
it
out?
What
that?
What
is
the
context
of
that
plan
which
machine
well
that
one
on
everything
you
need
to
know
all
of
that
and
the
information
typically
exists
on
your
CI
environment?
The
problem
you
have
is
that
it's
scattered
in
so
many
different
places.
A
You
need
to
consolidate
all
of
that
and
send
the
information
that
matter
to
the
person
who
is
interested
by
that
and
do
not
send
them
information.
They
don't
care
about
so
typical
case
is.
You
can
actually
collect
information
about
tons
of
tests
collected
for
sense
of
time,
detect
to
run
collect
all
of
that
into
a
database
and
make
this
analysis
automatically.
You
only
send
to
the
people,
the
graph
that
have
a
big
drop
or
change.
You
don't
care
about
the
rest.
A
A
As
a
developer,
doing
something
in
my
code,
the
only
thing
I
really
care
about
is
in
fact
of
my
change
on
everything
else,
so
I.
If
I'm,
typically
working
on
a
low
level
stuff
that
typically
play
the
music
in
Spotify,
then
what
I
really
want
to
know
is
in
which
way
is
that
going
going
to
impact
anyone,
but
I
can
think
of
in
the
organization
and
the
rest?
A
I
really
don't
care
about,
but
I
do
care
about
that
and
I
want
the
system
to
not
send
me
any
information
that
is
not
related
to
my
change
and
I
want
to
attempt
to
send
me
all
information
related
to
my
change
on
everyone,
so
that
I
can
talk
to
them.
If
the
change
I
made
is
actually
necessary
but
break
their
their
own
features
and
not
talking
about
Delta's.
A
What
you
really
want
it
to
be
able
to
see
the
different
series
between
the
time
it
worked
and
the
time
it
doesn't
work.
The
only
thing
you
care
about
is
a
difference,
remove
everything
else
so,
for
instance,
test
coverage.
The
code
coverage
I,
don't
care
about
the
percentage
of
that.
What
I,
really
care
about
is
the
two
lines
that
got
covered
or
not
covered
by
your
test.
What
I,
really
care
about
is
a
code
that
has
changed
and
by
the
way,
the
code
you
just
modified
from
point
A
to
point
B.
Is
it
discovered?
A
A
So
you
can
reduce
dramatically
the
amount
of
of
information
that
you
send
to
people
by
just
collecting
only
what
matters,
for
instance,
even
logs,
look
at
all
the
logs
that
you
have
and
put
some
intelligence
in
that
and
try
to
find
what
does
change
only
what
has
change.
So,
basically,
you
do
something
like
that
point.
You
got
like
your
first
commit
yet
another
commit.
A
A
So
now
you've
collected
data
for
like
say
two
years,
you
have
a
lot
of
information
given
which
ticket
has
been
implemented,
which
way
in
which
part
of
the
code
which
test
broke,
what
preference
tests
got
impacted
by
what
change?
You
got
a
lot
of
things
into
this
database
that
can
help
you
do
a
few
things
which
really
make
a
very
big
difference
test
priorities.
A
If
you
got
a
big
code
base
on
this
time
to
run
those
tests
is
simply
impossible
for
every
commit.
If
you
make
I,
don't
know
few
thousands
commits
per
day,
and
you
got
test
run
for
a
few
hours
just
use
the
math
I
mean
we
have
hundreds
of
belt
agents,
but
it's
just
not
enough.
It
doesn't
scale,
and
but
what
you
can
do
is
you
can
make
correlations
between
when
this
team
touches
these
piece
of
code
most
likely.
Is
it
going
to
break
that
good?
A
You
can
do
that
right.
Just
statistics
don't
try
to
put
any
judgment
in.
That's
just
the
fact
of
life,
you
just
like
the
statistics
and
what
that
means
is
that
you
can
prior
prioritize
the
test.
You
want
first
orgies
the
tests
that
are
most
likely
going
to
break
and
believe
me,
you
can
reduce
by
a
factor
of
10
the
average
time
it
takes
to
find
your
regression
only
by
doing
this,
that
is
kind
of
useful.
A
So,
basically,
what
you
do
is
this:
you
do
the
exact
same
attitudes
that
we
add,
but
you
prioritize
those
tests
and
you
can
even
go
further
than
that.
If
you
simply
don't
have
time
to
run
those
tests,
because
because
physics,
you
don't
have
enough
cpu
cycles
to
do
that.
What
you
can
do
is
whenever
there
is
a
change
you
collect
all
the
stuff.
A
You
would
like
to
run
as
test
if
you
add
time
to
do
that
in
the
same
place-
and
you
put
all
this
bucket
with
all
the
stuff
that
would
be
so
nice
to
be
able
to
run
as
unit
tests,
for
instance,
that
you
can
prioritize
that
and-
and
you
will
prioritize
first,
the
latest
built.
So
if
you
have
one
builder
bronze
is
green,
you
don't
have
fine,
you
don't
have
time,
you
don't
have
time.
Okay,
now
you
have
time
to
run
it.
A
If
it
turns
green,
you
don't
care
about
the
ones
in
between
you
just
drop
them,
but
if
it's
red,
then
you
want
to
buy
psyche
immediately
and
then
you
know
exactly
which
commits
it
is
broken,
and
that
is
a
super
efficient
way.
It's
kels
super.
Well,
you
can
also
try
to
influence
your
developers
by
that
by
saying
I'm
going
to
prioritize
the
tests
that
are
faster
to
run.
So,
if
you
want
your
tests
to
be
run
often
make
them
fast
to
sing,
it
may
help.
A
And
again,
you
can
also
prioritize
the
tests
that
are
most
likely
going
to
fail
because
you
know
which
file
has
been
changed
and
when
you
change
that
file
it
break
that
code.
Statistically,
you
can
try
to
make
some
interesting
statistics
as
team
a
works
pretty.
Well,
they
push
a
lot
of
code.
Statistically
speaking,
you
know
that
Team
B
is
going
to
slow
down.
For
some
reason,
I
mean
it's
not
very
obvious,
sometimes
why
that
happens.
A
Sometimes
it's
plain
obvious,
because
you're
touching
something
which
is
core
and
the
other
one
gets
impacted
by
the
changes
that
sort
of
easy,
but
sometimes
it's
not
obvious
at
all.
Why
why
there
is
a
relation
between
those
teams,
but
as
management?
You
know
that
if
you
put
a
lot
of
pressure
on
one
part
of
the
company,
maybe
you're
going
to
slow
down
these
other
part
of
the
company
as
I
help.
You
predict
when
you
can
release
something.
A
Basically,
we're
talking
about
big
data,
we're
talking
about
analytics.
We
always
talk
about
analytics
when
it
comes
to
collecting
data
from
your
users.
A
you
forgot
someone
you
forgot
yourself.
Please
treat
yourself
as
a
source
of
big
data
that
will
help
you
basically
analyze
your
own
development
processes.
That
would
help
you
prioritize
what
needs
to
be
run
first.
That
would
help
you
understand
which
team
is
struggling
and
which
teams
get
impacted
by
everyone
else,
and
then,
basically,
you
can
improve
a
lot.
Your
velocity
I
would
like
to
say
thank
you.