“It doesn’t work for us.”
You have heard this kind of talk many times.
- “It doesn’t work for us.”
- “But it works for Google.”
- “Well, yes, but we are not Google.”
- “What does work for you?”
- “Ehm...”
No matter the technique or the big tech company, the story is always the same: A proposal to tackle a real-world problem with a standard method or approach is dismissed immediately without even being considered. It is incredibly common for people to argue that their context is different, their setup is too unique, or that the suggestion is just "book-smart" and fails the reality check.
Yes, all of those arguments might be valid. It is important to consider the current environment because an idea's success depends heavily on the context in which it is implemented. Yet, a crucial element is missing from most of these discussions: an alternative.
Okay, so if trunk-based development doesn’t work for you, what does? If you don’t write automated tests, how do you verify that everything still works during regression? If your team doesn’t have an agile mindset, how do you ensure you’re building the right product?
Already Solved
Of course, every organization is unique, and every product has its own specifics. But underlying technical problems tend to be remarkably similar. In fact, it is almost impossible to encounter a problem that nobody else has solved (and blogged about) yet.
Standard solutions act as ready-to-use frameworks, designed broadly enough to be useful across the board. There are plenty of them out there, each offering a unique set of benefits and trade-offs to weigh against your specific context.
When you face a problem, don’t try to reinvent the wheel. Search for existing solutions, choose the best fit, adapt it, verify it, and iterate.