Should we try to be as technology agnostic as much as possible?

Question

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?

Thanks

Answer 1

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.

Answer 2

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.