Over the years, I’ve been a part of many decisions (and lively debates) around the choice of software development libraries, tools, and frameworks.
Many variables feed into these decisions, but more often than not, they are all quantifiable: integration costs, licensing costs, training costs, support options, maintenance needs, the availability of developers with relevant experience, and more.
But many of these quantifiable variables are ranges or flat-out guesses because any software development estimate is challenging at best, wildly inaccurate at worse.
That’s where subjectivity and emotion come into play. As I’ve written before, I don’t think it’s entirely possible to require a “strictly business” approach to anything humans do in collaboration and earnest, like participate in a software development team. We’re not robots. We bring our emotions to work whether we want to or not. And our work will be affected.
So when it comes to choosing a framework, in my experience, the way a framework makes an advocate or detractor feel will undoubtedly affect the way they tabulate the objective variables that drive the decision.
So when it comes to choosing a framework, in my experience, the way a framework makes an advocate or detractor feel will undoubtedly affect the way they tabulate the objective variables that drive the decision.
That’s why “shiny new” frameworks are often introduced as choices where perhaps they shouldn’t be. Learning new stuff is fun. It will feel better than the same old thing. (At least at first.)
As a developer myself, I can report that different frameworks do indeed have unique feels. Using statically typed languages gives me a feeling of solidity, speed, and accuracy. But working with repetitive boilerplate code and rigid rules feels heavy and bureaucratic. And though I haven’t found a way to measure it, I think the products I’ve coded against are better when I feel enabled by the framework rather than feeling burdened by it.
Ruby on Rails is the first web development framework to openly acknowledge the importance of the vague notion of “developer happiness.” Many teams choose Rails specifically for that, while other teams, unfortunately, discount it for prioritizing happiness over things like scaling and flexibility.
The “happiness,” in my opinion, is derived from the close connection Rails lets a developer have with the end product. Sure, it’s not statically typed and fast, but I’d argue that a close (and happy) connection between a builder and a product generally yields a better product. On many occasions I have reached for Rails over other frameworks because of this, despite other objective factors.
So when you’re gathered around a whiteboard (or Zoom call), charged with choosing between framework A and B, don’t be afraid to ask how each choice makes everyone feel. Because subjectivity and emotion will undoubtedly make their way into the decision matrix, and working with a framework that feels wrong to your team can lead to building something substandard.
