Ooh, here's an idea to improve bicycles forever! Your gluten are really good at pushing down but you're right, pulling up and over is a weakness for many people. What if - I know its crazy but stay with me here - what if we connected the two pedals so that instead of being independent, a tiny amount of the force that you push down with your big muscle groups could be used to help the other leg get into position for the next stroke?

I'mma gonna patent this right now. It'll make million$!

That's why the article didn't suggest not using them. It suggested only using a few of them at a time, backfilling with boring, well-understood technologies, so that you're not betting the farm on a house of cards when nobody's making you do that.

The odds that your business problem requires or can even benefit from a brand new language (that you can't hire for), a new storage system (that you can't find dev-ops support for in your data center), the latest methodologies (that nobody knows, hello training cost), et cetera, all at once, is just ridiculous.

And indeed, when MongoDB first came out it had all sorts of issues living in production environments. Now, on the other hand, its well-understood, the serious bugs are fixed, and its ready for casual users. How long would it have taken you to get everyone (including dev-ops) up to speed on MongoDB as opposed to actually building product over MySQL until (as it is today) a competitive solution was stable and "boring" enough?

If handling data elegantly is your company's selling point, then maybe its worth innovating on your storage engines and being on the "bleeding edge". If that's the case though, the article is suggesting that you don't simultaneously innovate in your development language, source-code storage system, and business model. That's all.

Yes, and I'm actually on board with that (although I'd have picked Salesforce if I'm just blind-picking out of a hat).

If you're just the average 20-80 person software shop - somehow refusing to believe that the (literally) millions of businesses running on platforms like Lotus Notes or Salesforce are doing alright and that your business is so terribly revolutionary that its better to spend hundreds of hours deciding-on, deploying, customizing, and supporting your own specialized CRM is a better use of your organizations time than spending those hundreds of hours on making better products and selling them to people for money, well then, I suggest that you're part of the problem.

It's the same reason that your own small company should be trying to implement its own CRM (assuming that's not its core business), or drastically changing the way that it considers sales compensation. Being revolutionary in one area is hard enough - don't make anything even harder than it has to be.

Seriously. Good, readable names for everything make code far more self-documenting than otherwise, don't cost the compiler a single cycle, and make it far easier to understand when someone comes across it five years down the road.

Other than that, I'd add methods that only perform one action, with no side effects, and that only work at one level of abstraction.

Finally, code that matches its method name - don't say "if thing.checkValues()", say "if thing.isValid()" - and if isValid() does anything like trimming whitespace it should do it on its own transient copies of things, since its not obvious that the method would ever change state.

And so on. It all boils down to code that doesn't surprise you.

Have you ever read Programming Pearls? Full of great examples of how to do elegant work with no resources that apply just as much today (just prepend "giga" to all of the numbers they use). From your comment I think you'd enjoy it.

Having a very lightweight laptop get the same performance as a high end desktop is still newsworthy, isn't it?

Or they can just introduce a slipstream charger adapter so that you can plug the power cord and the monitor cord into the same thing, leave that on your desk, and only connect one cable when you get home. And once monitors start supporting USB-C natively, they'll just do the same.

Just as with dropping PS/2, floppy drives, and optical drives, someone always has to go first.

Keep in mind that the target audience for the Macbook is far less likely to use an external monitor, or even to plug it in at all during the day (made possible by using that port space for more battery).

Other than putting the first mass-market GUI onto a UNIX product that people could actually use, giving us the first real "year of *NIX on the desktop" ever?

Oh, and redesigning the mobile phone (go back and watch the iPhone launch keynote and remember just how much was new, even things like "visual voicemail"?

Launching products that look obvious in retrospect yet were somehow not readily available before is a mark of good design.

Yup, which only had standing because Apple started to include sound support as part of the OS in the Mac. There's a reason that Apple named one of their sounds SOSUMI after all.

They're also incurring a shit-ton of liability in storing magstripe copies - something that's a PCI violation however you interpret the standards. That means that in the case of fraud the cardholder (phoneholder?) will be considered liable instead of the bank or merchant, and as soon as that happens the inevitable class-action lawsuit against Samsung (far more lucrative than going after LoopPay would have been) will be a doozy.

Google also insisted on getting in the middle of the transaction with their Wallet, and if my understanding is correct the results basically ended up providing an inferior experience to merchants since the cards ultimately got recognized as card-not-present. Apple on the other hand worked closely with everyone in the chain rather than trying to muscle their way in. If you're a merchant, the difference between paying card-present and card-not-present is often around 1% (because CNP has a lot more fraud associated with it). Apple's use of tokenization adds more security as well - its just a better thought out system.

Having said all that your point about the launch country was also completely valid. Again, Google tried (IMO) to be far too arrogant for their own good.

In a lot of ways its similar to the 3G issues. Many dinged the original iPhone for launching without 3G at a time when that was cutting edge and not very well supported. Once the iPhone 3G came out, all the issues had been resolved and it was a very smooth experience for users (and had been done in close partnership with AT&T). Some other phones had loudly claimed 3G before then and often had frustratingly poor network connectivity, sometimes amusingly slower than the iPhone's 2G had at the same time.

System integration: its important in all sorts of areas.

Its really aggravating too that US banks will refuse to offer chip-and-pin even though they could. Chip-and-signature is better than magstripe but its still a royal PITA whenever you travel in Europe.

Their PCI wording on the website is intentionally deceptive, I feel. When asked about PCI they talk specifically only about the fact that their datacenter is compliant in the storage of card numbers.

Its strictly against PCI requirements to store trackdata in any way, with the single exception of reading it in-memory and relaying it upstream to another PCI compliant service provider. Since this is exactly what their product does, I fail to see how they can claim its compliant (and, as I mentioned, they very carefully don't ever actually say that it is).