Killing Zombie Software - Technology Exit Planning
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


Killing Zombie Software - Technology Exit Planning



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

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.



Total Views
Views on SlideShare
Embed Views



4 Embeds 15 6 4 3 2


Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Killing Zombie Software - Technology Exit Planning Presentation Transcript

  • 1. KILLING ZOMBIE SOFTWARE please design software to die gracefully
  • 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!
  • 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.
  • 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)
  • 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!!!!!!
  • 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
  • 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
  • 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
  • 156. CLICK HERE FOR MORE!!!!