“It’s not just temporary. Now that it works you’re not going to touch it because something else depends on that behavior and touching it will be far too risky. You’re probably not going to clean it up, except perhaps to put it under the bed and hope no one trips over it later.
Even on a tight schedule, last-minute block-ship bugs appear and what should have been a simple, straightforward bug fix will turn into some Giger-esque state-driven nightmare causing everyone associated with the project to invent new profanities because the ones they have don’t seem emphatic enough.
In the next release a new feature will be impossible to implement because class A has intimate, incestuous, biblical knowledge about class B. It seemed to work but the child of this relationship is going to cause you problems for the rest of its life even if you manage to separate the star-crossed classes and send them back to their families.
Chris Parker (Apple frameworks engineer): You Are Not Ruthless Enough
I’ve seen the kind of long term damage this sort of cruft can inflict on a code base many times, which is why, like Parker, I tend to believe strongly in investing the extra time necessary to design good class interfaces, properly separate concerns, and get application architecture as right as I can given the knowledge I have at the time. I think one of the biggest things my time at Apple taught me was the NeXT-ian philosophy of building applications as thin layers and thinking of the lower level code in terms of frameworks as much as possible.
