A lot of factors are considered in a build vs buy decision. What are the technical capabilities of existing systems? Is the functionality a core offering of my own product? How complex would it really be to build? How much would buying cost? What about switching costs?

One thing I find myself considering more and more is the philosophy of the people who are building the technology I am evaluating. This isn’t something I normally list out out explicitly, and it is rarely brought up in discussions with other developers. Yet, it happens to be one of the most important factors.

All software systems have technical limitations, often in the form of bugs. But limitations can be overcome and bugs can be fixed. Software rarely looks the same after a couple years of development.

The big question is what is likely to change versus what will never change. React vs Vue/Angular are a perfect case to look at here. They’re all popular front end frameworks. They all care about performance. They all test their releases fairly well. They have various upsides and downsides that we could nitpick, but those can all change from release to release.

What will almost never change is their fundamental approach to software development. React runs on the idea that everything is driven by code. There is a bare minimum in an HTML template to load the application. From there the code determines what is displayed. HTML is simply output of that code. React is perfect for people like me who believe that having HTML templates makes software development cumbersome. The separation of code from the visual definition is largely superficial and causes more problems than it solves.

Vue and Angular take a different approach. They believe HTML templates have an important place in front end development. As such, code is sometimes triggered by “directives” defined in the HTML. This is perfect for people who believe that the separation of HTML from code provides better clarity when developing software.

While I have an obvious bias, both approaches are perfectly valid. Lots of high quality software have been built with both approaches. But if your style of software development leans towards one or the other, then you should pick the framework that fits your style. Don’t pick React thinking that it will someday provide a bigger role for HTML templates. Don’t pick Vue/Angular thinking that it will someday let you define everything from code.

Consequently, if your own preferences lean towards one of these philosophies, don’t let a bug here or there entice you to pick the technology that goes against your fundamental preferences. Bugs can be fixed. The very core of what the framework is will not.

To go a little deeper, sometimes a technological approach provides an indicator in how developers may make other decisions. An example of this is Sugar.js. When I was investigating date/time parsers, I found Sugar to be superior technologically. It was the most accurate and it was in Javascript so I could run it on the front end without making API calls.

However, they originally had overridden native objects such as Date. They created a way of opting out of this method because many developers hated it and it stopped them from using the library. Now while the technology itself has changed, the belief in the validity of this tactic serves as an indicator for the developers tolerance of risk vs reward.

Personally, I’ve been burned enough times by libraries overriding native objects that I believe the reward is never worth this risk. It’s my bias based on my own experiences. Other developers have other experiences and therefore a different opinion on the matter. That’s ok. What it means for me though is I know that I have a fundamental difference of opinion with the developers of Sugar. No matter how much I like the functionality of their library, I have to keep in mind that some future release will have a decision that will cause me to not want to upgrade. That means this library is a likely candidate for replacement in my software and I have to account for that.

There are other examples of this. There’s a popular backend technology that I’ll leave unnamed. My friends love it. The developer community at large seems to love it. I even loved it when I was using it at a past job (and someone else was maintaining it). In many ways, it makes life much easier.

Unfortunately, the developers make many choices that can be confusing to navigate. I would consider these choices bad UX, though we don’t often talk about UX with backend technologies. Yet, when I read the forums where other developers ask questions about these decisions, the response leaves much to be desired. Instead of addressing these issues, the developers of this technology fall back on the time tested tactic of blaming the user.

These developers are very intelligent and they built a fine piece of software engineering. But software development is stressful enough as it is. I don’t need a library/framework increasing that stress more than it needs to be. I simply don’t trust that future releases of this software will minimize my anxiety and so I choose not to use it despite the consternation of my peers.

Speaking of trust, the easiest and least subjective choice is when developers of a technology have a similar attitude but aren’t delivering quality work. I once was looking for a framework in a niche industry. One of the ones on the docket had a number of issues, the biggest one being that one of the pages literally took 30 minutes to load. I found out that this was because the framework didn’t run well on virtual machines because they hit the filesystem a lot. Instead of explaining why they needed to hit the filesystem, the framework developers blamed VMs for being slow at synchronizing files.

There were plenty of other examples of these developers blaming other technologies with the issues people encountered with their framework. In the end though, at some point a framework developer needs to take responsibility for the use cases their technology is supposed to solve. If they don’t, then people can’t trust their technology because they can’t trust those developers.

When choosing a library, framework, or service, we’re not just betting on the software in its current state. We are taking a long term bet on where that technology will be years from now. And while the individual developers for that technology may change, there is a philosophy around that technology that their replacements also believe in. Taking note of that philosophy is an essential factor in picking a technology to use in your own software.