It is true that we cannot be 100% technology agnostic when we are using a framework or tool, we will be always at least 20% dependent on the tool or framework.

The thing is that I feel better if I can be as much agnostic as possible of the chosen technology. My main 2 reasons are: it's easy to migrate to a better tool that is created in the future and any new developer coming to the team will understand immediately the code, if it is not so "framework" dependent.

Any one else can come with good reasons to be or not to be as much tool agnostic as we can?


  • 5
    Cost/benefit analysis. The more technology-agnostic you are, the higher the complexity of your own code (to create the various abstraction layers), which would be wasted if you never change frameworks. On the other hand, embracing a framework is wasteful if you change frameworks often. At the end of the day, how often do you reasonably expect to change frameworks? If you're wrong, well, it's not that big of a deal.
    – Brandon
    May 29, 2016 at 0:22
  • 1
    Depends entirely on the technology, of course. For every project I've ever done, it makes sense to try to be agnostic to the compiler/runtime/standard library/VM implementation by sticking to standardized language features, and it makes sense to be database agnostic by sticking to standard SQL, but being UI-framework agnostic is very hard to do without effectively writing your own UI framework in the process, so for that the best you can hope for is keeping UI code cleanly separated from everything else.
    – Ixrec
    May 29, 2016 at 10:29

2 Answers 2


This is a very general question so the answer can be unavoidably "it depends".

As an example, JPA (Hibernate) and Entity Framework are attempts to create abstraction over (mostly relational) databases - so that your app is agnostic of the actual SQL database engine it is running on.

That's great, but it's not free. What you get is more flexibility (you can theoretically switch the underlying DB engine) and better abstraction, but you lose the possibility to use more advanced features of the DB for e.g. better performance. Also, these abstractions are often quite "leaky". Replaced DB (and app) will still probably behave a bit differently than the old one. You still need to be aware of what SQL does, basics of relational model. So it can actually be more difficult for newcomers - they need to know both SQL and framework of your choice.

But this is still not totally agnostic. JPA/EF are again just a piece of technology which you want to be agnostic about. So you create your own layer on top of JPA/EF which hides away all the implementation details (entitymanagers, dbcontexts etc.)

People typically employ existing patterns (dao, repository) for this purpose. New employee still needs to know SQL, JPA/EF and now your shiny new layer.

Situation described above is actually quite common, but it's far from "as much agnostic as possible". You could also stop assuming that you use db with relational model (NoSQL), that your db supports transactions and ACID, then you end up with having programming model of essentially persistent key-value storage. You need to think about what you lose and what you gain.


The jury is still out on this question.

There are costs (consequences) no matter how you choose.

There are many ways to classify and compare the consequences, but the basic ones are:

  • Effect on development cost / productivity
  • Effect on product quality as judged by customers (e.g. lack of defects and functional limitations)
  • Effect on maintenance
  • Capability of the team - whether they are / will be up to the task. Remember that "team" is a fluid concept - people join and leave teams on a regular basis. There may be no original members remaining in the team five to ten years down the road.
  • Risks
    • Competitive - depends on what your competitors do.
    • Interruptions - whether a framework provider may vanish suddenly or be hit with lawsuits, or whether the contract / code license may be terminated at any time

This list is, of course, not exhaustive.

When analyzing the cost and benefits, one has to take the timeframe into discount. This is known as "time discounting" / "time preference" in economics.

In other words, you have to give stronger consideration to the short- and near-term tradeoffs, because the long term tends to be unpredictable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.