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.

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!!!!