[chooseaname]

It really depends on what you're doing.

If you're writing code for a device that's going to hang out in the forest for 10 years with no updates, write just enough code to solve the problem and make it easy to test. Then test the fsck out of it.

If you're writing code for a CRUD web service that you know will get rewritten in 10 months, write just enough code to solve the problem and make it easy to test. Then, test the fsck out of it.

If you're writing an Enterprise app that will be expanded over the next half decade, write just enough code to solve the problem and make it easy to test. Then, test the fsck out of it. You simply cannot know how your code will have to change so you cannot design an architecture to make any arbitrary change easy. Accept that. The best you can do is write clean, testable code. Anyone... anyone who thinks they can design a system that can handle any change is flat wrong. And yet... time and again, Architecture Astronauts try it.

[qes]

> You simply cannot know how your code will have to change

Nonsense.

Of course you can make reasoned predictions about how your software will change or not in the future.

Some will be wrong, but if you have any sense many will be right enough to have been worthwhile to address up front, and the balance will be clearly positive.

[aantix]

What are your thoughts on the habit of wrapping virtually every recurring piece of code in its own method? In case the implementation has to be overridden?

E.g.:

def current_time

  Time.now

end

vs. just repeating Time.now inline within all of the calling methods?

[chooseaname]

> In case...

When it happens, deal with it - odds are it won't. Expend the energy making the code base testable not pretending to be an insurance company ("In case sh..").

[wry_discontent]

I don't really want to disagree with anything in here, this all looks good.

But I think it's silly to imagine that there's nothing you can do to anticipate changes and make your code more amenable to change.

[AnimalMuppet]

The problem is the changes you anticipate often are not the changes that happen. Those anticipated-but-not-happening changes waste your time, and also clutter up your code, getting in the way of the changes that do need to be made.

[chooseaname]

> ... make your code more amenable to change.

This is where "make it easy to test" comes in.

And, sure, there are some things that are easy to anticipate. If you're processing CSV, you may get asked to process arbitrary delimited files next. But the point is 3 - 5 years out, you'll get asked for something the current architecture cannot support and a major effort will be required. You cannot anticipate those and thus should never try to.

[dynamite-ready]

I want that on a poster.

[cheez]

I see what you did here.