This is the kind of mistake that burns so badly. You find yourself saying something like "You mean you just ask them to update their location manually and that works?"
It reminds me of when Ballmer was bragging about how sharing songs via WiFi on the Zune could get you a date. Then Steve Jobs recommended simply giving one earbud to the girl.
The differencing between trying to untie the The Gordian Knot and taking a sword to it.
This probably holds true for a lot of examples of companies that solved the wrong problem. When your competitors can evaluate your progress, it's much easier for them to position themselves according.
(It will be interesting to see how things change with OS4's background processing. I'd guess users will continue to prefer for check-in based over continuous gps logging, though there may be some interesting/appealing applications of continuous logging. Haven't really looked into the specifics yet.)
Not to disregard or in any way invalidate your point, which has been taken, but did Steve have a solution for the possible ear wax issue, or does his famed reality distortion field extend to ear wax as well? I'm generally not keen to use anyone else's earbuds, nor am I keen to lend mine to anyone else (and they're not even the kind that you need to wedge into your ear).
Um, what?
I am failing to remember who said: the perfect racing car falls apart the moment it crosses the finishing line - all others else are over-engineered. The point is that good engineering is appropriate engineering. All the things that PHBs sometimes think off as the geeks going off on their own obsessions - maintainability, clarity of design, low fault tolerance, high scaling ability - these are either good engineering or over-engineering depending on the stage of the lifecycle, the purpose of the project (air traffic control systems anyone?), the future staffing estimates and so on.
For example in my own area of acedemic-(ish) software engineering, maintainability absolutely trumps delivery dates. Clearly, if you are chasing ramen profitability, it may not.
Context matters.
http://forums.autosport.com/lofiversion/index.php/t63818.htm...
The best solution is the simplest one which solves 80% of the problem. Very important when creating a minimum viable product.
How is this counteracted by asking whether they would build the product the same way were they to start over? It seems it would do the opposite: Bring all the warts to their attention and make them rewrite the code even though it works perfectly well.
