Un interviu cu DHH (Ruby on Rails creator)
Cateva idei interesante din articol:
So the problem with those methodologies is they put too much focus on estimating, which is inherently impossible with software?
I’d go even further and say that estimation is bullshit. It’s so imprecise as to be useless, even when you’re dealing with fixed inputs. And you’re not. No one is ever able to accurately describe what a piece of software should do before they see the piece of software.
The magic really is in shifting your mindset from estimates to budgets. Don’t think about how long something takes. Think about how long are you willing to give something. This flips the entire idea.
I wanted to go back to microservices. One of the engineers I spoke to earlier talked about them as a response to the monolithic software becoming too complex to maintain. What’s your beef with microservices?
Let’s start with the premise. Monolithic software becoming so complicated… what is this ‘becoming’? Is this just happening to us? Are we completely innocent bystanders? The complexity is just rolling over us and there’s nothing we can do? That is a bullshit assumption that we need to refute. Complete and utter nonsense. You don’t have to let complexity roll over you. You choose to. And once you’ve chosen to be flooded with complexity, then a natural response is to try shove that complexity into more different boxes because you just can’t handle it all at once, right?
If you are unable to contain the complexity of a monolithic application, what on earth makes you think you are competent to distribute that complexity across a fleet of services that now have to interact and deal with network unreliability, retries, two-phase commits, and all these other complexities that simply do not exist when you deal with method calls, parameters, and the basics of running a singular process.