Applying good coupling and cohesion principles is not obsessing. It's as much legitimate programming as writing an equality test.

Perfect programmers may manage to avoid duplicating code on the first try. But unless we have dozens of Mozarts posting here I'd guess that no one qualifies. That means we make mistakes, and the question of whether correcting those mistakes is good practice or obsession depends on the circumstances.

I think from your comment, we can agree that there are two scenarios to consider: when the programmer is in control of the product and when the schedule is in control of the product. "Programming is not always so time-and-performance-sensitive, but it's not time-insensitive either."

Here's the deal: when you stop your design process and kick the compiler up and start coding, you haven't stopped your design work at all, you've simply switched from top-down to bottom-up design. Every line of code you write is a validation/denial of the assumptions and planning you're supposed to do before you start. If you're not refactoring aggressively as you go along, you're not taking the chance to see where your code is supposed to be going: you're simply trying as hard as you can to get to point B from point A. It's like driving a car from one side of the field to the other by letting go of the steering wheel and hoping it gets there okay. Most of the time you make it to the other side just fine, but you have zero control over where on the other side you're going to end up.

To me, that's hacking, and I mean in a bad way. I've been known to hack like a freaking electric weed-eater, trust me! But that's when something else is out of whack on the project. It's a sign that there are serious problems. When you're doing it right, your code is constantly evolving as you refactor to the point where changes become less and less of an issue. So good programming means you spend all the time necessary to refactor with the knowledge that you'll going to make it back in spades later on.

It's like when playing rummy, and you decide to pick up a huge stack of cards. At first, it seems like a crazy move, but if you know how to play the game, you realize that the only way to win is to constantly redefine the problem domain of what you have in your hand. Hacking doesn't get you that -- it just gets you to point B no matter what. It may not be the sign of poor programmer, but it's definitely a red light that something is out of whack somewhere.

My opinion only. Your mileage may vary. Do not attempt to drive heavy machinery after reading my comments. Consult a physician before beginning a regimen of refactoring. Etc.

A simple dilemma:

You have to perform an operation in C that accepts up to 5 parameters and will be executed when a given 50 input sets are found (out of thousands of possibilities).

You can write one function that accepts variable parameters and paste it into the code for each of those 50 conditions. (Assuming you know how to do that in C to begin with -- I don't, actually)

Or you can write 5 different functions for each possible number of parameters, with some duplication in each function. Or you can write one function with 5 parameters and just pass 'NULL' in the unused slots and test for it inside the function.

Or you can come up a few meaningful sub-categories and write 15 different functions that also handle some processing that would otherwise happen further down the road.

Or you can write 50 different functions that correspond to each input condition, that do mostly the same thing at this point, but in the future if you needed to change any particular input set side-effects will be limited.

How do you answer this question without being able to see the future? (And, is it even worth worrying about, when any of the answers will work?)

For you, maybe. But what about the guy who applies enhancements 3 years later and has trouble getting through testing because the exact same code was somewhere else and difficult to find because of the 67 mods since then.

Minutes "obsessing" today usually saves hours testing tomorrow.

This also squares with a lot of IBM's experience in The Mythical Man Month, i.e. code needs at least three clients to really be reusable.

True, but the app has to make it to tomorrow for testing to matter at all. It's better to be in the championship trying to figure out how to manage a tired team, than it is to conserve energy during the semifinals and wind up sitting in the bleachers.

Doing things according to effective established principles saves a little time today and a lot of time tomorrow.

Quick and dirty usually ends up being neither.

I don't have that idea. There is sometimes, though, a tradeoff between current needs and future needs; and that tradeoff can not always be predicted. When that happens, it's logical to give current demands priority.

I can't for example, predict whether a future maintainer of my code would prefer code written with multiple returns, or code that sets temporary values, or code that uses a set of nested ifs, or code that assigns function pointers to a matrix and calls code based on the indices. Each technique has potential drawbackss in terms of future maintainability, likelihood of errors, and speed of immediate implementation. Trying to guess what a future coder (other than myself) will think is just not important in that case.

Effective Principles can only be Established based on a given development environment, and it's the responsibility of those in charge of the environment to make sure the established principles are effective and followed by the developers.

The fact is, there's almost always a trade-off between "quick" and "right". That's why so many people choose the former, to the detriment of the latter.