Post on 27-Aug-2014
description
transcript
KILLING ZOMBIE SOFTWARE
please design software to die gracefully
http://www.flickr.com/photos/scottpoborsa/
PART ONEWELCOME 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 ONEALL 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
one)
so, knowing this
one thing is clear
we need a graceful way to get rid of obsoleting
software.
IDEA TWOIT 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 THREEIT 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 FOURZOMBIES 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 enhancements, not really innovation
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 TWOHOW 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 ONEAdmit 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 TWODesign 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 THREEEncapsulate
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 forfunctions, objects,
applications, services, hardware, networks, business units (think
outsourcing), or whatever
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 FOURKnow 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 FIVENuke 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
uncovered in the MVP
anyway, just seriously consider the option from time to time so you know
you are not throwing good money after bad
PART THREEOUT
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://www.slideshare.net/selenasol/presentationshttps://twitter.com/eric_tachibana
http://www.linkedin.com/pub/eric-tachibana/0/33/b53
CLICK HERE FOR MORE!!!!