Killing Zombie Software - Technology Exit Planning


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
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Killing Zombie Software - Technology Exit Planning

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