Make vs. Buy

When I have some project I'm working on, I will often err on the side of building things that I really should try to just buy pre-made.  The most recent example of this was when I wanted to wall-power a canon point and shoot camera that I've had lying around.  I wanted to do some time-lapse experiments with it without worrying about the batteries dying.  I went to HSC and rooted around in the barrel connector bins until I found one approximately the right size to fit the DC input on the camera.  Then I rooted around in my box of AC adapters at home, until I decided I didn't have anything quite right, so I headed back to HSC, and bought a regulated supply of the right voltage.  But then I discovered that the supply I bought couldn't meet the peak current requirements of the camera.  So I started thinking that I could just use a higher current, higher voltage power supply, and built an additional switching regulator circuit to get the proper voltage at the current level the camera needs.  At this point I was several hours and probably $20 in gas and parts into this project.  What I *should* have done, right at the start, is gone to eBay and searched for "AC Canon Adapter A540".  When I did that, I found an electronics import-export company that sells a third-party equivalent to the Canon AC power adapter for $11.49, with free shipping.  I ordered one, and had it later that week.

The inclination to build, even when I should just buy, is related to the inclination to tinker, and a desire to know exactly what's going on inside the box.  If I buy a power supply, I get a few high level specifications.  If I build it, I know EXACTLY what's going on in there.  But the cost of the time spent being a control freak far outweighs the likely benefit knowing all the details.  Indeed, most complex systems simply can't be understood, in total, by one person.  There are some polymaths that come close, but most significant advancements come by building on the existing hierarchy of infrastructure, and driving deep into one area of specialization.  Of course, like all things, there is a balance to be maintained.  Good software engineers understand enough of the conceptual internals of a compiler to know how to avoid writing pathological code.  The don't necessarily know all the details, but they know the parts they need to know.  And that's another trick: figuring out which are those necessary parts.

And to borrow a line from Forrest Gump, "That's all I have to say about that."  I could delve much deeper into this topic, but I'm kinda tired, and want to catch up on my sleep. Goodnight.