I had a discussion with a co-worker yesterday about design philosophy. The other coder is more experienced then me, and I fully admit that he is likely much better at properly automating his testing, which I'm just now trying to break sloppy habits. However, it seems that some of our dispute is a philosophical issues where I'm unwilling to simply yield to his greater experience.
Generally he is a Directing programmer, who follows all of the formal approaches. He has interfaces for nearly every class and has automated tests for everything down to getter and setters on basic POJO objects. He sees refactoring as a dirty word which is a sign that things weren't written/designed properly from the start, it’s inevitable and done as necessary but everything should be done to avoid having to do it and you should feel bad when you have to.
I feel I'm a more flexible/Enabling programmer. I feel that interfaces should be used as necessary, but not thrown in until they are needed (KISS), and that it's easy enough to pull an interface out of an existing object by refactoring if you decide an interface/polymorphism makes more sense later. I also felt that, while I admit I need to be better at testing then I am currently, the level of automated tests he suggested seemed too rigors since it would take so long to implement and, more importantly, make refactoring a nightmare since I wouldn't be free to modify the behavior of any non-private method. As my requirements grow and change I find myself refactoring heavily and that level of testing feels like it would kill my flexibility. His view is that I shouldn't be refactoring so it doesn't matter if the tests make it harder to do.
Ultimately all of the other philosophical discussions seemed to boil down to the word 'refactor'. I love refactoring, I feel it should be used liberally any time you feel that something isn't quite as clean and beautiful as it should be, and that the natural course of growing a program or adding new requirements will necessitate refactoring to better enable code reuse, moving logic to new classes/packages as it grows more complex, and yes fixing inevitable design mistakes which will happen from a flexible agile development approach (and that’s not always bad if your code is written to allow modification!). He disagrees with all of that.
I'm wondering what other's thoughts are on refactoring. How common should it be? Is writing code with a philosophy of "I'm doing it simple now, I can refactor it later if more complicated logic proves necessary" inherently flawed/dangerous? Does acceptability of refactoring depend on program approach and style? I generally am on rapid prototyping or “clean up this ugly, but working, prototype some non-engineers wrote”, while it sounds like he actually gets to do formal programming with official requirements that don’t change; I’ve never once had a job like that myself!