perfect product architecture in a non-stop start-up

HOW TO MAINTAIN A PERFECT PRODUCT ARCHITECTURE IN A NON-STOP START-UP

HOW TO MAINTAIN A PERFECT PRODUCT ARCHITECTURE IN A NON-STOP START-UP

DECENT

INTERNAL AND CONFIDENTIAL 3

Introduction

• We want to develop a nice and tidy, "textbook" architecture.

• It all seems so simple and elegant before we start to code.

• After 3 months is all spaghetti code full of hacks

• WHY?


The traits of developing consumer apps

• No specific customer• Usually improving a single product in

small iterations• No "hard deadlines" (most of the

time)

• Product vs. Project


The enemies of good architecture

• We move fast and cheap • As the saying goes, "pick any two" - for start

ups, there are only two viable choices.• Iterations drive our progress

• As start-ups usually aim for a moving target• We use a faulty deployment mechanism• We must do "traditional" release cycles

• (continuous integration is a much less viable option)

So what does it mean?


We move fast and cheapl Most start-ups are underpowered and very

fastl There's no time to do a "proper" s/w development

processl Not always you have time to plan too much

aheadl We prefer to go for the MVP and iterate based on

data instead of "over-engineering"

We may know what's the “right” solution, but often we need to move fast, so we just hack it


Iterations drive our progressl We do lots of A/B testing and then discarding

the least successful codel We love our buddies in the product and

design teams But they sometimes cause our code to

fluctuate

If we know there's a small chance that the code will make it to production, so why not hack it?


We use a faulty deployment mechanisml Contrary to our backend guys, we can't deploy on a

daily basisl We must go through the market, which has a way of

its ownl Even when we deploy, we don't necessarily get to a

100% of our user base immediatelyl Users can be upgrading from any historic version to

the most updated one

Most "upgrade handling" & "backward compatibility" routines tend to go in as hacks


We must do release cyclesl There's a great part of our product that must

undergo manual testing (lots of UI testing, lots of UX testing, lots of "this doesn't

feel right" issues...)l The market cycle which can't be too frequentl This means that many features are stacked up into

every increment

Beware of the "Last-minute-before-the-version-release" bug fixes are usually the "least-change" hacks instead of the correct solution.


Hacks are a necessary evil

l It's what allows us get it ready in time

l They're still evil, though.l Hacks are what makes us fail in

the long run

So how do we do it?


So how do we do it?

l Accept realityl Know what you want, and what

you don'tl Manage your debtl Mark your targetl Make a plan


Accept reality

l You'll never get to that spiffy architecture you're dreaming about

l Unless your startup died or you've been acquired by Google and work on a side project there

l Your job is to maintain an acceptable architecture (with a smile on your face)


Know what you want / Know what you don't

l Good architecture isn't an absolute good

l The only reasons to have good software architecture are:

To enable fast & cheap feature development in the future

To have a more robust (= high quality, less testing) product

l And it should be cost effective


Manage your debt

l Each time a hack goes in, write it down in your HackBook(tm)

l Remember thy hacks as they should trouble your sleep

l This is where code review comes in handy

You don't necessarily control each and every commit, but at least make sure you know them


Mark your targetl You must know where you want to be

eventuallyl Define the critical modules who need the most

attention and which are probably not worth the trouble

l Don't waste time explaining this to non-developers (just joking (but seriously...))

This is a continuous task which should become part of your day-to-day work

There's no point in advocating for prioritization and allocating resources for it


Make a plan

l Fix your app with a set of well thought of small refactors

Don't branch and fix on your own and expect a big ceremony when you merge back


Refactors?

l Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior. Refactoring improves nonfunctional attributes of the software.


Make the time for doing the refactors - it's your responsibility

l Try to overload a required "product feature" with one of yours planned refactors

l Whenever you have a small break - fix one hack off the list (it feels good)

How we do it at EverythingMe?

(a few examples)

PRESENTATION NAME GOES HERE


A/B testing management

l“Remote controlled” feature flagslA/B testing mechanismlExact targeting (device model/os version/client version)

lRemoves hard coded “ifs” from the codelProvides a framework to isolate temporary/provisional code


A/B testing managementlJSON stored on server, parsed in client"new-button-green-or-blue": { "weight": 20, "conditions": [ { "screen-density": [ 240 ], "!locales": [ "en_US", "en_UK", "en_GB" ], "os-versions": [ 14, 15,16, 17, 18 ] } ], “variants”: { “green-button”: { “weight”: 50, “parameters”: { “color”: “#00ff00” } }, “blue-button”: { “weight”: 50, “parameters”: { “color”: “#0000ff” } } }}


Upgrade Management

lSafe and robust module to handle (multiple) version upgrade migrationslMakes sure that all backward compatibility code stays in one place.


Follow us

All these modules will be open-sourced in the upcoming weeks.Follow us at:

https://github.com/EverythingMe

http://geeks.everything.me

Good Luck!

perfect product architecture in a non-stop start-up

Technology