"If I have to raise a PR to rename a method that bothers me, I’d rather not do it"
And this is a short story about the process that penalizes people for trying to do their best.
»When batch size goes down, confidence goes up
Interestingly, I noticed that the smaller the steps I take when refactoring, the less of a need I have to run the tests.
»Big batches tend to make failures less than they actually are
Remember the last time you faced a big failure. How difficult was it to acknowledge it and how long did that process take? As you know, sometimes we can go whole life without being willing or ready to face it.
»Move the work to the people, not the people to the work
Big batches incentivize for choosing a suboptimal solution
As the batch size goes up, the emotional investement in it goes up as well, since we’re investing more time in the given solution.
As we become more invested in the solution, the bias towards that solution becomes stronger and it’s less likely for other equal solution to surface.
It’s likely that we become defensive about it as well, just because of the emotional pain of a huge work that we would have to do in case of rework or a complete change of the solution.
Mob Programming is a Drum Buffer Rope implementation
Interested in how to implement Drum Buffer Rope from Theory of Constraints to product development teams?
Try out mob programming. It makes sure that the whole team will be running at the pace of its currently slowest skill (constraint), which is essential for:
Queue time has way more leverage than processing time
Lead time = processing time + queue (feedback) time
»Sign of a premature generalization is lack of pain when trying to progress
If you didn’t feel at least a bit of pain when adding new functionality, implementing process or introducing a tool, most probably you already prematurely generalized. Empiricism assumes some pain because it’s based on learning, not speculation.
»One word to cut the batch size
There’s a difference between:
“We’re not saying we’re not going to do this thing”
and
“We’re just saying we’re not going to do this thing now“.
Slow tests can help you find a way to deliver value sooner
Test execution time can tell you a lot about design of your service. If you have a bunch of domain logic in the parts of the service where it shouldn’t be (controllers, repositories, external gateways or any adapter of that sort), your tests have to spin up a mock MVC or embedded database or stub service in order to test it. The more logic you have in these parts of the app, the more tests you’ll have against them, the slower the test suite.
»