Chatting with my friends about choosing developer frameworks, we accidentally arrived at this kale metaphor. It sounded witty and fun, so I’ll try to unpack it as best as I can. To begin, I will apply the value triangle lens from a while back, going over the edges of the triangle. I only need them as examples of the improbable extremes. What’s up with all the triangles in my posts lately?
A framework that favors the user/ecosystem edge will present itself as a promise of a high-minded idea, then quickly reveal a toy upon a close examination – kind of like one of those fake fruits arranged on a dinner table to spruce up the interior. As a child, yours truly once was lucky enough to taste one of those fruits and learn a valuable lesson about appearances. Yum, stale wax.
Building on the tasting metaphor, the combination of business and ecosystem value usually produces frameworks whose taste is best described as … cardboard, I guess? There’s definitely important ingredients like fiber in there, but the dietary value and enjoyment are nigh nil. Large companies tend to produce these frameworks for internal use and almost without fail, the quality of their developer experience tends to wind downward with time. These frameworks aren’t picked. They grow in place.
When a framework sits on the edge of user and business value, it usually tastes like candy. It’s downright addictive to use and makes everyone look good. Sadly, as we know from the value triangle discussion, the consequences of this sugar high are usually borne by the ecosystem – which eventually gets back to users. The long feedback loop of ecosystem effects creates a double-hook: if I only plan to stay on this team for a couple of years, there aren’t any downsides for me. I can just pick the hottest framework I like. Let the successors sweat the incurred debt.
It is my guess that when trying to find a framework that will work well for a team in the long term, the prudent choice will taste something like kale. Like the nutritious leafy vegetable, it won’t seem like an easy pick compared to other choices.
Such a framework will tend to look a bit boring compared to the other contenders, less opinionated. Instead, it will likely carefully manage its cost of opinion in relation to the underlying platform — and as a result, keep the papering over the platform’s rough edges to a minimum. Expect a couple of wart-looking things here and there. Make sure they are indeed the outcome of a well-budgeted opinion. Keep in mind the cardboard extreme – a good-for-you framework doesn’t have to taste bad.
The values of a kale framework will likely point toward concerns around the larger ecosystem, rather than directly focusing on quality of the developer experience. This is usually a good kale marker: instead of promising how great the taste will be, there will be focus on long-term health. Of course, please do the due diligence of taking the framework for a spin and make sure it’s not just a decorative ornament. Give it a few bites to ensure it’s not made of wax.
The kale-like choice may also be somewhat out of alignment with the team’s current developer practices. Misalignments don’t feel great. However, if you are looking to improve how your organization ships products, a framework is a powerful way to influence the development norms within the organization. In such cases, the misalignment is actually a tilt that steers it toward desired outcomes. For example, if my team is currently stuck in the anti-pattern of erecting silos of widget hierarchies for each new app, choosing a framework that encourages shared components might seem eccentric and inefficient, but eventually lead to breaking out of stuckness.
I hope these musings will help you generate some insights in your next search for the right framework. And lest I succumb to the normative voice of a recommender, I hope you use these insights to find your own definition of what “kale” means in your environment. May you find the strength to choose it.