What a day! This is my first dev conference and there’s quite a few things that have really resonated with me today.
#noestimates
A great idea behind the movement, to go back to the fundamental argument – you cannot predict the future, and therefore don’t waste time trying to estimate. It’s an interesting take, especially the study on prediction but will it take off, or doomed to fail like all previous variations? Ultimately the real world operates on the concept of budget and time and no matter how hard we try, the we are not disconnected from reality.
Seb Rose is a great speaker
He knows his stuff, very engaging speaker and the notion of evolving test really resonated with me. More on this later.
microservices – you’re doing it wrong
Most of what Neal Ford said in the beginning of his talk made much sense. He talk about the inherent problems with afferent and efferent points, about coupling and cohesion and the nightmare dependency chains. But then he went on with a completely ludicrous statement “one service per method”. WTF? I thought he misspoke and probed the question but apparently he strongly believes that is what microservices is. Now, the good bit is that microservices isn’t an invention by some famous programmer but a collective conciousness of the software development world that were already moving towards that direction before someone (Fowler?) gave it a name.
I won’t go into why you should do microservices but this notion of “one service per method” and the idea that a service is a “single responsibility through one method” is absolutely .. nonsense to put it mildly. Do single responsibility classes have just one method? I think not! Somehow, it seems to me that the group of people who fall under this category simply wants to move the coupling problem from packages (or binaries) to services … because coupling is services is fine … NOT.
Just because you can’t see them, doesn’t mean it’s not there! The problem doesn’t just disappear because you adopted the ostrich “put my head in the sand” approach to problem solving. That is not to say that the service can’t be only one method, but in my world view, a microservice should have some form of “bounded context” which is simply more than “just one method”.
the message patterns talk .. yea .. was a bit basic.
The talk itself was quite fine if not for that I’ve already heard all of it before. I thought our very own JM’s talk on it were quite a bit more engaging but that’s just me.
logically illogical 