Lessons from the trenches - my 2¢ on software architecture. As a the Mobile Architect in EverythingMe, I know it's hard to maintain the software architecture of our product. It's never as good looking as we want it to be, and it's a constant battle just to keep it barely acceptable... This is how we do it.

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

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

3. 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?

4. 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

5. 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)

6. So what does it mean?

7. INTERNAL AND CONFIDENTIAL 7
We move fast and cheap
l Most start-ups are underpowered and very
fast
l There's no time to do a "proper" s/w
development process
l Not always you have time to plan too much
ahead
l 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

8. INTERNAL AND CONFIDENTIAL 8
Iterations drive our progress
l We do lots of A/B testing and then
discarding the least successful code
l 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?

9. INTERNAL AND CONFIDENTIAL 9
We use a faulty deployment mechanism
l Contrary to our backend guys, we can't deploy
on a daily basis
l We must go through the market, which has a
way of its own
l Even when we deploy, we don't necessarily get
to a 100% of our user base immediately
l 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

10. INTERNAL AND CONFIDENTIAL 10
We must do release cycles
l 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 frequent
l 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.

11. 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

12. So how do we do it?

13. INTERNAL AND CONFIDENTIAL 13
So how do we do it?
l Accept reality
l Know what you want, and what you
don't
l Manage your debt
l Mark your target
l Make a plan

14. 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)

15. 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

16. 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

17. INTERNAL AND CONFIDENTIAL 17
Mark your target
l You must know where you want to be
eventually
l 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

18. 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

19. 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.

20. 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)

21. How we do it at EverythingMe?
(a few examples)
PRESENTATION NAME GOES HERE

22. INTERNAL AND CONFIDENTIAL 22
A/B testing management
l“Remote controlled” feature flags
lA/B testing mechanism
lExact targeting (device model/os version/client version)
lRemoves hard coded “ifs” from the code
lProvides a framework to isolate temporary/provisional code

23. INTERNAL AND CONFIDENTIAL 23
A/B testing management
lJSON 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” }
}
}
}

24. INTERNAL AND CONFIDENTIAL 24
Upgrade Management
lSafe and robust module to handle (multiple) version upgrade
migrations
lMakes sure that all backward compatibility code stays in one
place.

25. 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

26. Good Luck!