a rocket internet experience @ forumphp paris 2013

A ROCKET INTERNET EXPERIENCE

Alessandro Nadalin, 22nd November 2013

AGENDA

1. Context2. Responsibilities

3. Building the team4. Get started

5. Mutate6. Delegate

7. BONUS

1. Context

1st April 2012

2. Responsibilities

Strive towards excellence

Make things work

TDD is useless

Automated tests are useless

Symfony2 is useless

PEOPLE, FFS!

3. Building the team

You can't make everyone you know relocate

You can't relocate your company

How to hire a very good (middle-eastern) team?

HIRE THE YOUNG

They forget about the clock and areusually attracted to new technologies

Moreover, there is no big bias.

IGNORE CVs

How many PHP indians companies are out there?

How many of them do you know?

We are biased

Ask for partial overtime

No one expects everyone to know about everything,that is why we hire people and train them

Training has a cost that both the employerand the employee have to split

Means overtime forchanging labels it's useless,

of course

but OT is fine, get over it

It's a matter of what both partsoffer for / in those extra-hours.

Pyramid interview

Who is Frederick Brooks?

What is the second-system effect?

What does PEAA mean?

What is a data mapper?

Why is it cool?

Why is OOP better than procedural code?

What happens when you hit enter in the browser bar?

...and so on.

Surprise them

An interview is always a good opportunity for learning.

Given that you can effectively teach stuff with the pyramid interview...

...wear shorts if you want.

...ask how many cabs are out there if you want.

Putting the candidate in a no-comfort zone will let you know how he or she reacts to variable

situations and unknown problems.

If you ask weird questions...

Gain authority on the field, not on paper

If you wear shorts...

Gain authority on the field, not on paper

Remember people not to be judgemental


Beach after Work!


Offer fair packages

At the end of it...

4. Get started

"It takes 3 months to be effectively productive"

"Because the developers can't understand the code"

Solution #1

Fire them all

Why don't they understand the code?

"Because the code is not that domain driven"

Solution #2

Replace the software

In the next 4 months, we would have replaced our entire architecture with a RoR application and parts

of the architecture with NodeJS...

...if I was that dumb.

COST / BENEFIT

Know-how and tools for free is something you can't easily drop.

Instead of replacing a monolithic approach with another monolithic approach, you split the system

in layers and work on each of those layers.

So, why isn't the code domain-driven?

"Not everyone knows how decoupled DDD works"

And that's perfectly fine.

Imagine Fabien as your bosswhen you were a Rookie?

We're all born n00bs

Socratic approach

Socratic approach

Question something

Socratic approach

Question something

Raise your thoughts

Socratic approach

Question something

Raise your thoughts

Let them elaborate

Socratic approach

Question something

Raise your thoughts

Let them elaborate

Drown together

Socratic approach

Question something

Raise your thoughts

Let them elaborate

Drown together

Accept evidences

Socratic approach

Question something

Raise your thoughts

Let them elaborate

Drown together

Accept evidences

Ready to move on

The BIB approach

"BECAUSE IT'S BETTER!"

Do not change people becauseyou want things to get better.

Change things becauseyou want people to feel better.

5. Mutate

In ~3 months

In ~6 months

In ~9 months

In ~1 year

In ~1.5 years

All of this besides day-to-day development

~3 months: 1 deployment a week

~6 months: 1 deployment a day

~9 months: 2/3 deployment a week

~1 year: ½ deployments per week

~1.5 years: whenever s**t is ready

"Instead of replacing a monolithic approach with another monolithic approach, you split the system in

layers and work on each of those layers."

The paradigm changes

A software design based on discrete software components, "services", that collectively provide the functionalities of the larger

software application

You typically start with theinfamous web application

which does everything on its own

Then you realize that to providea chat system to your users

PHP might not be the best...

And soon you also decide,to improve performances,

that your frontend should have its ownin-memory persistence, to be faster

and you put it into another service

Then, as always...

SCALE.

And eventually, your lead architectwill come up and tell youthat your Java-based chat

sucks and should bereplaced with...

NODEJS

In human-understandable words, SOA is a software design which embraces splitting a monolithic, totalitarian software

architecture into smaller pieces, thus making them independent, loosely coupled and more maintainable

A backend service exists...

...and a new frontend pops out

Another one might want to dealwith the same data...

And ask the first one to compute some data...

And once it's done, there might be the chancewe want to raise an event...

And monitor if there is a problem...

WARNING

No one is designing Web Services for you anymore

Interfaces are crucial

Software design is crucial

Don’t limit yourself to develop stuff

ENGINEER THINGS

6. Delegate

A team of 12

A company of ~200

Release managementhttp://odino.org/source-code-workflow-after-3-months-of-github/

Maintenance

Product management

Delegation means...

Faster cycles

More time to pair and teach

Committed team members

...yawn...

Alessandro Nadalin

Alessandro Nadalin

@_odino_

Alessandro Nadalin

@_odino_

Namshi | Rocket Internet

Alessandro Nadalin

@_odino_


VP Technology

Alessandro Nadalin

@_odino_


VP Technology

odino.org

Thanks!Alessandro Nadalin

@_odino_


VP Technology

odino.org

7. BONUS

Join us!

Sr. Software Engineer

In Dubai.

namshi.com/careers/

http://www.youtube.com/watch?v=NThxiu1HGgM

http://en-ae.namshi.com/careers/

http://en-ae.namshi.com/careers/



Thanks!Alessandro Nadalin

@_odino_


VP Technology

odino.org