
Slow Deployment Causes Meetings - gk1
https://www.facebook.com/notes/kent-beck/slow-deployment-causes-meetings/1055427371156793
======
jedberg
I see what he's getting at, but I don't think it's right.

Meetings are caused by policies and the need for coordination. Even companies
with continuous deployment still have meetings.

You can eliminate policies, which will reduce meetings, but you'll still need
coordination. You can move coordination to your issue tracker or agile board,
but then you've just replaced meeting time with the time you spend interacting
with the tickets and the agile board.

There really is just no way around it. The bigger you get, the more
coordination you need.

Running small teams responsible for small services is one way to reduce that
need somewhat, which is part of why microservices are getting more popular,
but at the end of the day I'd say coordination time, in whatever form it
takes, is linearly (or maybe even exponentially) correlated with org size.

~~~
exelius
But then you just end up with a bunch of microservices you have to coordinate
changes between. Microservices are more of an implicit recognition that the
job your software does is complex enough that you need the overhead of
managing them.

I do think there's an element of truth to what he's saying: organizations
develop processes that can handle a certain amount of throughput, and trying
to increase throughput means making changes to those processes, which means
meetings about reducing the number of meetings. The amount of overhead is
largely driven by executive visibility requirements (and past times that
executive has been "burned" by a bad deployment) so it can't really be
changed.

I actually kind of agree with the mantra: "If you want to deploy more, deploy
more often." We become accustomed to testing changes of a certain size, and if
we try to cram more into a release, then release testing and certification
takes longer. Big releases are the enemy of most Agile processes.

~~~
jedberg
> But then you just end up with a bunch of microservices you have to
> coordinate changes between.

Not if you do it right. As long as the API doesn't change and you adhere to
every service having its own data store (which is key and many people forget),
you can make as many changes to your service as you want without any
coordination.

~~~
IanCal
>you can make as many changes to your service as you want without any
coordination.

I'm really not sure that's true. If I change my classifier endpoint, even with
the same API it's important people know that they might get different results
for the same input. It might be really quite important for peoples analysis.

Their system might not fall over, but that doesn't mean I don't need to
coordinate with them.

Perhaps I'm missing something in what you're describing though.

~~~
jedberg
I would say changing the resulting data in a meaningful way is still changing
the API. The API contract is not only the verbs that they can use but the
nouns that you send back.

~~~
IanCal
Well, if all you were saying is that given the exact same requests, the exact
same responses come back then you don't have to co-ordinate changes, then I'd
agree. I'm not sure that's a particularly controversial point.

Although that does involve _knowing_ your responses are identical.

If my results are different _at all_ I would need to notify people downstream.

~~~
jedberg
> If my results are different at all I would need to notify people downstream.

Presumably your API says what _types_ of data the caller should expect. As
long as you don't change that, they should be able to deal with the response
changing.

But really it's more about the fact that if you have a single monolith, if you
want to make a change, you have to coordinate with _everyone_ at the company,
whereas if you have microservices, you only have to coordinate with those who
are _affected_ by the change.

~~~
IanCal
> Presumably your API says what types of data the caller should expect. As
> long as you don't change that, they should be able to deal with the response
> changing.

The point I wanted to get across was that although a client won't _break_ ,
I'd still want to talk to those pulling data from the system. I was
disagreeing with the statement "you can make as many changes to your service
as you want without any coordination."

> But really it's more about the fact that if you have a single monolith, if
> you want to make a change, you have to coordinate with everyone at the
> company, whereas if you have microservices, you only have to coordinate with
> those who are affected by the change.

Yes, it does lower the hurdles to getting something out.

------
jobu
Many developers and companies look at Facebook as a model for good software
practices and principles, so it's interesting to see them struggle with the
same issues:

 _" Increasing overhead initiates a positive feedback loop: less getting done
-> more pressure -> more mistakes -> even fewer changes per deployment -> more
overhead -> less getting done."_

~~~
ryandrake
I think the jury is still way out on whether Facebook's model is something to
emulate or avoid. In the end, it's going to depend on the company, the
product, the customers' expectations, and the engineering talent/engagement.
"Move fast and break things" just isn't going to work everywhere.

I've seen places where waterfall was totally appropriate and worked well.
There's a lot of variety out there.

------
eecks
Facebook deploy changes to production three times a day? Did I read that
right?

~~~
TheAdamist
It seems almost every time i use the website something is
new/different/broken, so i'd believe that they're deploying that rapidly.

The mobile app seems a bit slower, with broken features staying broken for a
while. (matching the stated 2 week cycle).

