No content

Who? • David Salgado • @digitalronin (twitter, github, stackoverflow) • CTO, Tech co-founder, lead dev. etc. • Technical Architect @ Ministry of Justice 

I've done some rewrites Apologise in advance: presentation is a random walk rewrites touch on lots of different areas, & so does this talk 

What is a ‘rewrite’? 

Decide to replace
 a working system
 with one that is equivalent
 but different Let's unpack that 

Decide to replace
 a working system
 with one that is equivalent
 but different Not like you ended up replacing every line of code during normal development 

Decide to replace
 a working system
 with one that is equivalent
 but different If it's not working, you're fixing, not rewriting 

Decide to replace
 a working system
 with one that is equivalent
 but different If it's not equivalent, you're developing, not rewriting 

Decide to replace
 a working system
 with one that is equivalent
 but different If it's not different, you've just run "cp -r" 

Why? • “This code sucks” • “We should use #{shiny_new_tech}” • “This design/architecture sucks” • (aka “because micro-services”) Usually (not always) it's the developers who are pushing the rewrite There is a big problem with all of these arguments 

– Dan Milstein “Developers tend to spectacularly underestimate the effort involved...and spectacularly overestimate the value generated” Remember, we're talking about replacing a working system - so, the current code is generating value for the business Let's look at this idea a bit more closely 

This is what your
 product owner hears 

This is what your
 product owner hears “We want to spend a huge amount of effort
 (aka money), and deliver no benefit” If you've got a smart product owner, they might hear... 

This is what your
 product owner hears “We want to spend a huge amount of effort
 (aka money), and deliver no immediate benefit” If you've got a really smart product owner... 

This is what your
 product owner hears “We want to spend a huge amount of effort
 (aka money), and deliver no immediate benefit to the business” Digress, & talk about Incentives 

Incentives Let's look at the incentives for doing a rewrite 

Incentives • Faster to add new features • Enables feature XXXXX • Fewer critical failures • Less devops load • Happier devs • Recruitment Business 

Incentives • Work on a better system • Write software, not maintain it • Play with new toys • New tech/language/patterns • + CV / career • Faster to add new features • Enables feature XXXXX • Fewer critical failures • Less devops load • Happier devs • Recruitment Developers Business write software - we'll come back to that 

Not perfectly aligned * Rewrite could be good for devs, but bad for business, or vice versa (but usually devs are pushing for rewrite) 

Not saying "pitch a rewrite you know is a bad idea for your organisation" - depends on your situation and your conscience Know your goals and the goals of those around you => more chance of a good outcome 

“This code sucks” So common, it's a cliche (like builders/mechanics). OK, sometimes it's true, but there are other factors Why? 

Writing vs. Reading Code • Easier • More fun • Reputation Comes back to writing versus reading "Here is my gift to the world" github stars, twitter followers - "Here is a thing" vs. "I made this lib suck less" Serious problem in our industry - could be a separate talk 

Should you ever rewrite? 

Probably not ...but sometimes, yes - the new tech/architecture really is necessary - the code really does suck So, let's look at how to do it 

How (not) to rewrite Or rather, how not to. One, very common anti-pattern... 

No content

Big Bang • Feature freeze • Build new system (from scratch) • Migrate • Profit / Unicorns / Kittens / Ponies 

Why not? • It will take (a lot) longer than you think • You've stopped delivering value to users • The feature freeze is a lie • You're locked in • => Massive Risk There is a better way 

Instead of jumping off a cliff there is a better way to get where you're going 

Incremental • Work in small chunks • Freedom to stop at any point • Minimise Risk (one sprint) one sprint is an ideal scenario, but you can always get close to that 

Strangler Application The most common pattern for doing an incremental rewrite Martin Fowler, 2004 sinister name 

Strangler vine, aka strangler fig Dark, tropical forests where sunlight doesn't reach the ground 

Start with a tree. vine seed lands in crevice grows up and down, using the tree's structure, intercepting sunlight & nutrients Tree dies & only the vine remains 

Start with a tree. vine seed lands in crevice grows up and down, using the tree's structure, intercepting sunlight & nutrients Tree dies & only the vine remains 

Start with a tree. vine seed lands in crevice grows up and down, using the tree's structure, intercepting sunlight & nutrients Tree dies & only the vine remains 

Strangler Application 1. Set up production instance of new, alongside old 2. Build feature in new, that looks like old 3. Delete feature in old 4. Repeat until old is gone In terms of a software rewrite, process looks like this More detail about how to implement this in practice 

No. 1 rule - be prepared. Lots you can do before you start to make it easier to survive "Ash" - evil dead movies chainsaw where his hand used to be, & carries a shotgun Good mindset to have when embarking on a rewrite 

Test Coverage • Prove that new == old • Use your favourite testing tool • Containerisation Feature tests (acceptance tests) Don't start until you can prove new == old Changing tech, could be unfamiliar. Old tech could be horrible. Test suite can be its own application Containers can help - new & old & test suite can all target the same backend data store 

Walking Skeleton • Infrastructure • Deployment (CI/CD) • Web App. • Look & feel • Routing • Shared auth/session Writing the code is the easy part. Don't leave ops work to the end. Do it first look & feel - users shouldn't notice the difference. How to route some requests to new & some to old routing: sub-domain? path-based routing? sessions (to have a subset of users see new app)? shared auth. - port old auth to new app. can be quite a big task, move to standards? oauth or JWT 

Spike one function • Simple • Genuine • Authenticated • a.k.a. “Tracer Bullet” genuine - not a static content page: something that really exercises your system e.g. "edit my account" "tracer bullet" in Dave Thomas' "The Pragmatic Programmer" - crappy name, but it's about seeing what you're aiming at 

Back-end Systems • Choose component • Refactor (clarify boundaries) • Extract as a service • Replace with new version • Repeat Not just web apps - Can replace a backend system, one piece at a time Might be a bit more work One thing to beware of... 

Scope-creep • “We can fix XXX during the rewrite” • This will kill you, and eat your brain • Fix then rewrite or rewrite then fix One of the few nice things about a rewrite is the clearly defined scope This is what the chainsaw and the shotgun are for; "while you're in that bit of the code..." Puts you in an indeterminate state; new != old. Can't roll back, b/c user experience is different rewrite & development are different activities - guard that separation 

Summary • Incremental rewrite • Strangler Application • Prepare • Tests. Shared Authentication. DevOps • Fight scope-creep • (Mostly) Don’t rewrite, refactor From a dev. POV, I'd argue that launching a rewrite is the lazy option Unless you're changing tech. (for which you need a good reason), you can almost always refactor your way to clean, maintainable, performant code ... 

but it's usually harder, and less fun than throwing away and starting from scratch 

References • Things You Should Never Do, Part I
 http://www.joelonsoftware.com/articles/fog0000000069.html • How To Survive a Ground-Up Rewrite Without Losing Your Sanity
 http://onstartups.com/tabid/3339/bid/97052/How-To-Survive-a-Ground-Up- Rewrite-Without-Losing-Your-Sanity.aspx • Strangler Vine Pattern
 http://martinfowler.com/bliki/StranglerApplication.html • Walking Skeleton
 http://blog.codeclimate.com/blog/2014/03/20/kickstart-your-next- project-with-a-walking-skeleton/