Cleaning Up Legacy Creating fit and configurable platform

Nikolay Novozhilov

nik@wego.com

www.novozhilov.co

Legacy…Typical situation for a start-up who “survived” A and B rounds of financing:

• No refactoring – ship as fast as you can

• Employees churn - a lot of code is “a black box”…in PHP

• Current product was build on top of the old one during the last pivot

• Data is stored in several databases…one of them is human-copypaste-machine

…what do we do?

• Old API, new API, API for the product that doesn’t exist anymore…

• JIRA is full of bugs and no time for new features

• More developers close more bugs and introduce more new ones

Let’s “redesign” everything!

What is wrong with re-design? (1)

What is wrong with re-design? (2)

• Every time you change CTO you end-up with re-design

• Real need, not just migration from Java to Scala or from MySQL to Mongo

What is wrong with re-design? (3)

What is wrong with re-design?

• “Lets try building a new thing from scratch and move there”. Bad approach!

• Old code is result of long experience

• A good spec is better than commented code. It answers the question why we did it this way and what else we tried.

Sharpen the axeGive me six hours to chop down a tree and I will spend the first

four sharpening the axe

Abraham Lincoln

• Stop bug fixing. Good solution has priority over fast solution

• What about super-urgentbugs? They are not!

• Everything is negotiable

Divide and Conquer

• Separate and rewrite one by one…

• Divide by functions, not systems

• Gravitation law: Front-end is easy, database is hard

Warranty

• Fix one area (with all bugs included) and put a warranty on it

• Move everybody to new system and fix all bugs real-time

• Then do the next piece

INSIDE ONE BRICK

Don’t ask the user…

• No surveys

• Observations are everything!

“Give me final requirements…”

• You don’t know everything upfront, so what is the choice?

– Ask for maximum you could imagine

– Ask for minimum you need

• No matter what you choose - you end up asking what can’t be done at all

• Platform thinking. If you found what feature to add don’t just add! Make process of adding simple!!!

• How to sell it – “we never come to you again”

Hit the user fast

• MVP is good. But you can do faster.

• Fake the solution!

• First goal is research, not final design

• For internal products – make developer explain to users

Shipped is not done

• Not done after deployment. Maybe 50% done.

• LR effect tracking. How many of your A/B tests were good only for the 1st

week?

DONE!

• Stop bug fixing

• Divide and Conquer

• Fix one area and put a warranty on it

• Don’t ask the user

• Platform thinking, not “final requirements”

• Hit the user fast

• Shipped is not done