http://devchat.tv/ruby-rogues/217-rr-architecture-without-an-end-state-with-michael-nygard
"early out"
"code archeology"
"netflix histrics"
Talk a bit about his book book-release-it and his talk talk-architecture-without-an-end-state
Also talks about liking book-architecture-of-open-source-applications
segregated interface principle: https://en.wikipedia.org/wiki/Interface_segregation_principle
Michael: "the thing people most wonder when they look at something is why is this like it is? Hopefully you can read the code and understand what the code is doing without too much difficulty. But understanding why it was created that way is much harder. You can't get that from the code as easily."
podcast-rr-217-architecture-without-an-end-state#avdi-ruby-startup-engineering1 AVDI: It does seem like there's some humility called for. And it's tricky because I feel like especially in this Ruby space where there's a lot of startup coding going on still.
You get hired to be a rock star, right? You get hired to be someone who's going to do more with less and do great things. It almost, it feels like that's setting you up at odds with this sense of humility in the face of the decisions that other people have already made in a code base. podcast-rr-217-architecture-without-an-end-state#avdi-ruby-startup-engineering1
podcast-rr-217-architecture-without-an-end-state#jessica-pragmatic-is-contextual1 2 Jessica: "When we do something pragmatic and this code works, leave it, move on to the next thing, then it's because of our context. It's because of our deadline. It's because the next thing was more important than cleaning up this code. But when someone else does it, it's because they're stupid. It's like a quality of them when in reality in both cases, in our case, and in the case of someone else, our reasons are almost always contextual. I like to notice judgment and actively try to replace it with curiosity." podcast-rr-217-architecture-without-an-end-state#jessica-pragmatic-is-contextual1 2
podcast-rr-217-architecture-without-an-end-state#michael-issue-with-metaphor-of-technical-debt1 MICHAEL: Yeah, absolutely. I've had an issue with the metaphor of technical debt because if the company goes under, it's not like somebody else has to assume the debt and pay it off. It just disappears. If you delete all the code, the technical debt just disappears. So you may never actually incur those costs. There's some likelihood of it. podcast-rr-217-architecture-without-an-end-state#michael-issue-with-metaphor-of-technical-debt1
MICHAEL: I want to talk more about the positive side of things that are helping. I definitely think that tools in the dev apps space in general - packaging, deployment, provisioning - all of those tools really help move toward smaller teams because they allow much smaller deployable artifacts to reach production. There's actually a pretty high transaction cost to moving traditional software into production. Whether it's a new rails monolith that's going to sit on some number of servers and talk to a relational database or whatever, the traditional way of doing it involved a lot of paper, a lot of meetings, approval processes and so on.
And so you want to go through that as little as possible which means you make the artifacts as big as possible to minimize the transaction costs. With the idea that we can have exactly the same configuration running in our dev environment, QA environment, production environment and we don't have to go through a large approval process because not only the code has been vetted but the precise configuration has been vetted. But it doesn't hurt as much to make it through that production pass and you can do much smaller things.
That leads us to decomposing the teams into much smaller teams and it leads us to focus much more on the way they talk to each other. Now what are the representations that we're exchanging over the wire? What are the protocols that we're going to use? Those are all benefits. The fact that smaller things are more easily discarded or disposed of, those are benefits.
So I'm trying hard not to say the word but I'm just going take the plunge and say the move toward micro services is really a reflection both of the architecture change and the organizational change that's enabled by the dev apps tools.
blog-post-why-algorithms-must-be-transparent