Micro-Services for Dysfunctional Teams

[rbanffy]

http://dejanglozic.com/2015/03/03/micro-services-for-dysfunctional-teams/

[coldcode]

If your team is dysfunctional, I bet your micro services will be equally dysfunctional. If you don't do them correctly, the end result will be an even bigger mess than the monolith. Like everything, there are many more ways to screw it up than to do it right.

[nutate → coldcode]

I think dysfunctional is being used as a term of endearment to some degree. But I agree, the interfaces become the catalysts for the long meetings, the code debates, etc. It doesn't end up mattering if it becomes a question of "fix your service" vs "fix your client" arguments.

[dglozic → nutate]

You are correct - dysfunctional as in 'strong willed people that want to move at a different pace', not 'incompetent' :-).

[djvu9]

You have a technical problem. You want to solve it with XML, and now you have two problems.

You have a management problem. You want to solve it with micro services, and now you have N problems. N = number of micro services.

[ExpiredLink]

Adaption to dysfunctional management structures and processes seems to be a mega-trend in IT: Agile, Micro-Services, HDD (hype driven development), ...

[dglozic → ExpiredLink]

True - and more as a realization of reality in real world orgs than an ideal state. More pragmatic.

[ExpiredLink → dglozic]

I'm not convinced that this is the right way to tackle the problem.

[SideburnsOfDoom]

The second sentence is "Man, does that city every shut up."

eh? Is that a double-typo of "Man, does that city ever shut up?" meaning that it's a noisy town, or is the author trying to say something else?

[dglozic → SideburnsOfDoom]

It's a typo, thanks for pointing it out - fixed.