More Related Content Similar to Killing Zombie Software - Technology Exit Planning (20) More from Eric Tachibana (20) Killing Zombie Software - Technology Exit Planning5. for the last 30 years,
we’ve learned how to
build more stuff, faster
12. this deck hopes to start a
discussion about how we
escape the apocalypse
and kill all those software
zombies!
19. (and when I say eventually,
given biz / innovation speed, I
mean 3-5 years for a big firm
and 6 – 12 months for a small
one)
22. we need a graceful way
to get rid of obsoleting
software.
27. for example, in complex
platforms where many
bits of software interact
upstream, downstream,
and service to service
34. making way for the new
is scary and/or
threatening to the people
that own it.
37. we spend so much
keeping the platform
afloat, that we’ve
nothing left to dig
ourselves out of the hole
we’re in.
38. (today some firms spend 60-
70% of their IT budget
maintaining the existing
platform)
40. worse yet, not only are
we not killing software,
but we’ve just enjoyed 30
years of high-speed
build-out.
41. so for every 1 zombie we
failed to kill, 9 more
future zombies arose.
49. made up of dozens,
hundreds, and in many
cases thousands of
vestigial bits of software
55. since only 30% of your
budget can be spent on
Innovation
PS: In many firms, ¾ of that 30% is spent meeting
regulatory enhancements, not really innovation
75. but I welcome feedback
from the crowd if you
have creative ideas
81. so that you really
know how much
you’ve got, and how
much it costs.
83. MIS data cleaning is
really, really, really,
really, really, really,
really, really, really,
boring work
84. but if you want to be a
master zombie slayer,
it’s part of the job
102. while it is probably fair
for developers in the
trenches
103. to leave the high-level
platform strategy to
power-point-pushers
104. it is our responsibility
to make the right
strategic decisions with
day-to-day code
106. my advice is to add a
project checkpoint into
your development
process.
108. make sure you have
built in the means to
deprecate it gracefully
111. and if you are one of
them new fangled,
fancy, agile punks
114. one of the most
important design-for-
deprecation tools is
encapsulation
117. when you want to
replace a black box, it is
easy because nothing
in the surrounding
platform cares about
what is inside
119. so long as you
implement the original
interface, you can kill
off the original code
and replace it without
disruption.
120. add to that the driver
design pattern, and
we’re ready to roll on a
zombie-slaying
expedition.
122. it works for
functions, objects,
applications, services,
hardware, networks,
business units (think
outsourcing), or whatever
124. as a matter of
professional pride,
don’t allow your code
to go into production
without encapsulation
126. Ok, so I get that when
you push your
software into the wild
things get squishy
129. now I am not saying I
have a perfect
answer, but a master
zombie slayer will
work it out for their
project
130. if latency is not an
issue, log third party
requests so you know
who to notify when
you need to exit
131. this could even be
done manually with a
register owned and
managed by the
application owner
132. whatever the case, a
master zombie slayer
will make sure that
she does not
contribute to
platform spaghetti
134. we invest too much
of our emotion and
identity into our
things
135. it is a human
biological fixed action
pattern to fall pray to
the fallacy of sunk
costs
136. what I am trying to
say is, don’t be afraid
to rip it all down and
start again
141. i am not actually
proposing build for
the sake of build
142. but I am saying that
we don’t consider the
option enough
146. and that version 2 should
be designed from the
ground up or it will be
forever tied to the faulty
assumptions you
uncovered in the MVP
154. i’ll add it to this deck
and we can build
something really
useful
155. SHARE THIS DECK
& FOLLOW ME(please-oh-please-oh-please-oh-please)
stay up to date with my future
slideshare posts
http://www.slideshare.net/selenasol/presentations
https://twitter.com/eric_tachibana
http://www.linkedin.com/pub/eric-tachibana/0/33/b53