I agree with Jeff's general statement "don't reinvent the wheel, unless you plan on learning more about wheels" but I think it's important to keep in mind the c

I agree with Jeff's general statement "don't reinvent the wheel, unless you plan on learning more about wheels" but I think it's important to keep in mind the costs of going to a higher level of abstraction as well. Every framework I've used claims to improve productivity, and they all ask why you'd want to reinvent the wheel rather than use iBatis or or Hibernate or JPA or EJB or Spring or Guice or GWT... Some of these frameworks actually deliver on the promise of increased productivity. Others don't at all. A few do help once I've learned them, but aren't worth the sunk cost (ie., they do improve my productivity once I've sunk 200+ hrs into reading and configuring, but not enough to offset the time invested). One reason I like "low level" coding is that I know I can get the job done in a straightforward manner. It'll take a lot of typing, and it may be tedious, but so is dumpster diving through log files to figure out why the "wheel configuration file" isn't finding the "lug nuts" tag, only to then discover that volvo v90 has only been compatible with the deprecated version of the hubcap plugin ever since Ford stopped contributing to the "tricked out rim" facade. "Trivial" doesn't mean quick and easy, it just means that conceptually, you can see a path from here to there that doesn't have any serious question marks. In this sense, reinventing the wheel is often "trivial". Let's not understate how much time a programmer can lose by trying to make sure he doesn't lose time by reinventing the wheel.