►
From YouTube: Work Items Sync 2021-08-24
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
work
items
think
24th
of
august,
at
least
here
anyway,
cool.
That's
the
first
item,
it's
a
long
one,
but
I'll
try
and
stick
to
the
script.
So
I
want
to
advocate
for
the
position
that
we
would
finish
the
requirements
to
work
items
work
that
we're
currently
engaged
in
on
the
back
end,
whether
or
not
like
it's
the
right
like
product
decision.
A
I
think
that,
like
what
I've
noticed
over
the
last
couple
of
weeks
is
that
a
lot
of
the
rapid
actions
that
we're
taking
are
a
result
of
things
within
and
without
our
stage
that
have
been,
you
know
not
completely
finished
for
one
reason
or
another,
and
I'm
not
pointing
fingers
or
anything,
but
it
is
nevertheless
the
fact
that
some
of
these
are
unfinished
work
from
the
past,
and
I
think
we
should
kind
of
learn
from
these
things
and,
however
painful
it
is
like
stick
to
the
requirements,
migration
that
we've
already
started.
A
So
I've
listed
a
couple
of
possible
outcomes
if
we
were
to
switch
away
from
this
work-
and
I
don't
love
any
of
them
to
be
completely
honest.
Whatever
way
we
stop,
we
leave
technical
debt
in
there
and
like
to
put
perspective
around
this,
like
one
of
the
things
that
we've
been
cleaning
up
over
the
last
week
is
sub
transactions
and
a
large
part
of
that
came
from
the
user
mentions
work
that
alex
did
last
year.
A
That
wasn't
a
problem
at
the
time,
but
of
course
things
move
on
and
things
scale
up
and
they
become
a
problem,
and
I'm
worried
that
like
if
we
switch
off
of
requirements
to
work
items
now
we'll
leave
syncing
code
in
the
code
base.
That
is
fine.
Now,
like
I
mean
it's,
not
fine,
because
it
doesn't
do
anything
useful,
but
it's
not
a
scalability
issue
now,
but
it
is
more
likely
to
become
a
scalability
issue
before
we
get
back
to
actually
working
on
this
work.
A
If
history
is
any
kind
of
a
a
teacher
for
us,
so
yeah,
first
of
all,
any
questions
from
product
and
any
perspectives
that
I'm
missing
and
second
of
all,
when
I
mean
we're
in
a
three-month
headcount
reset.
I
have
three
on
my
team
that
I
can
dedicate
to
work.
A
A
We
know
that
we
need
to
sync
the
two
different
things
so
for
a
while
right,
we
need
to
have
like
requirements
as
an
object
on
their
own
and
requirements
as
a
work
item
type
and
for
a
period
of
time.
We
need
to
keep
them
in
sync,
and
this.
A
So,
in
other
words
like
if
I
create
a
requirement,
it's
going
to
also
create
a
requirement
work
item
type.
But
if
I
delete
that
requirement,
it
won't
delete
that
work,
item
type
and
so
like
it
makes
more
sense
to
the
to
merge
the
deletion
code
first
because
it
won't
do
anything
until
you
start
merging
that
so
it
maybe
looks
a
little
scarier
than
it
is
nevertheless
like.
A
This
is
a
classic
example
of
something
that
looks
completely
innocuous,
but
in
the
future,
like
it
causes
confusion
for
others,
because
if
we
stop
now
it's
like,
why
is
that
code
in
there
people
can't
reason
about
it.
They
see
it,
but
they
have
to
go
through
issues
to
find
context.
Maybe
they
never
find
that
context.
So
it's
scary
from
that
point
of
view.
C
Yeah
that
makes
sense
it's
like
all
the
context
is
kind
of
nested
and
nested
and
nested.
I
guess
yeah,
okay.
That
was
my
first
question
then
I
did
have
the
second
question.
That's
probably
more
important
but
yeah
we
mentioned,
like
you,
know,
making
it
modular
like
what
does
that
mean
in
terms
of
requirements?
Can
requirements
be
thought
of
as
like
any
object
in
the
future?
Is
that
going
to
be
flexible
in
that
way?
C
A
So
maybe
I
misunderstood
the
question
originally,
then,
the
the
work
that's
going
on
here
is
just
to
move
requirements
to
a
work
item
type.
Eventually,
we'll
have
to
do
this
for
everything.
That's
going
to
be
a
work
item
type
in
the
future
that
doesn't
already
exist
right
or
that
does
already
exist.
Sorry,
so
epics
will
have
to
be
migrated
as
well,
but
they'll
be
like
so
much
more
complex
because
there's
so
many
more
features
but
also
features
that
don't
exist
on
issues
yet
such
as
hierarchies.
A
So
the
reason
for
starting
with
requirements
was
they
were
the
lowest
risk
and
if
they're
the
lowest
risk
we
have,
we
can
with
the
most
chance
to
do
them
in
a
time
frame
that
we
can
predict,
and
then
we
can
learn
from
that
and
apply
that
to
epics,
while
solving
the
additional
product
problems
that
epics
bring
like.
A
Oh,
you
also
have
to
migrate,
start
and
end
dates,
which
you
also
have
to
like.
Maybe-
and
you
have
to
think
about
hierarchies
in
the
future.
You
also
have
the
problem
that
epics
are
at
the
group
level,
and
issues
are
currently
at
the
project
level,
so
yeah.
So
they're
a
little
more
more
complex,
so
we
chose
an
item
that
was,
you
know,
maybe
lower
value
but
but
simpler
and
less
risky.
C
Yeah
that
was
kind
of
what
I,
in
a
way
of
what
I
was
asking,
so
that
makes
sense
so,
like
whatever
we
do
here,
we
could
apply
that
to
the
other
items
it
would.
Those
items
are
just
more
complex,
so
we
would
have
to
still
have
some
learnings,
but
we
would
learn
a
lot
from
this
work
is
the
intention
right,
yeah.
A
Yeah
with
each
with
each
item,
we
migrate
we're
going
to
have
new
challenges,
but
it
makes
sense
to
do
like
the
lowest
common
denominator.
First,
which
is
requirements.
You
know
because
they're
just
basic
objects
like
title
description,
they
have
one
extra
little
piece
of
functionality
that
can
be
roughly
mapped
so
something
that
already
exists
on
issues,
which
is
the
satisfied
state.
You
know,
and
I
think
they
can
be
archived
instead
of
closed.
A
But
you
know
these
are
all
things
that
could
be
roughly
mapped
quite
easily
they're,
not
things
like
hierarchy,
which
requires
you
to
not
only
implement
that,
but
then
also
think
about
how
to
query
it.
You
know,
like
I
query,
deep
into
this
new
hierarchy,
which
are
really
just
a
hierarchy
of
issues
like
so
yeah.
C
E
Real
quick
because,
yes,
we
were
planning
on
migrating
requirements
to
issues
back
in
the
day,
because
we
wanted
to
link
them
to
test
cases
which
were
also
nationwide.
So
we
did
the
requirement
work.
Then
we
did
the
test
case
work
and
realized.
We
should
have
gone
with
nation
type
potentially
for
requirements,
so
the
intent
was
the
migrate
requirements,
donation
type
to
prepare
for
the
idea
of
a
future
option
to
have
them
all
synchronized,
which
we've
now
come
to
understand
as
work
items.
E
I
remember
having
conversations
back
a
year
ago
saying
if
we
couldn't
figure
out
how
to
migrate
requirements,
so
we're
never
going
to
figure
out
how
to
migrate
topics,
because
it's
so
much
simpler
and
the
idea
was.
We've
got
to
learn
how
to
do
this
at
some
point.
If
we
can't
figure
it
out
for
requirements,
then
we're
going
to
have
a
real
struggle
for
everything
else.
So,
hey!
Let's
pick
the
easiest
thing:
there
were
less
users,
there's
less
risk.
E
If
we
somehow
managed
to
delete
all
the
requirements
and
screw
them
up,
royally
it'd
be
a
much
simpler
job
to
rebuild
and
try
to
sort
that
out,
because
there's
just
so
many
less
of
them.
Now
as
we
move
forward,
there
are
now
more
than
there
used
to
be,
but
still
not
nearly
as
many
as
our
epic
species.
E
So
that's
sort
of
the
idea
behind
it
and
I'm
fine
with
getting
rid
of
the
archive
versus
clothes.
I'm
gonna
mention
charlie.
If
we
can't
carry
that
functionality
over
and
we
just
now
have
open
and
closed
requirements,
that's
fine
like,
but
we,
the
the
main
point
was
to
get
them
over
to
a
at.
The
point.
Issue
type
now
work
that.
F
Okay,
so,
just
to
summarize,
to
make
sure
I
understood
that
correctly,
it
sounds
like
this
requirements.
Migration
has
been
underway
for
a
while
right
before
we
all
started
talking
about
hey
what,
if
there's
this
reusable
thing
called
work
items
and
before
we
introduce
the
concept
of
a
feature
instead
of
epic,
this
work
has
been
happening
in
the
background.
H
Been
I
haven't
been
going
to
work
yeah,
I
I
mean
it's
on
my
team's
roadmap,
but
like
that
part
of
it
wasn't
clear
to
me.
The
whole
way
through
that,
like
like
the
30
percent
towards
the
certified
team
and
how
that
was
playing
out
in
terms
of
my
roadmap,
wasn't
clear
until
just
in
the
last
week
or
two
of
how
much.
B
B
If
I
could,
just
like,
we've,
been
working
on
extensible
issues
or
issue
types
for
over
a
year,
so,
like
that's,
where
you
know
like,
we
finally
got
everyone
aligned
around
work
items
and
we
decided
to
prioritize
feature
which
is
great
but
like
when
I
look
at
this.
It's
sort
of
like
migrating
requirements
is
a
really
natural
progression
to
feature
anyways,
because
we
have
to
do
the
work
items
table
effort
for
feature
right.
B
We
have
to
start
the
new
view
app,
which
we
want
to
have
with
title
description
and
assignee
for
mvc1
right
and
so
the
only
additional
work
we
would
need
to
do
other
than
the
the
actual
migration
was
the
test
reports
widget,
which
is
fairly
straightforward
and
something
we
should
be
able
to
do
and
then,
like
you,
have
parity
with
what
is
existing
requirements
and
they're
migrated.
And
it's
like
to
me
it's
sort
of
like
a
really
natural
progression
towards
the
feature
and
receipts
that
we
have
planned
out
already.
B
So
I
don't
know
if
that's
like
realistic
or
not,
but
we
can
then
continue
to
develop
the
rest
of
the
feature
and
all
the
other
widgets
behind
a
feature
flag,
but
we
can
also
release
and
finish
the
requirements.
Migration
work,
so
it's
not
tech,
debt
or
proc
debt,
or
just
like
basically
value
in
terms
of
unfinished
inventory.
That's
sitting
on
the
shelf
for
a
long
time.
A
Tacked
out
at
that
stage
like
if
we
stop
now
like
basically
because
well
I'll
already
have
to
do
a
handover
between
charlie
and
felipe
felipe
will
have
to
take
over
the
mr
that
charlie
has
in
progress
probably
like
if
it
doesn't
get
married
by
the
end
of
this
week.
Nevertheless,
they'll
have
to
be
a
hand
over
there
anyway,
if
we
close
that,
mr
we'll
basically
like
lose
the
knowledge
anyway,
somebody
else
will
have
to
ramp
up
her
or
charlie
when
she
comes
back
from
headquarters.
A
They'll
have
to
ramp
back
up
we're
going
to
lose
all
that
progress
and
we'd
still
have
this
code
in
in
the
code
base.
It's
it's
at
that
point,
technical
debt.
You
know,
and
we
can
say
we'll
come
back
to
it,
but
I
don't
know.
History
doesn't
really
say
that
we
will,
I
mean,
maybe
we
will
but
like
planning
anything
more
than
three
month
sites,
especially
in
a
company.
A
That's
like
agile,
like
this
is
as
good
as
as
good
as
I
guess
not
not
planning
to
come
back
to
it,
so
my
concern
would
be
like
if
we
do
that,
I
don't
see
why
we
can't
do
both
by
the
way
like
because
the
project
management
team
currently
are
working
on
parts
of
this.
A
H
How
much
time
I
think
I
have
that
in
three
one
like
what
is
the
time
frame
we're
talking
to
do
that
migration?
I
think
you
just
said
three
milestones,
and
and
do
we
feel
okay
still,
like
the
reason
why
we
were
saying
greenfield
was
so
that
we
could
do
it
without
an
impact
to
custer
customers
initially
because
they
weren't
relying
on
those
urls
or
those
the
issue
id
is
essentially
in
their
current
workflow.
Like
do
we
still
feel?
A
I
think
that
actually
we
were
planning
to
just
ghost
this
through
the
api
and
not
worry
about
the
front
end
at
all,
and
even
then
that's
like
you
could
argue,
that's
kind
of
tech
that,
but
we
were
okay
with
it
like,
because
just
we
reached
consensus,
I
think
that
that
was
where
we
wanted
to
go
with
it,
and
that
was
a
natural
break
point.
A
The
question
of
like
how
long
it's
going
to
take
has
just
radically
changed
for
me.
So
it's
kind
of
depends
on
that
that
last
question
that
I
put
in
there
as
well
like.
Where
do
you
see
our
capacity
going
over
the
next?
You
know
three
milestones.
While
you
know
two
members
of
the
team
or
two
fifths
of
the
team,
if
you
like,
are,
are
part
of
a
headcount
reset,
one
of
which
was
the
main
driver
of
like
if
you
like,
the
linearly
stacked
piece
of
the
part
of
this
work.
A
So
we
were
gonna,
get
these
three
we're
gonna
get
these
first,
mrs
out
of
the
way
that
was
all
dependent
work,
and
then
I
was
going
to
spread
it
out
amongst
the
team
that
we
could
maybe
get
this
completed
in
a
couple
of
milestones,
with
the
only
requirement
being
that
we
would
have
to
cross
a
milestone
bar
barrier
to
satisfy
the
the
requirement
that
self-hosting
customers
have
a
compatible
release,
but
like
it
goes
back,
basically
compatibility
is
guaranteed
one
release
by
back
right.
Does
that
make
sense?
A
So
if
you
kind
of
we
guarantee
that
one
minor
release
is
stable,
if
you
jump
multiple
minor
minor
releases,
we
don't
guarantee
that,
so
we
would
have
to
cross
a
milestone
barrier
anyway.
Now
two
of
the
team
are
part
of
the
reset,
including
one
member
of
the
team
who
was
primarily
working
on
it.
Another
member
of
the
team
was
heavily
involved
in
the
design
of
it,
and
so
there's
a
handover.
So
it
really
depends
on
how
much
capacity
we
have
to
give
to.
A
On
the
other
hand,
what
are
we
doing
with
this
reset,
but
trying
to
help
trying
to
pay
down
technical
debt
that
we've
left
in
the
past?
So
you
could
make
the
argument
that
we're
avoiding
long-term
reliability
problems
in
the
future
by
completing
this
work
now,
and
maybe
you
could
make
the
argument
that
we
counted
into
the
reliability
work
that
we're
doing
as
well.
I
don't
know
that's
not
my
choice,
though.
What.
E
The
three
months
I
thought
I
mean
my
understanding
and
then
I
realized
a
lot
is
shifting
right.
Now,
it's
probably
really
hard
to
get
a
very
tight
time
frame.
I
really
thought
it
was
less
than
three
months
worth
of
effort,
but
we
had
to
maintain
that
over
the
course
of
early,
so
it
was
more
like
a
couple
miles
of
effort,
but
we
had
to
keep
the
issue
open
across
the
release
boundary
which
would
just
be
to
clean
up
the
code.
E
That's
a
much
smaller
effort
to
remove
that
with
my
understanding
than
it
was
to
put
all
that
stuff
in
place.
So
I
don't
think
it's
three
months
exclusive
work
or
whatever
the
time
frame
ends
up
being
once
we
figure
out
the
head
company
said,
I
think
it
was
some
upfront
work,
a
pause
to
let
of
the
leads
go
out
and
then
back
in
work
to
pull
it
back
out.
It's
not
that
that
changes
a
lot.
I
just
want
to
make
sure
it's
clear
that
it's
not
like.
A
Right
yeah,
the
I
mean
the
there
should
be
no
visible
difference.
I
guess
for
users
for
the
most
part,
but
but
the
point
of
which
you
would
say,
like
there's,
no
further
risk
to
the
work
and
we're
simply
removing
stuff
yeah.
That
will
come
sooner
than
that.
What
I
see
is
the
whole
span
required
to
do
this
work.
A
If
that
makes
sense,
because
there
is
a
section
at
the
end
where
we
have
to
like
we've
had
the
sinking
going
on
for
a
while,
then
we
do
the
migration
of
existing
requirements
we
migrate
over
over
and
then
we
clear
out
the
stuff
that
we
left
behind,
but
that
part
at
the
end
doesn't
really
like
it
has
to
be
done,
but
it's
kind
of
removing
stuff,
that's
no
longer
being
used
so
yeah.
You
could
say
that
we're
done
done
at
the
end
of
that,
but
we're
like
done
with
the
risk
like
before
that.
H
Could
we
get
that
translated
over
into
the
main
level?
Epic?
I
can
see
there's
a
lot
of
requirements
linking
test
cases
is
in
there
now,
but
just
the
plan
of
attack.
So
we
can
update
sort
of
the
summary
and
make
sure
that
that's
clear
that
we're
all
on
the
same
page
for
amount
of
time
and
then
and
then
the
order
of
operations
for
requirements
and
how
that
rolls
into
features.
F
John,
as
for
your
question
about
capacity
right
and
how
much
we
allocate
to
reliability
are
the
main
way
that
we're
measuring
that
is
through
air
budgets
right.
So,
if
our
air
budgets
are
green
right
and
we
don't
know
of
any
outstanding
technical
network,
I
think
it's
good
to
it
to
work
items,
because
that
in
itself
is
technical
debt.
In
a
way
I
looked
at
product
planning
and
that
looked
okay.
F
E
A
Actually
so
a
couple
of
points,
the
aptx
requirement
was
raised
to
five
seconds
I
believe
this
morning,
but
it
might
have
been
yesterday.
Maybe
I
missed
it.
I
don't
know
that
in
itself
I
think
completely
mended
the
product
planning
error
budget,
so
it
looks
green
now
it
might
not
have
been
yesterday
on
friday.
The
second
thing
is
certify,
went
red
and
that's
because
a
job
that
was
failing
the
process
requirements
job
was
previously
not
counted
in
the
error
budget,
and
I
is
I'm
not
sure
why
I
didn't
look
too
far
into
it.
A
So
yeah
a
lot
a
lot
to
change
in
in
error
budgets,
but
look.
We
know
why
the
product
planning
our
budget
was
low
in
the
first
place
and
the
main
reason
I
guess,
was
disc.
Well,
there
were
two
discussions
being
slow,
which
is
true
of
all
stages,
that
use
discussions
or
all
groups,
and
we
had
a
lot
of
500s.
A
I
suppose
relative
to
certain
things,
we've
already
been
tackling
some
of
those
and
they're
very,
very
small,
very
simple
issues.
So
you
know
okay,
it's
green.
Now,
like
that's,
possibly
because
of
the
aptx
change.
I
would
be
surprised
if
it
was
to
be
honest:
it
doesn't
mean
that.
E
Right
do
we
have
the
fix
in
photography
also,
because
I
know
that's
why
the
giggly
one
was
very
sorry.
The
certified
one
was
kind
of
a
mess
to
start
with,
because
and
john
does
the
technologies
behind
it,
but
basically
because
we
went
full
graphql
on
requirements
when
we
initially
made
them
a
lot
of
the
stuff.
Isn't
cracked
correctly
there's
no
way
to
get
the
a
lot
of
the
summary.
In
my
understanding,
you
know
for
the
air
budget
to
graph
ql
nationally,
and
I
know
it's
in
progress.
E
I
don't
know
where
that
is
who
owns
that.
So
the
certified
air
budget
is
artificially
low
because
of
that
now
it
sounds
like
it's
not
red
for
other
reasons,
but
just
as
an
fyi
to
certify
everybody's,
it's
not
really
the
best
place
to
look
for
reliable.
You
know
issues.
A
Yeah,
that's
exactly
right
and
the
the
simplest
way
I
could
describe
it
would
be
like
if
you
go
through
the
rest
api
and
you
want
to
list
your
requirements.
If
we
had
a
rest
api
for
those
it,
it
would
be
very
simple
for
us
to
track
that
request.
It's
a
request
to
the
endpoint
the
list
requirements.
The
problem
with
the
graphql
api
is
that
it's
completely
permissive.
It
lets
you
do
anything
pretty
much.
A
So
it's
an
object
graph
and
you
could
ask
for
give
me
all
requirements
associated
with
this
thing
and
only
return
the
name
of
the
requirement
or
only
return
the
status.
The
point
is,
the
number
of
possibilities
are
so
huge
that
we
can't
possibly
track
that
amount
of
cardinality
and
so
we're
doing
like
little
hacks
and
stuff
by
tracking
the
operation
name
and
things
like
that
in
cabana,
but
it's
nothing
that
we
can
put
in
our
grafana
charts
yet.
But
there
is
some
kind
of
solution
ongoing
to
to
figure
that
out,
I'm
just
not
across
them.
F
Okay,
are
there
issues
that
track
this?
These
can
y'all
make
them.
B
I
was
just
answering
the
question.
I
think
it's
gonna
change
it
quite
a
bit
the
top
five
most
defensive,
endpoints
or
requests
all
have
to
do
with
projects.
I'm
not
sure
what
the
root
controller
is.
I
think
asks
you
with
projects
too-
maybe
maybe
not,
but
right
now
the
air
budget's
at
99.58,
which
is
way
higher
than
it's
been
in
the
past.
B
So
I
think,
couple
weeks
ago
it
was
like
at
98.3
or
something
absurd,
so
yeah
it'll
be
interesting
to
see
what's
happening
and
then
we're
already
working
on
basically
issue
search
or
what
will
be
the
future
work
item,
search
because
that's
the
other
area
we're
actually
having
real
customer
problems
and
impact
because
they
can't
search
issue
lists
or
boards
in
a
performant
way
without
timing
out
at
scale.
So
heinrich's
working
on
that
as
we
speak,
but
it's
good.
B
F
This,
I
think
it
sounds
like
we
still
need
to
dedicate
capacity
to
reliability
like
in
instrumentation
for
certified
in
the
issues
that
we
know
of
like
search
and
discussions
right.
So
I
think
continuing
to
focus
on
that
makes
sense,
and
I
think
it
means
that
we
have
to
focus
on
requirements
and
sas
reliability,
but
I'll
defer
to
engineering
to.
Let
us
know
like
how
how
much
capacity
we
have
and
if
there's
anything
left
after
working
on
these
two
things.
A
A
It
is
a
fudge
because
we
don't
know
how
slow
or
fast
graphql
is,
but
we
should
just,
I
think,
for
now
treat
that
as
an
unknown
and
fix
the
thing
we
can
see,
and
it's
just
one
thing.
C
Kristin
I
was
gonna
say
I
think
I
want
to
talk
about
like
ideation
around
requirements,
but
I
think
we
can
just
move
on
to
three
right
now
in
our
like
two
seconds
left,
because
I
think
it's
more
important
sure
thank
you
and
maybe.
H
We
could
do
yours
offline
here
as
well.
This
we
may
not
know,
but
I
noticed,
or
it
was
said
that
the
move
from
or
to
bring
projects
and
groups
together,
we
would
reduce
30
of
our
code
base
when
those
two
come
together.
H
Could
we
get
a
number
like
that
on
epics
getting
onto
work
items
as
well
as
requirements,
either
a
number
of
files
percentage
of
code
base
number
of
lines
of
code,
something
where
we
could
at
least
say
this
effort
that
we're
going
to
do
from
an
engineering
standpoint
is
going
to
participate
this
much
in
completing
or
getting
rid
of
some
tech,
debt
and
overhead
I'm
going
to
do
it
in
terms
of
backlog
percentage
and
all
these
issues
and
epics
I'll
be
able
to
close
on
when
we
have
work
items,
but
that's
just
a
question:
I'm
throwing
out
there.
A
And
I'm
not
sure
it's
I'm
not
sure
it's
that
useful.
A
number
like
it
might
be
deceptively
like
not
useful,
like
it
might
appear
useful,
but.
A
It's
not
it's
not
those
two
files,
it's
not
that
it
would
be
small.
It's
just
that,
like
is
maintaining
one
work
item,
finder
really
easier
than
maintaining
like
an
epics
finder,
an
issue
finder,
you
know,
and
ever
you
know
and
everything
else
like
in
some
ways.
Yes,
it
is
in
other
ways
it's
much
harder,
because
you
know
you
have
to
work
with
one
thing:
that's
much
more
complex
so,
like
I'm
just
saying
that
lines
of
code
generally
might
be
deceptive,
but
the
in
answer
to
your
question:
could
we
estimate
it
yeah?
H
D
E
I
think
we
just
have
to
be
careful,
though,
because
we've
in
the
past
said
smok
is
the
driver
and
if
you
remove,
you
know
30
000
lines
of
code.
You've
made
your
product
better
and
I
think
there's
something
to
be
noted
here
and
taken
out
of
more
regulated
industry
is
that
what
you're
shooting
for
is
not
low
slot
you're
shooting
for
a
low
complexity
value
that
has
always
been
the
path
forward
for
reliability.
E
H
E
F
I
think
the
essence
of
what
kristin
is
bringing
up
is
important,
though
that,
especially
in
today,
right
like
where
we
are
as
a
company
and
that
we're
saying
we're
attacking
tech,
debt
and
complexity
and
making
our
code
base
more
sustainable.
It
is
important
to
find
a
way
to
quantify
how
work
items
contributes
to
that
great.
G
F
F
E
Yeah-
and
we
can-
I
mean
I'm
happy
to
talk
about
this
in
nazim.
I
was
I've
done
this
for
years,
but
yeah
code
complexity
is
the
way
forward
on
that.
If
you
want
to
talk-
and
I
think
most
people
agree-
if
we
can
show
that
our
code
complexity,
numbers
are
decreasing
because
of
changes,
we're
making
that
can
be
breaking
up
functions
in
the
multiple
smaller
pieces
that
are
easier
to
maintain,
there's
hundreds
of
ways
to
do
that
across
the
board.
The
problem
is
oftentimes
complexity
and
reduction.
E
Complexity,
increases
time,
reduction
in
time
or
increases
in
efficiency,
reduce
your
complexity.
So
it's
this
balancing
act.
You
have
to
come
to
as
a
company
and
it's
hard
to
translate
that
to
senior
levels
because
oftentimes
they
see
it
as
one
or
the
other,
and
the
reality
is
the
balance
of
the
two.
If
you
want
performance
code,
you
have
to
increase
complexity,
oftentimes
and
where
do
you
draw?
E
A
Yeah-
and
I
agree
if
we're
going
to
put
effort
into
something
like
we
should
be
able
able
to
measure
the
outcome
like
and
I
know
in
the
front
end:
they
have
this
like
concept
of
tree
shaking
for
css,
so
they
can
see
which
css
classes
never
get
called,
and
then
they
can
just
remove
those.
I'm
not
sure
we
have
anything
comparable
on
the
back
end,
but
it'd
be
really
nice
to
see
like
what's
in
our
code
base,
that
never
is
in
the
critical
code
path
like.
Can
we
just
get
rid
of
it
then
like?
A
If
it's
never
used?
I
don't
know
if
we
have
tools
for
that,
it
would
be
hard
to
estimate,
but
it
would
certainly
be
it's.
You
can
quite
easily
these
days
measure
cyclomatic
complexity
and
things
like
that.
We
have
the
tools
for
it.
Just
can't
really
estimate
it.
Like
I
mean
I
wouldn't
know
where
to
start
saying
like
hi,
could
we
reduce
that?
Like
I,
I
mean,
I
know
how
we
could
reduce
it,
just
not
how
we
could
estimate
how
much
we
would
remove.
H
In
this
conversation
too,
like
whether
or
not
we
say
a
number
like
that
for
me
to
just
know-
hey
we're
going
to
remove,
like
this
whole
epic
folder
in
the
code
base
and
but
we're
going
to
have
to
add
this
much
complexity
into
the
main
controller
or
whatever.
Because
of
that,
so
it's
not
necessary.
It
might
be
a
trade-off
situation,
but
I
just
like
would
like
to
be
sort
of
aware
of
what
those
are
like
the
amounts
and
the
complexity
added.
F
I
think
we're
over
time,
so
maybe
this
can
be
a
homework
assignment
for
each
of
us
to
think
of
a
way
that
we
would
like
to
measure
this.
I
think
kristin,
your
idea
to
measure
the
backlog
reduction
is
really
good
and
maybe
there's
other
ways
in
which
we
can
measure
the
engineering
side
of
things.