Interesting .. my current contract involves writing ETL scripts (or, as we call them in the trade, 'data-munging' scripts) that take a variety of input flat files, split them up into fields, re-organize the data in the fields, and write the result out to a variety of flat files, until some mainframe folks figure we have a match. That's the Perl development part.

My scripts don't go on to live on any production system, however. My actual deliverable is the documentation, in Excel spreadsheets, showing the input records, the output records, and the transformations for each of the fields. And it's an interesting switch to go from writing logic in Perl, to describing these transformations in pseudo-code. It really is a different skill set.

My guess is that your battles with products are the result of siloed development. As opposed to my situation, where I'm coding and then documentating, I imagine that engineering builds a User Interface but never use actually it, not do they have Marketing test it. Maybe it's because there isn't time, there are no resources, or any other reason that you can think of. Then the manual writing team fiddle with the prototype unit and write something up, but they don't actually use the unit either. Everyone probably blindly imagines that setting the clock is something that gets done once, upon installation, when the packing materials and manual are clearly to hand -- and if it takes 10 minutes, who cares or remembers that pain.

I think the problem here is that everything insists on knowing what the current time is, rather than having things networked together so that part of an appliance power-up sequence would be 'Go get the current time/date from the local ntp server', solving issues with power outages and Daylight Savings. Unfortunately, that scenario doesn't fit with the lowest common denominator (yet), so we have several different appliances, all with their own unique way of setting time.

At least some of the devices are grown-up and can handle this sort of situation. :)