Monthly Archives: August 2008

Obsolescence and obscurity in digital cameras

Blog, , , , , , , ,

University Hall Tower at OWU I’m planning on buying a new DSLR, and as I looked through old photos from college today I started to think about my first digital camera, a Philips ESP50.  Here’s a page with some specs, translated from German.

I remember buying the camera, logged in to eBay from my parents’ house late at night the day after Christmas.  I think I ended up paying something like $250 for it.

This was before the megapixel war, when 640 by 480 was considered a viable resolution.  This camera applied tortuous levels of JPG compression to fit images on the 4MB disk.  At the time, though, it seemed like a good deal.  Film cost money, and developing film cost money, and most of the year I was a ramen-noodle-eating college student.  Probably the biggest reason to go digital was the tiny little screen on the back – you could actually tell if you got the shot, instead of waiting to get back a bunch of blurry prints.

The camera is painfully obsolete now, and even then it was somewhat obscure.  The thing is, the Web was a pretty amazing place even back in 1998 – there were lots of web pages about this camera.  I remember reading at least a couple reviews, and searches for it on WebCrawler or Alta Vista or whatever I used back then came up with retailers, other auction sites, etc.  Look for information about this camera now, and it seems that it has been largely forgotten:

And that’s about it.

I wonder, is this the destiny of all cameras?  Will I do a search for my Nikon Coolpix 5700 in 2014 and come up with just as little, or has the Web expanded so quickly that the copious product reviews, blog posts, and technical discussions on photography forums outweigh the force of entropy?  I wonder if the Internet has gained any stability as it has matured – do pages tend to stick around longer, or is linkrot a constant of the universe?

Future generations will hardly feel deprived if they miss out on information about some crappy old digicam.  Still, you never know what kind of information will end up being useful to someone at some point, and this same problem extends to all the information on the Web – from reviews of obsolete products to the human genome.  If a website goes under and deletes a thousand blogs, it won’t exactly make the news.  But our great-grandchildren might look at that stuff the way we look at letters from the Civil War.

The only solutions I have are more effort behind projects like archive.org, increased data portability, and rational intellectually property laws that don’t make saving 70-year-old content from deletion into a federal crime.

For discussion, how do you deal with ancient equipment, keeping around old web content, or even archiving old email?

The most difficult problems you will ever face as a programmer

Blog, , , , , , , , ,

Niagara Falls and city lights at night I was given a problem to solve at work earlier this week and I pretty much totally choked.  To be honest it wasn’t that hard of a problem – I obviously can’t share it with you here, but I will say that (among other things) I completely, totally blanked on how to find if two lines on a plain intersect and didn’t have a laptop handy to look it up.

This bothered me all week and got me thinking about my career as a programmer and the kinds of problems I’ve been asked to solve.  Everything we do as programmers, developers, or software engineers boils down to solving problems–so what have I been doing all these years?  Finally I realized that of all the difficult problems I’ve worked on in my professional career, most of them were difficult because of:

  • Imposed constraints;
  • Convoluted business rules and vague requirements;
  • Political or organizational issues; or
  • Human factors.

That last type of problem I actually really enjoy working on, but let’s put that aside for the moment.  Notice anything missing from that list?  Only rarely have I encountered problems that required really complex logic, difficult algorithms, or lateral thinking.

Why is this?  Have I shied away from those sorts of problems, or been unable to hack it?  I don’t think this is the case.  I did well enough on the SAT and GRE, and I can usually get myself back up to speed for solving logic puzzles in a week or two.  My guess is that my career is pretty typical, and that most of the problems that most companies face are due to constraints, vague business rules, organizational issues, and human factors.

This flies in the face of the kind of education most of us get as programmers.  At OWU the computer science department always erred on the side of math – we spent more time on concepts than practical applications.  I really, really value the kind of coursework I had in college but when it comes down to it, I learned just two things that I use on a regular basis:

  • Basic concepts and common programming paradigms; and
  • How to learn new languages, programming paradigms, etc.

I really enjoyed discrete math, but have rarely needed all the combinatorics.  Hacking scheme in my AI class was very cool but that’s the last time I’ve done any alpha-beta pruning.  I have successfully solved problems with some relatively mundane insights:

  • Don’t rely on memory, take notes and find references.
  • Look for low-hanging fruit.  Does the database even have indexes?  Do you really need to debug 2,000 lines of Javascript that essentially reimplement the concept of linking?
  • If you ever have a technical quandry, you’re probably not the only on in the world with the same question.  Chances are one of those other people has already asked the question somewhere on the web, and with a little luck someone else has already posted the answer.
  • Don’t get involved in political struggles between teams and don’t play the blame game.  Be unerringly pleasent in contentious situations, and if someone agrees to something in a meeting follow up with and email or some kind of documentation.
  • Prototype and iterate, people tend to use vague terminology and don’t always want exactly what they think they want.

So, if you’re going to end up implementing shopping carts or interfaces between large internal systems most of your career, why bother with brain teasers and algorithm interview questions?  Does this mean all that fancy book learning should be thrown out the window?

…

No!  Of course not!  If you do, when a really juicey problem does come along you’ll choke like me.

I’ve come to the conclusion that I need to make a concerted effort to look for problems that are difficult not because I don’t have enough time to do them, or because the two teams involved hate each other, or because the business analyst said “X is always Y” when he meant X is usually Y.  My guess is I’ll be hit with some soon at work.

In the mean time, got any good logic puzzles?  Textbook problems?  Favorite websites?  Feel free to post them in the comments below to get me started.