Hacker Newsnew | comments | show | ask | jobs | submit | kgrin's comments login

Global Entry is for immigration/customs, not TSA security.

The trade-off is: they do a background check and take some biometrics, and in exchange you can skip the conversation with an immigration agent where they ask you where you're been, etc. - you just answer the usual customs-form questions at a kiosk.

It's actually a pretty reasonable trade-off, and speeds the process of going through Customs - which, unlike some of the TSA stuff, is in no way unique to the US (having gone through immigration/customs in 20+ countries, I can say with some experience that the US is far from the worst...)

-----


"Software engineering estimates and plans often fail to live up to the reality that follows. It seems to be the only engineering discipline in which this is regularly the case."

Is it though? I live in Boston, home of the notorious* Big Dig[1]. While particularly egregious, it's far from the only large-scale civil engineering project that's gone off the rails. In fact, I'd argue that until fairly recently, many more public works projects shared the "surprise factor" of software projects. I'd recommend Caro's "The Power Broker"[2] for a fascinating history of NY-area public works (among other things - great book all around), including how much of that process was about adapting the plan to new things the builders were learning along the way ("oh, turns out that soil is completely different than we planned...")

That's not to say that there aren't particular features that make software engineering its own special snowflake - as there are meaningful differences between how civil, structural, mechanical, etc. engineers operate. But spend some time in another engineering organization and you'll find it's different, but not as different as you think it is.

(And FWIW, even civil engineers sometimes follow "agile" concepts - a company I once worked for was contracted to design a highway, and even after the construction started, engineers were "embedded" with the builders to make on-the-fly adjustments based on the environmental factors they discovered throughout the process... I wish I could find their project write-up, but it was a while ago and the company has long since been gobbled up by a bigger company).

* As a (subjective) kicker, I'd add that the Big Dig, over-time and over-budget as it was, was ultimately quite worth it... much like many software projects!

[1] http://en.wikipedia.org/wiki/Big_Dig

[2] http://www.amazon.com/The-Power-Broker-Robert-Moses/dp/03947...

-----


Yep, you're right... I'm forgetting that physical engineering also suffers from some of the same problems. The thing that it adds though is a level of rigour, and ability to reason about the project, that we're still struggling with somewhat in the software world. Believe me, in 20 years since I was taught it's not strict "engineering", I've yet to see that change much, other than in safety-critical and cleanroom projects.

-----


Engineering is much more straightforward, you have the plans and know that you need X amount of parts and Y amount of labour. Software is more like research, where you don't even know if you can solve the problem acceptably, most of the time.

-----


If you have the plans, it's manufacturing, not engineering.

The engineering in the design is in developing the prototypes and proving that theoretical concepts can be implemented practically. There is nothing straightforward about that, unless it is an incremental improvement to an existing implementation.

The engineering in manufacturing is about deriving ways to manufacture parts with greater yields and greater efficiency. In some cases, it is about developing manufacturing techniques that were hitherto impossible. Again, not much straightforward about this.

All of the above is rigorous, but that is not the same thing. This rigor can be applied to software development just as easily as any other product development, and when it is it becomes software engineering.

-----


I feel it's the lack of hard laws that kill software. Unless it's a very constrained project, where limits drive your design, you'll have freedom to think about things and then it shifts into ontologies, people trying to find 'tiny theories' to express their problem in the best way. Each layer adds variability and we end up in hard to bridge technology silos.

-----


Great point!

-----


EPR nuclear plants are suffering delays and far over budget.

-----


That sounds pretty much identical to Zencoder, encoding.com, etc.

-----


Sounds like speech recognition, actually - I frequently get emails from a doctor who dictates most of his emails (on mobile), and they have a very similar cadence of grammatical mistakes...

YMMV of course, but iOS/Android (and Dragon/et. al.) are pretty good at recognizing words, less so entire sentences - and remember, this is 5 years ago, so adjust accordingly (unsurprisingly, consumer-grade speech recognition has improved dramatically in the past half-decade).

-----


I kind of wonder if they're counting "Chrome" as an app, and the 8th minute is actually SMS + phone (quaint, I know). I'd believe it either way, to be sure.

-----


