4 ms·

So the benefits to testing seem clear and compelling. But I cringed a little when I read the bit about wanting to maybe one day swap out the search backend. A

So the benefits to testing seem clear and compelling. But I cringed a little when I read the bit about wanting to maybe one day swap out the search backend. A pretty big chunk of the code that annoys me most at work is a result of this kind of premature abstraction ("maybe we'll need to swap out the database layer one day"). As far as I can tell most of the time this is never needed, and the net time lost by hundreds of developers over several years is much greater than the cost of forgoing the extra layers and just making the transition the hard way as and when it's required.

UK-AL 9y ago
But when you do need it, and you haven't put in the mechanisms to replace it. Your screwed. Without the proper abstractions things can become tightly coupled, and your going to spend a lot of time untangling it. I've been on projects like this, and spent a lot of time getting annoyed at the lack of foresight.
- crdoconnor 9y ago
  You can go overboard though. Excessively loose coupling can come at the expense of DRY (and vice versa). It's a trade off.
- lgas 9y ago
  The problem is that few projects survive long enough to get to the point where anyone can be annoyed by the lack of foresight... so often any foresight or effort on implementing what was foreseen is wasted effort. Often times that wasted effort contributes to the premature death of the project by soaking up resources that could've been used to implement more features, fix more bugs, etc. The question is which is more problematic, the lack of foreseeing the need to change the database or the lack of foreseeing the death of the project due to spending time on the wrong things? Personally I think having a successful project that needs the database changed is a) not a particularly hard problem to deal with and b) a good problem to have.
locopati 9y ago
We also take for granted that a lot of that work has already been done for us (e.g. JDBC or Hibernate in Java or ActiveRecord in Ruby).

UK-AL 9y ago

But when you do need it, and you haven't put in the mechanisms to replace it. Your screwed. Without the proper abstractions things can become tightly coupled, and your going to spend a lot of time untangling it. I've been on projects like this, and spent a lot of time getting annoyed at the lack of foresight.

crdoconnor 9y ago
You can go overboard though. Excessively loose coupling can come at the expense of DRY (and vice versa). It's a trade off.
lgas 9y ago
The problem is that few projects survive long enough to get to the point where anyone can be annoyed by the lack of foresight... so often any foresight or effort on implementing what was foreseen is wasted effort. Often times that wasted effort contributes to the premature death of the project by soaking up resources that could've been used to implement more features, fix more bugs, etc. The question is which is more problematic, the lack of foreseeing the need to change the database or the lack of foreseeing the death of the project due to spending time on the wrong things? Personally I think having a successful project that needs the database changed is a) not a particularly hard problem to deal with and b) a good problem to have.

locopati 9y ago

We also take for granted that a lot of that work has already been done for us (e.g. JDBC or Hibernate in Java or ActiveRecord in Ruby).