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?
INTERNAL AND CONFIDENTIAL 4
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
INTERNAL AND CONFIDENTIAL 5
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?
INTERNAL AND CONFIDENTIAL 7
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
INTERNAL AND CONFIDENTIAL 8
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?
INTERNAL AND CONFIDENTIAL 9
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
INTERNAL AND CONFIDENTIAL 10
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.
INTERNAL AND CONFIDENTIAL 11
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?
INTERNAL AND CONFIDENTIAL 13
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
INTERNAL AND CONFIDENTIAL 14
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)
INTERNAL AND CONFIDENTIAL 15
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
INTERNAL AND CONFIDENTIAL 16
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
INTERNAL AND CONFIDENTIAL 17
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
INTERNAL AND CONFIDENTIAL 18
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
INTERNAL AND CONFIDENTIAL 19
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.
INTERNAL AND CONFIDENTIAL 20
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
INTERNAL AND CONFIDENTIAL 22
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
INTERNAL AND CONFIDENTIAL 23
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” } } }}
INTERNAL AND CONFIDENTIAL 24
Upgrade Management
lSafe and robust module to handle (multiple) version upgrade migrationslMakes sure that all backward compatibility code stays in one place.
INTERNAL AND CONFIDENTIAL 25
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!
Top Related