I’m currently working on a pretty major overhaul to a custom Content Management System that I wrote for some clients, and I have found that I am both reworking the interface, and doing code refactoring at the same time. I notice that I often end up performing these two tasks simultaneously, partially because its hard to sell clients on pure code refactoring but it does have to happen, and partly because feature creep is an ever-present evil.
The question is, would I do much better to try to wear these hats one at time? would code refactoring first, without changing any features, followed by a round of feature changes result in a more manageable process? Or am I just deluding myself, thinking that something else looks better because I’m not elbows deep in it at the moment?
I think that focusing on code and interface separately sounds like a good idea, and the fact that you can consider them as separate tasks shows that you’ve done a better job than most of separating the business logic from the presentation.
Clients definitely want to see changes, though–if they check up on the progress frequently, then I suppose it is important to have a few obvious UI updates.
Unfortunately, many businesses don’t think long term, which is an important part of the argument for refactoring. The other part, which is easier to sell, is about being agile. Perhaps most importantly, cleaner code makes a developer’s life suck less. Do it for your own good, if you can get away with it, even if your employer doesn’t care. Assuming you get repeat business from that client, wouldn’t you rather spend your time programming features that actually help their business or would you rather put out fires in their brittle infrastructure all day? In the latter case nobody wins. Therefore, occasionally it is best to respectfully use your own judgment and then allow the results to speak for themselves later.
However, you can definitely get away with refactoring code and adjusting UI simultaneously (or even business logic), but you need a decent strategy to mitigate the risk of breaking things. I tend to rely on the refactoring tools, which are built into all the good IDEs now, in order to keep things clean. Historically this required regular expression acrobatics to find and replace across files, but now you can do a lot of things like rename functions & variables, adjust method signatures, or even extract interfaces (for those who like MVC and other design patterns) all without worrying about fixing up all the dependent code. Plus, I know you’re a big advocate of version control so you’re already checking your own work there via diffs (amen to Chris’ advice in his earlier post btw).