Creeping Elegance

From ExtremelySpoiledChild:

What a program wants is elegance. What a program needs (in order to fulfill its function in life) is robust functionality. IMHO, spoiling a program is over-refactoring it, producing CreepingElegance?.

I'm not arguing against RefactorMercilessly. RefactorMercilessly works very well when coupled with producing customer valued functionality. Without that, I can refactor a program for five years. I will then have the tightest, fastest, least buggy five-year-old program in the world to compete with state-of-the-art software. Guess which one gets picked - it ain't mine. -- RobMandeville

I agree that CreepingElegance is a symptom if you always do what the code wants; and I'll agree that its better then the mess caused by neglect (when you don't listen to the code at all). But the real problem I was attempting to highlight is that the code's definition of elegant is not always consistent with human psychology. A state table is a simple, cohesive, thing. When you try to implement it, the code tells you that it wants to split it over multiple classes. Many of the GOF patterns have this fragmentation listed as one of their negative consequences. The use of MetaRefactoring may not be what the code tells you it wants, but it may be what it needs. -- DaveWhipp

CreepingElegance, traditionally defined, is the tendency of independent developers to add functionality not needed by the actual customers. ... often a problem in tools made "by developers for developers" - each person working on the program adds more random features, until you have a big mess. -- JeffGrigg

isn't that CreepingFeaturitis, a different beast?

I would be careful about equating unneeded functionality with elegance, and mixing elegance of function with elegance of implementation, too.

From a user's point of view, an elegant system is one that is both simple to understand and powerful to use. Strictly speaking, code refactoring should have no visible impact on this. From a developer's point of view, an elegant system is one that is both simple to understand and simple to extend. Code refactoring should have a highly visible (to developer) impact on these, or it's not "worth doing".

When you decide what's "worth doing", don't you have to know what else is in the queue?

I give a different significance to CreepingElegance than the one presented thus far. When management is too brutal in its demand for function and schedule, the only way to get adequate elegance into the code is to "creep" it in there. A subversive mode of keeping your code maintainable and your company in business. -- WaldenMathews

May be, but I'd argue that that's almost immoral - management should be forced to live with the consequences of bad priorities. -- DanielKnapp

I like Walden's interpretation. As for morality, how do you feel about signing your name to a piece of inferior work just to spite your management? Do you have pride in your profession? -- RandyStafford

I have a great deal of pride in my profession, but I still think that management should get what they ask for - it's the only way you'll teach them not to. I would try to talk them out of it first, of course. If it came to that, I would probably not want to sign my work if I judged that I could have done it much better on my own, but few commercial programs have credits lists in any case. -- DanielKnapp

I tend to find that if I get caught making the code better I get reprimanded for 'not doing the work I'm supposed to be doing' so it's often a no-win situation. "we don't have time to write quality code" gets bantered around too much for my liking... -- JustMab

View edit of December 11, 2003 or FindPage with title or text search