CES: Worse Products Through Software (2013)
hypercritical.co
hypercritical.co
Frankly anything close to hardware, up to and through the driver layer, has a real tendency to barely perform as required. It really seems like if it works enough to show someone it looks like it's working they stop, but we've all seen this attitude applied to higher levels of the software stack, except there it's easier to deal with.
The single most telling gadget here is the Chromecast, which successfully nullifies most of the point of smart TVs for <$40, while providing a user experience none of the TV makers got close to.
The auto manufacturers, in particular, seem to expect that I should be paid about 2/3 my current salary to physically relocate and then work 45-hour weeks for them, if they even have any software jobs in the US at all.
To them, writing the software is like adding an extra cup holder.
Last time I checked iphones and xboxes and tivos were hardware. If every hardware maker with good software is a software company, and only the hardware makers with bad software count as hardware companies, it's by definition true that hardware companies can't make good software.
--Robert Metcalfe
Speaking as a software guy at a hardware company for TVs, one of the challenges is that there isn't a cohesive conversation between the hardware designers and software engineers.
On more than 3 occasions I could name off-the-top of my head, we've had to write workarounds or re-architect entirely for missing or over-promised performance of the silicon.
Likewise, some very useful features have been scrapped because they would add $1.00 onto the cost of a unit. While I get that 1 million units x $1.00 adds-up, the conversation about how this could either make a better product or that subsequently spending 2 million in software maintenance, isn't cheaper---is missing entirely.
This is a familiar refrain from other jobs and other engineers throughout the custom hardware industry. This doesn't even scratch the surface of how software engineers are essentially held to hardware engineering deadlines regardless of the complexity of the software they're being asked to produce.
Most new models, it seems, have the so-called "smart" features, but it's harmless if you don't connect it. I just use a TV as a big monitor - plug in a PC and use a wireless keyboard from the comfy sofa.
More curious is why the TV and monitor categories haven't converged. Eventually I predict, they will, when demand for OTA tuners fades and "cord cutting" (as the cable TV industry calls it) goes to higher percentages.
See here: http://5by5.tv/hypercritical/16
Also, see here for details about John's "Journey"[0] [high fives self] researching and purchasing a TV recently:
http://atp.fm/episodes/43-brilliance-enhancer
[0] - If you've listened to John discuss video games recently, you'd be high fiving me too :-)
[1] http://www.monoprice.com/Category?c_id=113&cp_id=11307&cs_id...
It's even worse when the random track is not even produced from a good pseudorandom number generator. In order to preserve the back/forward button functionality, the "random" selection may be seeded as a function of the current track number and the system clock date. So you end up with a choice between the native playlist and the player's playlist of the day.
The only reason I can think of for making your hardware do such things is that you don't care about the user experience as much as you care about the $0.15 cost per unit it would take to make the function work in even a 3/4-assed way.
We have one guy on our software team that this describes. The rest of your post is condescending assumption that ALL of us have the unix beard and vim editor of that one dude. Paradoxically he is one of the iPhone owners in our Android heavy group. In conclusion, I guess I've never really worked with programmers before.
The CLI makes it easier to force developers to separate the functionality from the user interface. You still might have the guy that puts all the code inside Main( string[] args ), obviously, but at least that code is easier to test.
Just like removing the presence of alcohol from the alcoholic may allow him to resist temptation and become a better person, removing the GUI from people with bad GUI coding habits may allow them to resist temptation and write better code. But maybe not.
It also helps you discover who actually knows how to write software, and who is dependent on the development environment to erect all the scaffolding for them.
The software companies that produce the best UX don't do so because there's a "draconian master" forcing the programmers not to just have Macs boot directly into Emacs and give users electric shocks when they click the mouse button. They have teams that are actually interested in UX design. Everyone I've met doing engineering at Apple cares about this sort of stuff. And while I'm sure there are programmers out there disappointed that their Android phones don't boot into console mode, none of those programmers are people on the Android team who have only been held back from doing so by the Iron Fist of Sergey.
I think there may be economic factors too. Isn't it true that TV replacement rates are low and they have low margins? Given the longevity of displays, why would anyone want to bundle in hardware/software with faster refresh rates?