4 ms·
This sounds like a sure way to enforce a local optimum. If you can't make mistakes and break enough things at a time to change the architecture, in order to fix
by arithma 8y ago
This sounds like a sure way to enforce a local optimum. If you can't make mistakes and break enough things at a time to change the architecture, in order to fix the architecture itself, it means your architecture is going to be extremely sticky, and there will be no chance that design mistakes will be corrected.
- jasonpeacock 8y agoOwning production systems means you can't make mistakes and break things. People are already doing what you're saying can't be done, everyday, when they change production systems. He's saying you should figure out the path from A to B and get there in small steps. And make sure your tests pass at each step. Don't make big changes that are hard to propagate and merge with others' changes. Basically, avoid the classic "nobody change anything, I'm doing a merge today!" situation.
- lifthrasiir 8y ago> People are already doing what you're saying can't be done, everyday, when they change production systems. Only seemingly so. People do break tests when they are writing (or removing) code, and even intermittent commits often don't pass tests (they thus have to be squashed before the merger, they only exist for making reviewer's jobs easy and keeping them risks faulty bisect for example). Development and deployment are separate things.