Here are two related articles (by Mike Mooney) where I found myself agreeing with every point and feeling relief that others have come to the same conclusions as I have over the years.
The Framework Myth says you don’t need an internal omnipotent framework. I agree – over the years we have built up a small collection of re-usable code, based on experience of actually needing that code in our situation. Coders love to code, and I have to admit feeling a thrill at writing my own APIs but “you are probably not getting paid to fulfill your dreams, you are getting paid to write the damn code.”
Reusable Code is Bad is a headline in the tradition of hyperbolic blog post headlines, but “never build something to be reused until you actually have two systems that actually need to reuse it right now.” is something that makes sense to me.
Crucially, I think, everybody’s situation is different so you always have to judge for yourself. But as I look back over a decade of projects, how much unused reusable code did I write? How many times did I sweat over whether to take the time to “add another layer of abstraction and logical branching to my function” and how many times was I wrong when I decided to? Less and less as experience has taught me not to.
You should understand the principles of code reuse, no doubt, but learn to use your own judgement in your current situation. As with all advice, just because Google/Facebook/37 Signals/some-guy-with-a-blog says it’s a good idea, doesn’t mean it is for you.
This was an interesting observation. I’m not a coder, I’m an Instructional Designer and my profession has a similar philosophy of “shareable content objects” meaning you can put a bit of training from one course in to another, blah blah blah…always thought it was bull–and could never figure out how it should work. I do some actionscript writing and I do find that I am able to leverage what I’ve done in other projects into current projects, but not in situ or en toto — the same with training materials.