KILLING ZOMBIE
SOFTWARE
please design software to
die gracefully
http://www.flickr.com/photos/scottpoborsa/
PART ONE
WELCOME TO THE
ZOMBIE
APOCALYPSE
whether you work in a
mega MNC or a sexy lean
start-up
today’s software
professional is at the
heart of a zombie
apocalypse.
for the last 30 years,
we’ve learned how to
build more stuff, faster
but we’ve spent very
little time learning how
to get rid of it.
the result is platform
sprawl
with software products
and features that are
long dead, but which still
walk the earth
“grawwww”
this is not sustainable.
if we don’t act now, the
zombies will win
this deck hopes to start a
discussion about how we
escape the apocalypse
and kill all those software
zombies!
IDEA ONE
ALL SOFTWARE
NEEDS TO DIE
here is a law of nature.
all software needs to die.
either the business needs
will change
or newer technologies
will arise
either way, all software
will eventually become
obsolete.
(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
on...
so, knowing this
one thing is clear
we need a graceful way
to get rid of obsoleting
software.
IDEA TWO
IT IS HARD TO KILL
SOFTWARE
unfortunately, shuffling
off this mortal code is not
so easy.
killing software can be
near impossible.
there are technical
reasons for why this is
true.
for example, in complex
platforms where many
bits of software interact
upstream, downstream,
and service to service
changing one piece can
have profound impact
across the sprawl.
decoupling a dying
technology can become a
feat of engineering
like a mad game of jenga.
and there are people
reasons too.
killing software can easily
look like (or actually be)
killing jobs.
newer business flows or
gadgetry render existing
personal skill sets
obsolete.
making way for the new
is scary and/or
threatening to the people
that own it.
moreover, there are
budgetary reasons
supporting all this legacy
software is extremely
expensive.
we spend so much
keeping the platform
afloat, that we’ve
nothing left to dig
ourselves out of the hole
we’re in.
(today some firms spend 60-
70% of their IT budget
maintaining the existing
platform)
IDEA THREE
IT IS EASY TO
MAKE NEW
SOFTWARE
worse yet, not only are
we not killing software,
but we’ve just enjoyed 30
years of high-speed
build-out.
so for every 1 zombie we
failed to kill, 9 more
future zombies arose.
in the growing
economies from 1980 to
2008, businesses simply
threw money at the
platform.
the mantra was build,
build, build!!!!
and where we could not
grow organically
we merged, and we
acquired
adding duplicative
software on top of
duplicative software.
as a result
organizations today are
living with massive and
intractable platform
sprawls
made up of dozens,
hundreds, and in many
cases thousands of
vestigial bits of software
of which, perhaps, 30% is
actually needed
which means that 70% of
our software is
ZOMBIE SOFTWARE!!!!!!
IDEA FOUR
ZOMBIES SUCK
zombie software eats you
alive, starting with the
brain
since only 30% of your
budget can be spent on
Innovation
PS: In many firms, ¾ of that 30% is spent meeting
regulatory enha...
not much innovation
actually happens
and even the innovation
that can happen
is burdened with the
huge technical barrier to
entry
of integrating with the
legacy platform from
birth
and who wants to work
in a neighbourhood full
of zombies
in today’s zombie sprawl
your best, most highly-
paid geek superstars will
be as bored as sh*t
finally, all this vestigial
technology creates great
complexity
and complexity means
greater risk of failure
and longer times
diagnosing and
recovering from failure
which means bigger
support organizations
which means less money
to innovate
which means life sucks
PART TWO
HOW TO KILL
ZOMBIE
SOFTWARE
when you think of it this
way
zombie killing looks to be
one of the most
important core skills of
today’s technologist
but what weapons can
you wield
as a master zombie slayer
i’m proposing 5 weapons
but I welcome feedback
from the crowd if you
have creative ideas
WEAPON ONE
Admit that you
have a Problem
the first thing you
need to do is to
quantify how bad
things are
because otherwise,
the budget holders
will continue to ignore
you.
knowing how bad
things are means
cleaning up your
application inventory
so that you really
know how much
you’ve got, and how
much it costs.
I know
MIS data cleaning is
really, really, really,
really, really, really,
really, really, really,
boring work
but if you want to be a
master zombie slayer,
it’s part of the job
come to terms with
spreadsheets
make them your
friends
most importantly, stop
sniping and take small,
steady steps.
once you know how
bad your problem is
it’s time to budget for
resolution
this means business
cases, time/cost/benefit
estimates, lobbying,
negotiation, and
prioritization
but remember
technology is the one
that said it wanted to
think like the business
so here is your chance
get involved with your
business partners
and start solving this
business problem
WEAPON TWO
Design for
Deprecation
most software
development life cycle
plans
look a lot like the Iraq
War
no exit plan.
with no exit plan
it’s no wonder that we
cannot kill zombie
software.
while it is probably fair
for developers in the
trenches
to leave the high-level
platform strategy to
power-point-pushers
it is our responsibility
to make the right
strategic decisions with
day-to-day code
and that means
designing exit plans
into your code.
my advice is to add a
project checkpoint into
your development
process.
before you deploy your
code into the platform
make sure you have
built in the means to
deprecate it gracefully
better yet, add a
chapter to your
business requirements
document
and work through the
exit plan with the
business
and if you are one of
them new fangled,
fancy, agile punks
then explicitly build exit
into your scrum
WEAPON THREE
Encapsulate
one of the most
important design-for-
deprecation tools is
encapsulation
you remember that
thing the prof in object-
oriented design 101
kept going on about
encapsulation means
that you create air-tight
black boxes with clear
fully-functional
interfaces
when you want to
replace a black box, it is
easy because nothing
in the surrounding
platform cares about
what is inside
because they never
knew what was inside
in the first place
so long as you
implement the original
interface, you can kill
off the original code
and replace it without
disruption.
add to that the driver
design pattern, and
we’re ready to roll on a
zombie-slaying
expedition.
and encapsulation
works at every level of
zoom, like a fractal
it works for
functions, objects,
applications, services,
hardware, networks,
business units (think
outsourcing), or whatev...
all that said, my point is
this
as a matter of
professional pride,
don’t allow your code
to go into production
without encapsulation
WEAPON FOUR
Know Your Enemy
Ok, so I get that when
you push your
software into the wild
things get squishy
for example, other
software grabs your
output, reformats it
and sends it out as
input into something
else.repeat()
and you quickly lose
track of who depends
on you
now I am not saying I
have a perfect
answer, but a master
zombie slayer will
work it out for their
project
if latency is not an
issue, log third party
requests so you know
who to notify when
you need to exit
this could even be
done manually with a
register owned and
managed by the
application owner
whatever the case, a
master zombie slayer
will make sure that
she does not
contribute to
platform spaghetti
WEAPON FIVE
Nuke and Restart
we invest too much
of our emotion and
identity into our
things
it is a human
biological fixed action
pattern to fall pray to
the fallacy of sunk
costs
what I am trying to
say is, don’t be afraid
to rip it all down and
start again
we don’t do that
enough with our
platforms
we fix and mend
and fix and mend
until all that is left
is…well…a zombie
i am not actually
proposing build for
the sake of build
but I am saying that
we don’t consider the
option enough
and that starting
from scratch is often
a cheaper, better
option
certainly, anyone who
has used the
minimum viable
product model
knows that version 1
is necessarily wrong
and that version 2 should
be designed from the
ground up or it will be
forever tied to the faulty
assumptions you
uncovere...
anyway, just seriously
consider the option from
time to time so you know
you are not throwing
good money after bad
PART THREE
OUT
if you’ve gotten this
far
wow!
but don’t stop here
please join me in the
discussion
give me your ideas on
new weaponry
i’ll add it to this deck
and we can build
something really
useful
SHARE THIS DECK
& FOLLOW ME(please-oh-please-oh-please-oh-please)
stay up to date with my future
slideshare posts
http://w...
CLICK HERE FOR MORE!!!!
Upcoming SlideShare
Loading in …5
×

Killing Zombie Software - Technology Exit Planning

2,905
-1

Published on

Whether you are a big, sprawling MNC or a sleak, sexy start-up, zombie software will quickly invade your product platform. This deck is meant to start a conversation on how our industry can fight the zombies.

Published in: Software, Technology, Business
4 Comments
15 Likes
Statistics
Notes
No Downloads
Views
Total Views
2,905
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
34
Comments
4
Likes
15
Embeds 0
No embeds

No notes for slide

Killing Zombie Software - Technology Exit Planning

  1. KILLING ZOMBIE SOFTWARE please design software to die gracefully http://www.flickr.com/photos/scottpoborsa/
  2. PART ONE WELCOME TO THE ZOMBIE APOCALYPSE
  3. whether you work in a mega MNC or a sexy lean start-up
  4. today’s software professional is at the heart of a zombie apocalypse.
  5. for the last 30 years, we’ve learned how to build more stuff, faster
  6. but we’ve spent very little time learning how to get rid of it.
  7. the result is platform sprawl
  8. with software products and features that are long dead, but which still walk the earth
  9. “grawwww”
  10. this is not sustainable.
  11. if we don’t act now, the zombies will win
  12. this deck hopes to start a discussion about how we escape the apocalypse and kill all those software zombies!
  13. IDEA ONE ALL SOFTWARE NEEDS TO DIE
  14. here is a law of nature.
  15. all software needs to die.
  16. either the business needs will change
  17. or newer technologies will arise
  18. either way, all software will eventually become obsolete.
  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)
  20. so, knowing this
  21. one thing is clear
  22. we need a graceful way to get rid of obsoleting software.
  23. IDEA TWO IT IS HARD TO KILL SOFTWARE
  24. unfortunately, shuffling off this mortal code is not so easy.
  25. killing software can be near impossible.
  26. there are technical reasons for why this is true.
  27. for example, in complex platforms where many bits of software interact upstream, downstream, and service to service
  28. changing one piece can have profound impact across the sprawl.
  29. decoupling a dying technology can become a feat of engineering
  30. like a mad game of jenga.
  31. and there are people reasons too.
  32. killing software can easily look like (or actually be) killing jobs.
  33. newer business flows or gadgetry render existing personal skill sets obsolete.
  34. making way for the new is scary and/or threatening to the people that own it.
  35. moreover, there are budgetary reasons
  36. supporting all this legacy software is extremely expensive.
  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)
  39. IDEA THREE IT IS EASY TO MAKE NEW SOFTWARE
  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.
  42. in the growing economies from 1980 to 2008, businesses simply threw money at the platform.
  43. the mantra was build, build, build!!!!
  44. and where we could not grow organically
  45. we merged, and we acquired
  46. adding duplicative software on top of duplicative software.
  47. as a result
  48. organizations today are living with massive and intractable platform sprawls
  49. made up of dozens, hundreds, and in many cases thousands of vestigial bits of software
  50. of which, perhaps, 30% is actually needed
  51. which means that 70% of our software is
  52. ZOMBIE SOFTWARE!!!!!!
  53. IDEA FOUR ZOMBIES SUCK
  54. zombie software eats you alive, starting with the brain
  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
  56. not much innovation actually happens
  57. and even the innovation that can happen
  58. is burdened with the huge technical barrier to entry
  59. of integrating with the legacy platform from birth
  60. and who wants to work in a neighbourhood full of zombies
  61. in today’s zombie sprawl
  62. your best, most highly- paid geek superstars will be as bored as sh*t
  63. finally, all this vestigial technology creates great complexity
  64. and complexity means greater risk of failure
  65. and longer times diagnosing and recovering from failure
  66. which means bigger support organizations
  67. which means less money to innovate
  68. which means life sucks
  69. PART TWO HOW TO KILL ZOMBIE SOFTWARE
  70. when you think of it this way
  71. zombie killing looks to be one of the most important core skills of today’s technologist
  72. but what weapons can you wield
  73. as a master zombie slayer
  74. i’m proposing 5 weapons
  75. but I welcome feedback from the crowd if you have creative ideas
  76. WEAPON ONE Admit that you have a Problem
  77. the first thing you need to do is to quantify how bad things are
  78. because otherwise, the budget holders will continue to ignore you.
  79. knowing how bad things are means
  80. cleaning up your application inventory
  81. so that you really know how much you’ve got, and how much it costs.
  82. I know
  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
  85. come to terms with spreadsheets
  86. make them your friends
  87. most importantly, stop sniping and take small, steady steps.
  88. once you know how bad your problem is
  89. it’s time to budget for resolution
  90. this means business cases, time/cost/benefit estimates, lobbying, negotiation, and prioritization
  91. but remember
  92. technology is the one that said it wanted to think like the business
  93. so here is your chance
  94. get involved with your business partners
  95. and start solving this business problem
  96. WEAPON TWO Design for Deprecation
  97. most software development life cycle plans
  98. look a lot like the Iraq War
  99. no exit plan.
  100. with no exit plan
  101. it’s no wonder that we cannot kill zombie software.
  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
  105. and that means designing exit plans into your code.
  106. my advice is to add a project checkpoint into your development process.
  107. before you deploy your code into the platform
  108. make sure you have built in the means to deprecate it gracefully
  109. better yet, add a chapter to your business requirements document
  110. and work through the exit plan with the business
  111. and if you are one of them new fangled, fancy, agile punks
  112. then explicitly build exit into your scrum
  113. WEAPON THREE Encapsulate
  114. one of the most important design-for- deprecation tools is encapsulation
  115. you remember that thing the prof in object- oriented design 101 kept going on about
  116. encapsulation means that you create air-tight black boxes with clear fully-functional interfaces
  117. when you want to replace a black box, it is easy because nothing in the surrounding platform cares about what is inside
  118. because they never knew what was inside in the first place
  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.
  121. and encapsulation works at every level of zoom, like a fractal
  122. it works for functions, objects, applications, services, hardware, networks, business units (think outsourcing), or whatever
  123. all that said, my point is this
  124. as a matter of professional pride, don’t allow your code to go into production without encapsulation
  125. WEAPON FOUR Know Your Enemy
  126. Ok, so I get that when you push your software into the wild things get squishy
  127. for example, other software grabs your output, reformats it and sends it out as input into something else.repeat()
  128. and you quickly lose track of who depends on you
  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
  133. WEAPON FIVE Nuke and Restart
  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
  137. we don’t do that enough with our platforms
  138. we fix and mend
  139. and fix and mend
  140. until all that is left is…well…a zombie
  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
  143. and that starting from scratch is often a cheaper, better option
  144. certainly, anyone who has used the minimum viable product model
  145. knows that version 1 is necessarily wrong
  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
  147. anyway, just seriously consider the option from time to time so you know you are not throwing good money after bad
  148. PART THREE OUT
  149. if you’ve gotten this far
  150. wow!
  151. but don’t stop here
  152. please join me in the discussion
  153. give me your ideas on new weaponry
  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
  156. CLICK HERE FOR MORE!!!!
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×