Poof and then Rails was gone

I might just not be very good at this programming thing, but to me these kinds of articles on testing often (not always) remind me of my annoying tendency to implement a comprehensive productivity approach (often combined with buying yet another task app) that, on paper, really should help me keep track of my life. Usually it's a variation on Getting Things Done, which stands out in its exhaustive, all-encompassing, fine-grained approach.

In practice the whole falls apart after a week or so because I forget to do things the right way or because I don't feel like processing my 'inbox'...

Instead, I seem most effective when I write down my top three tasks of the day on a piece of paper.

Maybe I get that feeling because I've mostly experienced companies where testing didn't really seem to have much of an effect. Whenever I asked about this lack of efficacy, the answer was usually "that's because we're not implementing it completely!"

Which is exactly what I hear (and suggest) whenever I or someone else falls off the GTD wagon.

Am I completely wrong about that feeling? I mean that as an honest question, as I truly don't want to be negative and I'm way to inexperienced to be cynical about these things :-).

Let's take a framework I know pretty well: Django.

It's not uncommon to switch from one database to another (say, MySQL to Postgres). Django's DB abstractions keep you from having to really worry about what actual database you're running on; unless you had hard-coded dialect-specific SQL somewhere, you just flip a couple settings and now you're talking to the other database.

Same for changing replication setups, for changing authentication mechanisms, for changing logging setup, for changing how you do caching... all of these are things that can and in the real world do change, either from testing to production environments or over the life of a production application.

So it makes sense to abstract those, and the abstraction is backed by "these are things people have really needed to do frequently".

What I have a problem with, and what I criticize as overabstraction, is when someone then comes along and says "well, what if you replace the persistence layer with something that's not even persistent, like volatile memory or stdout (which is actually logging, not persistence, at that point -- a confusion of concerns!)" And then they write a blog post explaining how really you should keep abstracting to the point that the code can "persist" data to those things.

And that's why I say that the examples almost always feel incredibly contrived; it's like somebody didn't know when to stop, and just kept abstracting everything they could find until they ended up with an overengineered mess. Static/dynamic actually has very little to do with this, since even languages that do static typing in overly-verbose and un-useful ways can handle the kinds of abstractions people actually use.

So I don't see a point in re-architecting for these weird contrived hypotheticals, which always seem to be the focus of whatever we're calling the indirect-abstraction-for-everything pattern nowadays; it produces code that's more complex than necessary, has more layers of indirection (and hence bugs) than necessary, and doesn't actually gain any utility in the process.

It actually wasn't my terminology... If you read the parent of my comment, the self-proclaimed complexity was, literally, "MVPs which are mostly CRUD apps". I think most Rails applications I've used defy that description, and I don't agree with that comment that it is "the entire reason for Rails existing" any more than I would agree that the entire reason for PHP existing is to make personal home pages.