Killing Zombie Software - Technology Exit Planning

  • 2,755 views
Uploaded 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 …

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.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
2,755
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
32
Comments
4
Likes
14

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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