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