And yet when they don't, people decry (accurately!) the crappiness of non-"Google Edition" phones. For years now, the only Android devices truly competitive with iPhones have been the various Nexus/Google Play Edition/etc. devices - ones where Google has taken a heavy hand and enforced a more integrated (one might say "Apple-y") experience.

Indeed, early on in Android's life, Google was much more hands-off with the OEMs, letting a thousand flowers bloom... we got fragmentation and subpar devices, developers and consumers complained, and Google set forth on tightening the reins and exerting more control such that when people buy an "Android" phone, it means a particular experience. (And of course there's nothing stopping OEMs from shipping AOSP-based devices and just not calling them Android - as in fact a number have done).

-----


I agreed with you until this past year. If you play with a Nexus 5 or 6, and then you handle a Galaxy S6/Note4, LG3 or HTC M8/9, the user experience of all the of the non-Nexus devices is actually quite good and the OEMs are now allowing users to either disable or remove OEM apps & skins or skin elements they don't want. Frankly, the UX of stock Android is pretty crappy in several areas, and a lot of third party ROMs & skins improve it dramatically.

The issue I have is that if you're a non-techy user and you get accustomed the "The Samsung Way", then try to switch to a different brand device, it can be very disorienting. They practically feel like different OSes in some cases.

In addition, the current Nexus devices (5/6) are pieces of crap compared to the halo phones from the big OEMs.

-----


"Pieces of crap"? While they might have at least some features lacking, calling N5 and N6 a "piece of crap" is just wrong.

But I do agree, that OEM skins do improve some lacking features of the stock Android, they also bring in tons of dark patterns and just terrible UX design with them - TouchWiz (Lollipop) for example removes all timed audio profile functionality, brings confusing duplicated apps for pretty much all standard applications (Play Store, Google Fit, Calendar, Mail, Keep, etc.) with their own separate accounts, hides camera functionality in public API and several other problems. Not to mention a completely different design of the OS from the whole Material ecosystem.

And thats a tip of the iceberg considering the times of Android 2.3/4.0 when Google CTS tests weren't so strict and developing anything worthwhile was practically impossible since OEMs kept overwriting even default integrated themes - stuff like setting black text to be white, removing fonts and other fun stuff we had to deal with.

-----


Lollipop turned Nexus devices into pieces of crap, specially the N5.

-----


I disagree - as a longtime Verizon Wireless customer & former Android user (~~6 users), I constantly have seen crapware pushed down on Android phones. Phones like the Nexus series are not available on Verizon, and I happen to be on a legacy family plan ($40/month/line, unlimited data), so the only option for (relatively) crapware-free phones is the iPhone.

Samsung phones have been degrading in quality as well - screens have become more fragile, Samsung has focused on copying Apple in many ways, and probably most damning, the market has responded negatively to these more recent changes.

Give me a more spartan device like the Nexus 5 over that crap any day. Google had it right, but unfortunately has been blocked from bringing that experience over wholesale.

-----


I completely agree about the difference between OEM versions of Android. The home and back buttons on my HTC One M7 are on opposite sides to those of my wife's Galaxy phone. What I don't really know is at what point the OEMs have enough freedom to let Google be out of danger from the EU.

-----


Err... what's a plausible reason passwords would be restricted to 20 chars, other than being stored in plaintext in a char(20) field?

-----


Making sure you can't DDoS by sending gigabyte passwords for the server to hash. Of course 20 is seriously … overprotective.

-----


Pretty sure nothing's stopping me from sending a gig of data to their server anyway.

-----


No, but hashing is much more intensive than just receiving it.

-----


I'm doubtful that it's a billion dollar industry. As a prior commenter noted, shippers will likely raise rates to compensate (particularly when you're a large shipper, rates tend to be negotiated anyway), or adjust policies to make refunds scarcer.

It may be a clever hack for a few early adopters, but is likely to be somewhat self-defeating if/as it grows. (Though in fairness, "shipment auditing" is a much bigger and more interesting play than refund harvesting specifically).

-----


It may be a clever hack for a few early adopters

There's a number of companies like Refund Retriever (disclosure: I'm the Director of Technology) that have been doing this since 2006.

-----


AWS CodePipeline and AWS CodeDeploy (both announced simultaneously I think)

-----


Indeed it did... thanks for the sharp eye, will fix!

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: