Cryptocat for iPhone and Android – Call for Review - <AUTHOR> https://blog.crypto.cat/2013/12/cryptocat-for-iphone-call-for-review/?nocache <comment><USER2> You know that using a .cat domain for something not related to Catalan culture or language is not allowed by the conditions established by ICANN and Fundació puntCAT?

You have only translated the main page (with Google Translator...) to make it look like you have some Catalan content there. That's naughty.

"In order to be granted a .cat domain, one needs to belong to the Catalan linguistic and cultural community on the Internet. A person, organization or company is considered to belong if they either:[4]

      1. already have content in Catalan published online.
      2. have access to a special code (sometimes called ENS), issued during special promotions or by agreements with certain institutions.
      3. develop activities (in any language) to promote the Catalan culture and language.
      4. are endorsed by 3 people or 1 institution already using a .cat domain name."

Read more about it: [http://en.wikipedia.org/wiki/.cat](http://en.wikipedia.org/wiki/.cat)

<comment><USER3> I've always wondered what is so special about catalan? Why do they deserve a special three letter domain nobody else has?

Who should I address a letter to request for the wayuu culture to have a .way tld?

<comment><USER2> The thing is, the Catalan community has a very strong presence on the Internet.

As an example, the Catalan version of Wikipedia currently has +400.000 articles, being the 17th biggest.

To make clear what this means, you have to know that Catalan isn't even under the 100 most spoken languages worldwide (it has about 7 million speakers). So there is 1 article for every 17.5 people. Compared to the English version (4.4 million articles, 700 million speakers = 1 article every 159 people), or the Spanish one (1 million articles, 460 million speakers = 1 article every 460 people!), it is quite impressive.

So why would they want an own .cat domain? Because as a non-independent country / nationality, they are not allowed to have a two letter domain. Still, they wanted to be represented on the net so there was the PuntCAT foundation which did a huge effort in order to obtain the three letter .cat domain, but as it was sponsored, I imagine that they decided to restrict the usage of it to websites that have something to do with Catalan culture, or at least are written in Catalan.

I must say the Catalan culture and political movement is a pretty interesting topic itself, but I didn't want to make this post political, but rather interesting for "teh techies".

<comment><USER4> Provinces can get ccTLDs - Taiwan has .tw.

Sponsoring and getting .cat is a pretty cool workaround, though.

<comment><USER5> Can provinces really get ccTLDs? I thought .tw existed because Taiwan has an ISO country code: [http://www.iso.org/iso/country_names_and_code_elements](http://www.iso.org/iso/country_names_and_code_elements)

Having said that, I'm not sure why the UK (whose country code is GB) uses .uk

<comment><USER4> IANA considers .tw to be "Taiwan, Province of China", as does that ISO link. As I understand, China pretty much bullied everyone else into not recognizing Taiwan so the rest of the world (like the UN) agrees Taiwan isn't a country. That's why one reason Microsoft asks for your Region, not country.

There appear to be other ccTLDs like .IO and .AQ that aren't countries. (Probably more.)

And I'm just being pedantic.

<comment><USER5> Both IO and AQ are ISO country codes as well. I'm not sure why.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Easy to be snarky about this. But I admire their persistence.

In the face of the extensive criticism they could have just given up.

Instead they have acknowledged making mistakes, didn't give up, learnt from the mistake and changed their subsequent behavior. This is admirable.

<comment><USER7> Compare them to underground dentists -

Bob has no medical training, but has a dremel and practiced on a pig head. He offers to do a filling for his pal. He makes a bit of a botch of it, but he larns from his mistake and carries on. Dentistry is important so it's admirable that Bob ignores the criticism. Bob's first pal is currently fighting off a severe infection, but Bob uses that as a learning experience.

Bob will get there one day!

<comment><USER8> Except, this is software.

My favorite expression when things get heated: "Nobody is going to die."

There are exceptions, of course, but a vast majority of the work we do just doesn't matter in the context of life and nature.

<comment><USER9> > "Nobody is going to die."

This isn't accurate, e.g. [http://cryptome.org/2012/07/chile- comments.htm](http://cryptome.org/2012/07/chile-comments.htm) .

Bad crypto is actually much more dangerous than a single rogue dentist.

<comment><USER8> Bad crypto doesn't kill, people/organizations with a fucked up agenda do.

I thought this past year taught us that no information is safe. To expect that any system is entirely secure and ever will be is pure egotism.

<comment><USER9> Then what's the point?

</comment></comment></comment></comment></comment></comment><comment><USER10> I will say from skimming over the source tree the amount of code in CryptoCat(android) is surprisingly light. This is very refreshing compared to other chat applications which are unnecessarily huge.

Will be definitely going over this later.

<comment><AUTHOR> Cryptocat for Android is particularly unfinished so far. I would be surprised if you _don 't_ find bugs inside. Cryptocat for iPhone is currently a lot more mature, but similarly still needs peer review.

We have a commissioned audit for both apps, but it won't be starting for another two weeks. Thanks SO MUCH for your interest. We rely on security enthusiasts for comments and advice.

</comment></comment><comment><USER11> If your multiparty protocol is actually something you want scrutinized, why not follow the accepted model and make a c library reference implementation and release a research paper outlining the basis for your design decisions?

"Hey guys, here's the code, file some bugs for software that is of no use for you to spend time auditing" is pointless.

Adium has an incentive to read the libotr sources. Every user has a small incentive to read kernel sources.

Nobody has any meaningful incentives to read the cryptocat homebrew multiparty cryptosystem except the few you've paid to do so. This is cargo cult peer review; it looks like you're doing it but it doesn't actually yield the intended results.

PS: glad to see you switched to OTR for two party. You should have done that years ago, but at least you wised up in the end. Hopefully nobody got killed or tortured in the process.

<comment><AUTHOR> It's true that we don't have a research paper per se for the multiparty protocol, but we do have a specification document [1] as well as implementations in Objective-C, Java and JavaScript. The specification, as well as the implementations, have received both professional audits (from cryptographers) as well as community audits. The reason we don't have a research paper published is simply because we're working on one right now — a redesign of the multiparty protocol based on OTR. We have cryptographers on board from various Canadian universities and are organizing an internal forum to get them to collaborate on this. We expect publishable results by June 2014.

Regarding OTR, we actually switched to that 16 months ago — it's not exactly like we recently wisened up.

[1] [https://github.com/cryptocat/cryptocat/wiki/Multiparty- Proto...](https://github.com/cryptocat/cryptocat/wiki/Multiparty-Protocol- Specification)

<comment><USER11> > as well as implementations in Objective-C, Java and JavaScript.

Factor the ObjC version out to plain C, and call into it from your Objective C implementation. Make the plain C version the canonical version. (Things like Emscripten may be useful here for your JS use-case.) This is how libotr does it, and for good reason.

Then, others can use it, and perhaps you will get meaningful free auditing. What you're doing now probably won't attract that because unless your bug bounty is six-figures, nobody competent will spend any significant amount of time auditing it because they have no incentive to do so.

<comment><AUTHOR> Everything you've said in your comment is good advice. Once the paper I've mentioned is ready, we will have this kind of implementation.

</comment></comment></comment></comment><comment><USER12> And why the hell should i use a app that is written by know poeple that prooven they have no clue about crypto? Why shouldn't i use one of the many apps that support OTR?

<comment><AUTHOR> Cryptocat's private chat uses OTR. Our group chat function uses an open and studied multiparty protocol. Generally, our security bugs have been implementation errors much more than protocol design errors.

Surely, the best we can do as a community project is open up our code for more volunteers and experts to help and take a look. :-)

<comment><USER12> Great to hear that you switched to older and audited code. Could you explain what relationship this app has to the javascript version?

<comment><AUTHOR> There are currently three Cryptocat clients:

* Cryptocat: The original client. It's a signed browser extension that you download and install in your browser. It offers OTR implemented in JavaScript in a friendly chat interface. We take every precaution to make JavaScript more secure, such as using a signed browser extension to prevent code delivery MITM, using native cryptographically secure random number generation, and so on. More info on our JavaScript approach at my personal blog: [http://log.nadim.cc/?p=33](http://log.nadim.cc/?p=33)

* Cryptocat for iPhone: No JavaScript here! This is an app written in Cocoa Touch/Objective-C that implements OTR and our multiparty group chat protocol. It's really quite a simple app compared to what we had to do to put encrypted chat in the browser. It's new and needs review! Find bugs! Help a cool open source project! We'll send you rewards!

* Cryptocat for Android: No JavaScript here! This is an app written in Java that implements OTR and our multiparty group chat protocol. It's really quite a simple app compared to what we had to do to put encrypted chat in the browser. It's new and needs review! Find bugs! Help a cool open source project! We'll send you rewards!

All three clients are made to be 100% inter-operable.

<comment><USER13> I guess the third one should be the android version.

<comment><AUTHOR> Derp. Fixed. Thanks!

</comment></comment></comment></comment></comment></comment><comment><USER14> Glad that they're taking security seriously. It's a sharp difference from how they used to do things[1]. However, I'd still like to see either an explicit bug bounty (there's one implied here) or a paid audit.

[1]: [http://blog.cryptographyengineering.com/2013/03/here-come- en...](http://blog.cryptographyengineering.com/2013/03/here-come-encryption- apps.html)

<comment><AUTHOR> From my perspective, we've been taking security seriously a year+. Our first commissioned audit was in November 2012, and we've had a bug bounty since then as well: [https://crypto.cat/bughunt/](https://crypto.cat/bughunt/)

This isn't, of course, to say that there haven't been vulnerabilities. But I have to stand behind our mitigation and disclosure policy as being very highly responsible and transparent.

So far, we've had three paid audits, with two more lined up, and regularly reward community bug-finders. We're planning more competitions for Cryptocat Mobile in March and April, with prizes such as iPhones and Nexus Phones. :-)

<comment><USER15> Hi, I am working on a security-focussed startup. We have a rough cut of our initial product offering due in the next month and are trying to get initial trial users and customers on board to help us demonstrate interest.

How do you manage to afford to finance the audits and bug bounties? We have found that some potential customers want to see us get security audited before trusting our solution, but from what we can tell this is a multi-hundred thousand dollar cost and requires us to freeze development while it takes place. We currently have zero day-to-day budget and runway for 6 months. How have you afforded it?

<comment><AUTHOR> > How do you manage to afford to finance the audits and bug bounties?

Public donations from our website and funding from public institutions and NGOs. Currently, our audits are funded by the Open Technology Fund: [https://www.opentechfund.org](https://www.opentechfund.org)

Generally, our funding tends to be very limited though, so sometimes we have to ask someone to do an audit for cheaper than they usually would, seeing as we're an open source project with no source of revenue.

 __EDIT __: Forgot to mention, we have no funding for bug bounties. I pay all bug bounties out of my own pocket. I don 't mind, I feel the money is very well-spent.

Good luck with your startup!

<comment><USER15> Ah, so basically, as a for-profit company aiming at a B2B enterprise product, we are screwed in this regard until we have the capital to absorb the audit cost through either revenue or investment. Oh well.

</comment></comment></comment></comment></comment><comment><USER16> can you give some screenshots or videos of the fingerprint showing mechanism?

My biggest concern with cryptocat is that this info is kind of hidden and not bubbled up to the user.

In the web version, the way its handled makes it possible for the server operator to replace who you are talking to mid-conversation without warning unless you click a fingerprint button before and after every message you send which nobody is going to do

I know there is an issue for this on the web version ( [https://github.com/cryptocat/cryptocat/issues/463](https://github.com/cryptocat/cryptocat/issues/463) ), just wondering if the mobile ones take a different approach.

</comment><comment><USER17> How are you guys going to get Cryptocat on the iPhone app store? Apple rejects GPL-licensed apps.

<comment><USER18> Is that the case? I thought it was more that the GPL rejects distribution on the App Store.

<comment><USER17> Are you seriously saying that it is the FSF's fault? It's Apple's fault. They didn't have to make the iPhone a closed platform.

</comment></comment></comment><comment><USER19> So there's a DC hackathon[0] taking place this weekend, and Cryptocat is on the list of projects to work on.

I imagine the Android and iOS apps would be ripe targets for bug finding adventures, but are there any places specifically that could use the kind of scrutiny that such an event could provide?

[0] - [http://www.eventbrite.com/e/dc-internet-freedom-hackathon- ti...](http://www.eventbrite.com/e/dc-internet-freedom-hackathon- tickets-9306081741)

<comment><AUTHOR> Yup! I'm leaving for D.C. tomorrow and will be at that hackathon. Please come and help!

</comment></comment><comment><USER20> Man they are a glutton for punishment.

<comment><AUTHOR> I like to think that the Cryptocat team and myself have matured beyond the point where we consider security disclosures to be punishment, but rather something to be expected when handling a project that wields experimental technology. We're trying to be adults by adopting principles of full disclosure, mitigation, transparency, public involvement, and making sure our process is tweaked to prevent the repetition of past mistakes.</comment></comment>


Wakie: The Social Alarm Clock That Lets You Wake Up Strangers - <AUTHOR> http://techcrunch.com/2014/12/10/wakie/?ncid=rss <comment><USER4> This concept seems strange, a random person calling to wake you up.

It makes me think back to an annoying app idea I had, Spam the Spammer - <USER2> idea for this was, anyone that sends me spam, I send it back to them and crash their account. Don't worry HN community, I didn't build this product.

Back to the topic, their features on having recorded celebrity voices seems a bit stalkish to me. I don't see any real need for an app to call me to wake me up. I'm a heavy sleeper, and usually set about ten alarms each morning - <USER3> works fine for me.

I'd expect this app to be semi- faddish.

<comment><AUTHOR> I'd have loved to see Spam the Spammer come to fruition!

<comment><USER4> Lol, it would actually enjoy it, but if other people did it to me, that would suck big time.

I'd assume, if I built it, people would spam the crap load out of me, just by spite.</comment></comment></comment>


A command-line murder mystery - <AUTHOR> https://github.com/veltman/clmystery <comment><USER2> A lot of the code that I write looks like a crime-scene.

</comment><comment><USER3> Hah, I had a similar idea a few months back [0]. Of course, being the lazy person that I am, I tweeted about it, wrote about it in my ideas notebook, and never implemented anything.

Checking this out right now!

[0] [https://twitter.com/gardaud/status/402608968029057027](https://twitter.com/gardaud/status/402608968029057027)

<comment><USER4> It's not a new idea.

I recall a database query tutorial on the Apple Mac in the early 90s that took the form of a detective game. With clues, you gradually refined your query. I can't find any references to it now though.

<comment><USER3> Hah, that's awesome- if anyone knows of it, would love to know the name!

I'm definitely familiar with tutorials for programming languages/tools/environments using the medium itself, as you just described - but have never seen anything in game form. Further examples appreciated!

<comment><USER5> I'm not sure about on the Mac, but that sounds like the MS Works 1.0 tutorial for the database component. The scenario was for a ski field where there had been a murder, and you had to whittle down the suspects based on the clues found.

</comment></comment></comment></comment><comment><USER6> I found it frustrating that gur vagraqrq fbyhgvba cngu qbrfa'g gryy lbh qverpgyl jura lbh'er qbar naq lbh unir gb vasre gung sbe lbhefrys.

It's a really neat idea and a cool way to give people some command-line practice.

<comment><USER7> Yes, I agree - I think the name of the suspect should form part of the key required to decipher the solution file, so that you cannot see the solution unless your suspect is the perpetrator.

The frustration for me was gur haerfbyirq vapbafvfgrapl orgjrra gur pbssrr pyhr ng gur pevzr fprar naq Naanory'f jvgarff fgngrzrag.

Gur onevfgn ng gur pevzr fprar ercbegrqyl fnvq gung "n jbzna yrsg evtug _orsber_ gurl urneq gur fubgf".

Ohg Naanory Puhepu'f vagreivrj erpbeqf ure fnlvat gung fur "ena njnl nf fbba nf gur fubgf jrer sverq", gung vf, _nsgre_ gur fubgf jrer sverq.

Vg znl or cbffvoyr gb erpbapvyr be rkcynva gubfr fgngrzragf, ohg gurl frrzrq gb zr gb jneenag ng yrnfg fbzr vairfgvtngvba.

<comment><USER8> Zl haqrefgnaqvat: Pevzr fprar jnf gur fgerrg va sebag bs gur pbssrr cynpr. Gur jvgarff vf gur ynfg crefba gung yrsg orsber gur fubgf (bhgfvqr) jrer sverq.

Gung fur ena nf fbba nf fur urneq gur fubgf svgf dhvgr va?

</comment></comment></comment><comment><USER9> Hey, I'm the one who made this. Glad you guys liked it! This one was a bit quick and dirty, done for a workshop at the Mozilla Festival last year, I'm going to try to do another installment though!

<comment><USER10> I had a lot of fun with this. I did it in Clojure, though. Thanks!

</comment></comment><comment> lost-theory Very fun and unique. I enjoyed it a lot! My solution (spoiler alert): [https://gist.github.com/lost-theory/8412918](https://gist.github.com/lost- theory/8412918)

<comment><USER9> I love this. I've been curious what a one-line solution would look like. :)

</comment></comment><comment><USER11> Including the .zip in the repository is a bit redundant when GitHub offers you the ability to download a zip file of a repository. Like this:

[https://github.com/veltman/clmystery/archive/master.zip](https://github.com/veltman/clmystery/archive/master.zip)

[https://github.com/veltman/clmystery/issues/4](https://github.com/veltman/clmystery/issues/4) \- I opened an issue about it, just in case the author did not realize this.

</comment><comment><USER12> Are the executables listed in [https://github.com/bmatzelle/gow/wiki/executables_list](https://github.com/bmatzelle/gow/wiki/executables_list) sufficient for use with this?

<comment><USER13> Yep, I was just able to do it only with cat, grep, sed, and head.

<comment><USER14> I think I would have found it painful without join and sort, though (which, also in that list).

<comment><USER15> I rarely use join and it never occurred to me. For combining the one file that had records spanning several lines, I used awk instead of grep -A as the hints suggest. Where the hints suggest a head/tail combination, I used sed. I also used sort piped to uniq in one case; combinations of those two are very often useful.

</comment></comment></comment></comment><comment><USER16> thanks for sharing. this was entertaining and reminded me of [http://vim- adventures.com](http://vim-adventures.com)

<comment><USER9> Glad you enjoyed it!

</comment></comment><comment><USER17> Alicia Fuentes F 48 Walton Street, line 433

There's no Walton Street under streets. Same for a few others I checked. What gives?

<comment><USER18> I guess she's not important. What let you to suspect her?

<comment><USER17> First person in the people file. Is there a bunch of gibberish?

</comment></comment></comment><comment><USER19> I take it using pagers would be considered cheating, under the categorisation of "text editors"?

<comment><USER20> It's not cheating, it just doesn't really help you. There's a lot of noise. You have to use grep, sed, etc. to find the text that's actually important.

<comment><USER21> Not just a little, holy crap there is a lot! The crime scene file is ~13500 lines of reports.

</comment></comment></comment><comment><USER22> This was fun!</comment>


Toyota Gears Up to Become Global EV Systems Supplier - <AUTHOR> https://www.thedrive.com/tech/27790/toyota-gears-up-to-become-global-ev-systems-supplier <comment><USER2> Decades ago, Honda tried to become a gasoline engine supplier to other car makers. But the industry remained vertically integrated in engine development, even as parts suppliers in other areas moved up the value chain. Electric cars may drive horizontalization even more. Another factor is the huge number of manufacturers springing up in China.

</comment><comment><USER3> The comments there are somewhat magical. FOOL CELLLSSSS!!1!1!

</comment><comment><USER4> Does this mean we'll get a PHEV toyota or BEV anytime soon?

<comment><AUTHOR> Here's a Toyota Prius plug-in hybrid:

[https://www.toyota.com/priusprime/](https://www.toyota.com/priusprime/)

Not much pure electric range but 640 miles total driving range.

<comment><USER4> Right. I forget it because I want it to be a rav4.</comment></comment></comment>


Show HN: PRLibs, madlibs to create press releases for startups - <AUTHOR> https://prlibs.com/ I learned Flask, Python, Uwsgi, and Nginx configuration in order to make this happen.
Oh and if you're feeling generous, you can buy them for $2 a pop:
https://prlibs.com/nocc <comment><AUTHOR> I learned Flask, Python, Uwsgi, and Nginx configuration in order to make this happen.

EDIT: Oh and NLTK, of course.

EDIT2: If you missed it, you can see all the posts here: <http://prlibs.posterous.com/>

Oh and if you're feeling generous, you can buy them for $2 a pop:

<https://prlibs.com/nocc>

</comment><comment><USER2> Oops, now my real name is out on the internet. Good thing it didn't ask for my SSN, I probably would have typed it in as well without reading anything.

</comment><comment><USER3> We whipped this together for a Startup Weekend fun. The articles are hilariously awful right now. Any tips for making sentences more coherent is welcome.

<comment><USER4> I say, make them even more incoherent. How? Take Reddit user syntaxgs: This strange Internet persona (dedicated troll? bot? multiple people?) has been writing bizarre, unreadable comments for years now [1]. I recommend you look at his Reddit comments, modify your text generator to replace phrases with syntaxgs's "syntax", and post the results.

References:

[1] Reddit account: <http://www.reddit.com/user/syntaxgs>

[2] syntaxgs comment obfuscator (not mine): <http://syntaxgs.sharpoblunto.com/>

<comment><USER5> You can also take inspiration from this twitter bot <https://twitter.com/Horse_ebooks> It is very zen sometimes.

</comment></comment></comment><comment><USER6> Is there a way to dele them? I didn't know mine would be saved and viewed by my bosses who undoubtably have a google alert for their startup name.

</comment><comment><USER7> "The startup seeks to let strings by breaking .2em bytes."

I was tempted to make a snarky comment about this, but it's actually not much worse than phrases like "We deliver beautiful products to web enterprises!" At least this is _obviously_ gibberish.

</comment><comment><AUTHOR> There seems to be a lot of HTML leaking through. We'll see if there is any way to sanitize it further...</comment>


Packt Publishing ebooks free today with DOTDEBOOKFREE promo code - <AUTHOR>

http://www.packtpub.com/
no credit card required, mailinator emails happily accepted :>

    DOTDEBOOKFREE
 <comment><USER2> Today, one of our discount codes escaped into the wild! If you were lucky enough to download a free ebook today we hope you enjoy it - we'd also like to thank the HN community in particular for highlighting some legitimate issues on our end. We'll definitely be looking into addressing these. However, nothing that good can last for ever, and the discount code itself should no longer be active.

We're happy to talk to any of our authors about the impact this might have had on individual titles on a case by case basis - you should always feel free to get in touch with your primary editorial contact even after publication (alternatively, you can email me directly regarding this particular discount at email@example.com). We're here to help and support you not only through the publication process, but also beyond.

We apologize for any inconvenience caused to customers who tried using a code that we emailed out directly. Please contact us at email@example.com if you have experienced any problems as a result.

</comment><comment><USER3> For lazy, to ease copy-paste:

DOTDEBOOKFREE

:>

</comment><comment><USER4> Is it still working for anyone? I see "Sorry, that promotion code is no longer valid".

<comment><USER5> Me too... That really sucks.

</comment></comment><comment><AUTHOR> Any recommendations for well-written books?

<comment><USER6> [http://www.amazon.com/s/ref=sr_st?keywords=packt+publishing&...](http://www.amazon.com/s/ref=sr_st?keywords=packt+publishing&qid=1393411249&rh=n%3A283155%2Ck%3Apackt+publishing&sort=reviewrank_authority)

I got "Building Machine Learning Systems with Python".

<comment><USER7> Great book. I'm one of the suckers who paid for it months ago.

</comment></comment></comment><comment><USER8> Can I create a 'real' account and centralize all my ebooks, or do I need to create one account per ebook?

<comment><AUTHOR> one discout per account

<comment><USER8> Thanks

</comment></comment></comment><comment><USER9> It's a pity they don't have akamai/cloudfront or something, it seems they are getting crushed.

So whomever is running 27 simultaneous downloads, please stop. You'll never read all those books.

<comment><USER10> You're right, I'll never read them. However I'm collecting a shitload of pdfs, I convert them to HTML, put them in an ElasticSearch database, so I can search their content when I need it.

It's more like a complementary documentation database.

<comment><USER11> Sounds like too many steps. Why not use ePub directly. It's just a Zip with funny HTML inside. Index that and you may even get page numbers. Contact me if interested in collaborating (it's one of my todo projects).

</comment></comment></comment><comment><USER12> "Down for maintenance."

I guess it's the Hacker News effect.

<comment><AUTHOR> the Varnish "Guru Meditation"[1] page never fails to give me a little smile, reducing the anger about unavailable pages

[1] [http://en.wikipedia.org/wiki/Guru_Meditation](http://en.wikipedia.org/wiki/Guru_Meditation)

<comment><USER12> I wondered about that. I thought "Guru Meditation" was an AmigaOS only thing.

</comment></comment></comment><comment><USER13> Adding the promo code in the Checkout section doesn't trigger or reset the price and it's still asking me to continue checking out using either credit or paypal. What am I doing wrong here?

<comment><USER14> Try to add only one book. That way it works for me.

</comment></comment><comment><USER15> the search functionality on the site is really inaccurate, I searched for ruby and the first book recommended is Raspberry Pi Media Centre, nothing on the first two pages had ruby in the title.

<comment><USER11> Yeah, I find it funny given that they published like 10 books on Solr and Elastic Search combined. I guess they don't have time to eat their own dogfood. The problem with breadth publishing approach!

</comment></comment><comment><USER16> Hi, How does this work? I added a few ebooks to my cart and tried to use the promo code, but it still doesn't show any change.

 __EDIT __— Worked like a charm. Thanks much!

<comment><AUTHOR> add one to cart, apply promo, enter bogus data, checkout. repeat.

<comment><USER17> script anyone?! :D

<comment><USER18> Why not torrent them instead? I mean it: I assume that collecting bogus data doesn't do them any good and torrenting would save the publisher some server load. A script that buys every book, on the other hand, doesn't even contribute to popularity statistics.

<comment><USER19> I'm just going to go ahead and get just 1 the legit way. However I wish they made some sort of volume discount that wouldn't mean paying £300+ for a 10-15 book collection.

Honestly most of these books are on topics that would make them obsolete quite soon. The real practical use for these is as references across several topics. I understand it's hard to monetise that kind of thing though.

</comment></comment></comment></comment></comment><comment><USER20> It looks like you can get a second e-book for free if you allow them to send seven days worth of daily deals (I unsubscribed from everything before noticing the message).

<comment><USER21> Not sure if they've just changed it, but the offer for the mailing list is now 50% off your next book. Or is that a different offer?

</comment></comment><comment><USER22> Worked for me too, don't even need Mailinator (as you don't need to pickup the email). Address with randomly chosen Post (zip) code.

</comment><comment><USER23> Clickable: [http://www.packtpub.com](http://www.packtpub.com)

</comment><comment><USER24> No email confirmation and plain text captcha. They got to be kidding.

<comment><AUTHOR> they don't even check if the email _looks_ right. firstname.lastname@example.com works..

</comment></comment><comment><USER25> Sadly, the code is, evidently, no longer valid.

</comment><comment><USER26> It really worked

<comment><USER13> at what point do I see the deductio? I have entered the promo code, checked out and hesitant now to enter my credit details.

<comment><USER27> If you do it right (i.e, just have one book in the cart), the button should say Check Out For Free

<comment><USER13> oh ok, so it's restricted to only 1 book?

<comment><USER27> One free ebook per account, apparently

</comment></comment></comment></comment></comment><comment><USER5> DOWN FOR MAINTENANCE...

great.

</comment><comment><USER28> Damn, now getting a status 503.

</comment><comment><USER29> aaaand.. the site is down for maintenance.

got a few books though.

</comment><comment><USER30> Cheers mate. great stuff

</comment><comment><USER31> Now promo code invalid

</comment><comment><USER32> Thanks!

</comment><comment><USER33> thx</comment>


Ask HN: Seeking relaxing, cheap vacation spots for personal coding - <AUTHOR> Sometimes I'd like to just get away and code for fun.  Any tips for finding a spot w/ decent Internet, low expenses, and minimal distractions?<p>I'm based in San Francisco, CA, but am open to traveling anywhere. <comment><USER2> Though expensive compared to SEA, I prefer Japan when I need to get away and focus on doing a specific project for a few weeks. I just spent 6 weeks in Japan. For me to focus on anything, I want my environmental needs to be of least resistance and least time consuming of my time. I am typically 2-3 times more productive in Japan but I can't do it more than 4-8 weeks continuously to avoid burn out.

I don't know the language so it provides sufficient isolation. Any talking by others around me becomes part of background noise. It doesn't interrupt my thoughts unlike when I may over hear things in language I can understand.

People are great, respectful and non-interfering. They will leave you alone in most situations. You don't need to keep your guards up regards to scams and watching your stuff.

Infrastructure, facilities and safety are great so I don't need to worry about the environment and environmental changes, just focus on what I need to do. Portable 4G wifi is as fast as my comcast at home, no power or living issues. Food is great and don't need to think and watch where I can safely eat.

When I need a break, the major cities have decent nightlife or places and expat population to provide a break from work.

</comment><comment><USER3> Nomad List has a good collection of cities with filters. For example, places in North America that are warm in March with fast internet access [1].

[1]: [https://nomadlist.com/#month=mar&temperature=warm&internet_s...](https://nomadlist.com/#month=mar&temperature=warm&internet_speed=fast+internet&region=north+america)

</comment><comment><USER4> Porto - European best destination 2017 ([https://vimeo.com/203346600](https://vimeo.com/203346600)).

Not very expensive with lots of things to visit (nature, culture, nightlife, food, etc).

Porto airport has a Ryanair hub with flights to many cities in europe if you're into it.

</comment><comment><USER5> I'd recommend Cebu, in the Philippines... but seeing as you want to keep travel costs low, how about Hawaii? Rent a nice hotel room with a spectacular view without blowing your money on travel costs.

</comment><comment><USER6> Cruise ship - less than $100 a day if you do it right. Plenty of food and lots of good nooks to code from. I've met several developers who take a week off on a ship to really get work done without distractions.

<comment><USER7> Seems like internet access might be an issue.

<comment><USER8> Or, lack of internet access might be a productivity enhancement. :-)

<comment><USER6> That's how I look at it!</comment></comment></comment></comment>


Monty Oum, animator at Rooster Teeth, has died - <AUTHOR> http://roosterteeth.com/members/journal/entry.php?id=3302319

<comment><USER2> For context, he was the creator of the famous machinima Haloid (Halo + Metroid) back in the day: [https://www.youtube.com/watch?v=cL- mR79GErU](https://www.youtube.com/watch?v=cL-mR79GErU)

I'll always remember him for his ridiculous work ethic and amazing combination of art and tech (I believe he created his own animation library for RWBY or something like that to give it it's unique cel-shading kind of look)

Many people are mourning together on the Rooster Teeth subreddit [https://www.reddit.com/r/roosterteeth](https://www.reddit.com/r/roosterteeth)

</comment><comment><USER3> So sad. Such a young guy. And from a selfish point of view, we'll never get another Dead Fantasy ( [https://www.youtube.com/watch?v=WAsq3HkYbUs](https://www.youtube.com/watch?v=WAsq3HkYbUs)). Created some pretty great fan service back in the day.

</comment><comment><USER4> Does anyone have any info about what kind of allergic reaction could have caused this?

I'm fearful of hospital procedures for reasons like these. How'd the doctors let it slip by? But it's a dumb fear and I'm trying to break myself of it.

<comment><USER5> It didn't 'slip by', it likely happened very quickly, without warning, and the doctors and nurses certainly did everything they could to save him (I don't know anything about the specifics of this case, but I'm familiar with the general practices).

There are various medications used for sedation that you wouldn't be exposed to in the course of 'normal' life, so the first time you're exposed to them is on the operating table. That makes it very hard to predict things like this.

It's also possible it wasn't actually an allergic reaction, but one of a handful of other life-threatening reactions that can take place during medical procedures (e.g. [https://en.wikipedia.org/wiki/Malignant_hyperthermia](https://en.wikipedia.org/wiki/Malignant_hyperthermia) )

No procedure is without risk. It is important to weigh benefits of the procedure against the risks (your doctor should be able to help you judge your specific risk factors and explain the benefits).

</comment></comment><comment><USER6> Came to HN to distract myself from this news and here it is. Monty was a great inspiration to me mainly for his relentless work ethic and amazing creations. He is sorely missed in the RT community.

33 is too young to die.

<comment><USER7> I was trying to distract myself from bad news here, too. Hard to escape it sometimes. Hope you're doing better now that it's a few days later.

</comment></comment><comment><USER8> > _Ten days ago Monty suffered a severe allergic reaction during a simple > medical procedure that left him in a coma._

Such a young guy. Remember that you can never be sure how many "tomorrows" you get.

</comment><comment><USER9> If you are curious, and don't happen to follow such things, you can see some work he was involved in, in the form of the RWBY series on Crunchyroll. (I'm not associated in any way with Crunchyroll.)

The combination of Blocks World style AI with Machinima has the potential to change human culture in radical ways. (It already is, IMO.) What would it do to language, if we could just think of a video scene in our heads, and our mobile computer could just synthesize it and show it to others? I suspect the use of "like" is related to the effect video media has already had on language.

<comment><USER10> > I suspect the use of "like" is related to the effect video media has already > had on language.

I'm not sure what you mean by this, can you explain?

<comment><USER9> Well, like, when people use "like," it's like they're narrating a video scene in their own heads in a way that would cause another person from a video- soaked culture to, like, make it play in their heads too. ;)

It's the same as how such narration worked before, but it's also different in that we have a corpus of video culture to make references to. Before widespread video, we were always referring to the imagined "movie scenes" evoked in our heads by narration. Now, we can refer to a corpus of specific pre-rendered movie scenes.

<comment><USER11> > Well, like, when people use "like," it's like they're narrating a video > scene in their own heads in a way that would cause another person from a > video-soaked culture to, like, make it play in their heads too. ;)

The syntactic filler likes, or the "its' like they're..." like? Those are very different. Syntactic filler such as that is universal in human speech and languages, but tends to be different depending on the language and speaker. There's nothing unusual about Americans attaching to the word "like" as syntactic filler.

Or do you mean "like" as a synonym for "such as"? Like/Such as in this example here? I don't see how that has anything to do with video culture. People have spoken in hypotheticals since long before video.

<comment><USER9> _The syntactic filler likes, or the "its' like they're..." like?_

If you pay close attention, you'll find that it's not always filler. Often, people are prefacing references to visuals from the common culture.

</comment></comment></comment></comment></comment><comment><USER12> In case anyone else is unable to get past the "checking your browser" page (whatever that means...) like me:

>Our friend, inspiration and co-worker Monty Oum passed away yesterday afternoon at 4:34 PM surrounded by people who loved him very much. Ten days ago Monty suffered a severe allergic reaction during a simple medical procedure that left him in a coma. Although he fought bravely, his body was not able to recover.

And wow, I'd been planning to catch up on RWBY this week. Sad news...

<comment><USER13> Checking your browser is a cloudflare thing. FWIW.

<comment><USER14> I seem to be getting that at about 30% of the sites I go to today.

</comment></comment></comment><comment><USER15> Ugh, this is tragic. Such a talented person gone too soon.

Now I don't want to say it was life changing for me, but I greatly enjoyed watching his earlier videos (Dead Fantasy series, Haloid).

But with RWBY (his most recent work) he spawned a universe out of nothing that is now loved by thousands and thousands of people.

True creative talent and dedication at his level is rare, and while we'll never get to see more from him, I have no doubt that his work has inspired countless people to create their own universes, and for that we should be happy.

</comment><comment><USER16> This is terrible, I've been following Monty since before Haloid. I thought it was awesome when he joined roosterteeth to work on RvB.

He was incredibly talented young man and certainly died way too early. I hope his family will be able to get through this, it will certainly be very tough to handle this.</comment>


"Going commando" on the TSA - <AUTHOR> http://arstechnica.com/tech-policy/news/2010/11/going-commando.ars <comment><USER2> Before you try this, note the TSA just arrested a man for not wearing enough clothes so he could be patted down.

He was not refusing their gate-rape freedom-fondle, just making it easier for them:

[http://www.printthis.clickability.com/pt/cpt?action=cpt&...](http://www.printthis.clickability.com/pt/cpt?action=cpt&title=Passenger+Chooses+Strip- Down+Over+Pat- Down+|+NBC+San+Diego&expire=&urlID=441153877&fb=Y&url=http%3A%2F%2Fwww.nbcsandiego.com%2Fnews%2Flocal- beat%2FPassenger-Chooses-Strip-Down-Over-Pat-Down-109872589.html)

 _TSA requested [he] put his clothes on so he could be patted down properly... He never refused a pat down._

So basically they could visually see he didn't have any weapons but required him anyway to then put on more clothes so they could then pat him down.

America has lost it's mind.

</comment><comment><USER3> I'm not sure a kilt would help- they'd just pat you through the kilt. How about some bike pants? That way the TSA can see what they are getting into:

[http://www.amazon.com/Nike-Echelon-Padded-Bike- Shorts/dp/B00...](http://www.amazon.com/Nike-Echelon-Padded-Bike- Shorts/dp/B003QJ8DN8/)

</comment><comment><USER4> TSA is great illustration for what American Democracy really is.</comment>


Why Can't Developers Estimate Time? - <AUTHOR> http://blog.patchspace.co.uk/why-cant-developers-estimate-time? <comment><USER3> _As a community we need to get away from [making shit up]. If we don't know, we don't know, and we need to say it._

All too often, when we do say it, managers just get annoyed and demand it be done by an arbitrary deadline; since we don't know how long it will take, we're not in a position to justify why it will take longer than that arbitrary deadline. The decision gets made either by "this is when it's needed" or "make up something so he'll stop pestering us", the date gets etched in stone, the particular scenario is forgotten, and when the date is missed everyone looks bad and gets annoyed.

Managers need to know how long things will take. Fair enough, there's more to most projects than just development, and it all must be scheduled to come together in a sensible workable timeframe.

The problem is it's still a fast-changing discipline, with the unknowns dominating the knowns. The biggest known is construction time: most disciplines have a construction/distribution period long enough that it can cover/buffer for variation in the design phase; in software, the construction/distribution period is nigh unto _instant_ (compilation), so design can't hide behind any other phase. It's all design, usually entailing something significant designers have never dealt with before. It's not, say, a bridge where all the basic materials & mechanisms are well understood, predictable, and have a long construction period which can run parallel to at least some of the design phase.

<comment><USER4> In this situation I tend to follow the Montgomery Scott Miracle Worker Rule(tm). Come up with a nice, comfortable number in your head, pad it out a little if necessary so it's a nice round number, then multiply by 4.

<comment><USER5> The only thing that worries me with this technique (as tempting as it is), is that I've seen teams where the work will dramatically slow down because they're trying to "fit" to the deadline. Getting it done as fast as possible and early only leads to more work for more people.

</comment></comment></comment><comment><USER6> This is a wonderful overview of the science of estimating, and far be it from me to argue with ToC and the revered Product Development Flow book. I'm a big fan of both.

But that's all horseshit in many contexts.

The problem is not that these ideas are false, it's that _variability is so great that in small projects you never separate signal from noise_. Over hundreds of user stories? Over months or years? Dozens of teams? Sign me up for flow, Kanban, and the goodness of ToC. Coincidentally, this is why these conversations always end up with some kind of histogram and discussions around long tail tasks.

Small scale, however, the reason I can't tell you when I'm going to be done with making that button the right color is that the danged user can't make his mind up. The biggest part of local variability is not competence as much as the social nature of human interaction. As technologists, we always do exactly what this author does -- we completely ignore the human part of development and pretend it's all just a systems game. We're all little factory robots processing little pieces of stuff at our station, moving it on to the next station.

It's important to remember that these generalizations are only true at the macro level. In fact, for really small teams in a startup environment, it's all social-interaction induced variance. That's probably the one most important thing to know about estimating for many of us. For the few of us who are responsible for macro-level systems, it's still good to know if you're going to understand individual team and developer performance.

<comment><USER5> I don't think I've _ever_ seen a software project hit a deadline, that includes early delivery as well as late.

I found the constant focus on time estimating in management disciplines incredibly contrived and frustrating. It's an incredibly wrong headed effort at taking mass production estimate techniques (where zero creativity is required) and applying it towards a creative endeavor. It makes as much sense as asking "how many innovations per hour can the team accomplish?" "or how many paintings can a team of painters crank out per day?".

What I think bothers me the most is how this is treated in management education. At its simplest, you start with a roll of the die, because any estimate is essentially a Wild Ass Guess (WAG). But then, realizing that software deadlines are never met, the management discipline tries to use various structured techniques for estimating, like complex work breakdown structures and critical path analysis blah blah blah, which of course simply use WAGs at a finer level of granularity and do little but generate busy work for the managers. Instead of one WAG, we now have dozens or hundreds of small WAGs.

Of course none of this provides a better estimate of time, but might include gems like when aggregating your WAGs from a work breakdown structure to derive a total project estimate, add 20% to each small WAG to build in "slack time" which is another way of saying "we don't really know how long it'll take, so we're going to over estimate as a Check Your Ass (CYA) maneuver, if we estimate out long enough, all work will get done early!". Brilliant. Modern management practices have now turned from coordinating and organizing complex efforts into professional CYA endeavor.

I think there's light at the end of the tunnel, most of this nonsense is a result of trying to scope box projects, which makes sense when building a bridge, or making millions of widgets, but makes little sense when building new software. There's obviously a need for setting deadlines, as anybody who's ever managed a "when it's done" software project knows...that only asks for "Duke Nukem Forever" problems. Setting deadlines keeps people on task and motivated.

So the solution? What do your business needs dictate in terms of delivery time? Then timebox to that. If features don't get built by that time, too bad. Software, unlike building a bridge, is a _continuous_ practice. You can build, deliver and then rev to fix, extend, addend software that didn't hit the desired scope. It eliminates lots of the CYA and WAG nonsense, and forces people to try and get as much as possible done in the allotted time anyways. It keeps the development team from going into (what I consider) largely unethical extended crunch periods near or after a WAGs arbitrary deadline. They'll simply focus on what they _can_ deliver. It's descriptive of their job instead of proscriptive. It implicitly creates the understanding that full functionality is not the goal for a milestone.

"Build as much as you can by x" makes more sense than "How long will it take to build all of Y?".

<comment><USER7> > "Build as much as you can by x" makes more sense than "How long will it take > to build all of Y?".

As a developer this makes total sense and I love it.

The problem is when the rest of the company that exists outside of the development world (i.e. creating new things), like sales and marketing, is that they would rather the whole company align under the "build all of Y" type of scenario because it makes their jobs fantastically easier. At the expense of the devs, of course.

As "agile" development practices continue to spread, I am hopeful that this re-framing of development around short development iterations and continuous delivery begins to transform the processes of the "clients" of development teams as well.

<comment><USER8> In my experience, when sales and marketing hear 'agile' they think it means you can deliver everything in a week. They don't hear 'iterations' or 'a certain amount of functionality' they hear 'completely done, faster'.

There's still a long way to go on this.

</comment></comment></comment></comment><comment><USER9> Oy, this again. OP might as well ask, "Why doesn't my buggywhip make my Camry go faster?"

Who cares whether or not anyone can estimate? These days, if you're estimating, you've already lost. Your competitors have already built and deployed something while you're in the endless analysis phase.

Estimating presupposes that you have an accurate spec which presupposes that you're going through some kind of development cycle. And after 40 years, we know that rarely works.

We know that what works better is combining analysis and development: prototyping quick cycles and stepwise improvement. It rarely matter how good it is; it only matters that is exists on time and that it's good enough.

 _I propose an alternative: what we need to do is teach to junior devs the meaning of done._

I propose an alternative to OP's alternative: what we need to do is define "done" as "whatever you've got at the deadline".

When you don't know what you want (who does?), it's better to have _something_ on time that you can improve upon than nothing late that wasn't right anyway. You don't need to estimate to do that; you just need to keep building and sharing.

<comment><USER10> This is great for consumer web/mobile apps, but it doesn't work so well for medical software or avionics.

<comment><USER9> _This is great for consumer web/mobile apps, but it doesn't work so well for medical software or avionics._

Don't kid yourself; this is _exactly_ what works for medical software or avionics. I never said we didn't test; I just said this is how we get stuff done: We use stepwise refinement instead of waterfall, so estimating is suddenly much less important.

(For the record, I'm 100% enterprise and 0% consumer web/mobile apps. As we speak, in my other session, I'm building an aerospace prototype I intend to deploy within 48 hours.)

</comment></comment></comment><comment><USER11> I am always blown away by the fact that we are terrible at estimating and are convinced that it is something that is just not possible, instead of acknowledging it as a skill that we simply have not developed.

Consider, restaurants have to build in an estimate of how much service they expect at a given location. Before it even opens. Once open, they have to keep a steady supply of estimates tracking against how stocked the supplies should be. Do we truly think this is a skill people just have? Or one that is developed and has been refined through the years?

My personal belief is that we are too busy learning to program, such that we never dedicate time to learn to estimate. This works for the stars that can keep pace programming at the top of the field forever. However, as soon as things adopt a maintenance perspective, being able to estimate the amount of work you will have becomes key.

<comment><USER12> Restaurants are able to identify customer patterns over a set amount of time. With these patterns, they are able to forecast the demand of what kind of food they need to stock. And that being said, my friends who have worked in restaurants say that ingredient inventory management is possibly the hardest thing in a restaurant's operation. So it's not like the restaurant industry has completely figured it out, though they do a lot better than many. I cannot count how many times I've walked into a restaurant hoping to have some specialty dish, only to find out that they've run out of ingredients. It happens on a regular basis to me.

For devs, it's slightly different. The customer patterns may not be consistent over time because devs are not always asked to build the same thing over and over again. Meanwhile, restaurant customers do order the same thing over and over again, so it's a lot easier to confirm the recipe timing and build order (just finished too much SC2) down to an exact science.

Yes, some devs may do nothing but build simple CRUD apps all month, and maybe they can get good at estimating what a simple CRUD app will cost based on their experience. But a lot of devs also work on things that have new and unique requirements for every single project, so the comparison with restaurants is not fair. And nothing against simple CRUD apps. Whatever brings home the bacon brings home the bacon.

<comment><USER11> I had not meant to imply it was a solved problem in food. More that it was not one that they ignore. As you pointed out, they can be wrong sometimes. Probably more often than folks would realize. (Also, it is not just the daily operation, but again, the estimates in moving into new territory. I don't have numbers, but my hypothesis would be that is the most risky estimation that happens in food. Not the least because most small chains do not have the staff to adequately run the numbers.)

And, yes, it is hard. That is part of my point. It is hard, but they address it and give it an effort. With luck, they make progress at getting better.

Contrast with devs. We spend a lot of time blaming others for why it is hard. (Requirements change, etc.) Ironically, this is something that day to day people have to deal with and adjust for accordingly. Based entirely on the historical perspective of dealing with similar items. That is, all of these are metrics that are trackable and reportable. With luck, they can be anticipated through estimation.

</comment></comment></comment><comment><USER13> To paraphrase Donald Rumsfeld, you've got the known unknowns and the unknown unknowns.

It's the unknown unknowns that'll get ya.

</comment><comment><USER14> Using three estimates can help. Create optimistic, likely, and pessimistic estimates for each significant development task. Plug the values into the Program Evaluation and Review Technique (pioneered from building Polaris nuclear submarines in the 1950s) to get a reasonable estimate:

t_{expected} = (t_{optimistic} + 4 \times t_{likely} + t_{pessimistic}) / 6

<http://www.codecogs.com/latex/eqneditor.php>

This also helps indicate what tasks will take the longest, allowing managers to prioritize based on business needs.

</comment><comment><USER15> I think it is best to do incremental estimates. "How long until you have the service deployed to staging with a single 'ping' operation?". When that step is complete: "Ok, now how long to get operation Foo working end-to-end?". This requires trust along the way that people aren't wasting time, but estimating a big project can really screw you. If the estimate comes back for 6 months, and it could have been done in 3, then the project will still take 6 months.

</comment><comment><USER16> If devs are estimating in hours, days or some other measure of time, the game is already over. As a species, we're pretty terrible at estimating absolutes. But we're pretty good at relative comparisons. If I hold up 2 buckets, 1 small and 1 large,and ask you their precise capacity in liters, quarts, etc., most guesses would be off, many quite a bit. If instead I asked you approx how much larger the large bucket was compared to the small bucket - 2x, 3x, 4x, etc., the majority of the guesses would be pretty accurate.

The better option when estimating is using a system that builds on relative comparisons between work items. We use "points" on a sliding scale. Not only does estimating get much more accurate - "We think that enhancement is about 2x as big as the one we just finished", but the estimation process is quicker.

What brings the point estimation system back to calendar time measures is mapping it to how many of those points of work are typically accomplished in a fixed amount of time - basically typical throughput. Knowing that throughout number, it's a quick calc to figure out how long it will take to complete the work. The throughput number also takes into account all of the little things that go on during the day that no one ever remembers to account for - <USER2> breaks, emails, phone calls, chit-chats with co-workers, etc.

I've never worked on a project that estimated things with the absolute (days, weeks, months, years) scale that was accurate and didn't require death-marches at the end. Conversely, I haven't worked on a relatively estimated project (points) that has been late or required anything like a death march to complete.

</comment><comment><USER17> The difficulty of accurate time estimates is not limited to developers. Anyone who's ever ordered food for delivery intuitively knows this, but many people in our industry fail to make that connection. It's the same problem.

The cause of the problem is you make estimates by running a simulation and no matter how complex, the longer the time / the bigger the scale of the project, the more entropy reality will introduce which your simulation did not account for.

Rather than embracing delusion that you can give accurate estimates -- or driving yourself insane trying to reach deadlines you created with incomplete information -- developers should follow the lead of other professions, and when we give estimates make it clear that it is an estimate.

House contractors don't have this problem. Plumbers don't give this problem, and in 2013 even pizza drivers no longer have this problem. Why are we still pulling our hair out trying to give perfect time estimates and follow through on them as though they are gospel?

Here's my rules of time estimates:

1) Under promise, over deliver. Be conservative in your estimates (that means expect it to take longer than you initially think.)

2) Make it clear to whoever this estimate is for that it is only an estimate, and that it is only good for the current parameters of the project. As problems come up, and _when_ the paramters change, the estimate will become insufficient.

3) Don't treat them like gospel. If you do a good job of setting up expectations, sometimes you will finish ahead of "schedule", and unfortunately no matter your best efforts, sometimes you will finish behind. That's OK. This is reality, not a simulation. Things aren't perfect. If you're working with someone who says it's not ok, stop working with that person in the future.

</comment><comment><USER18> If you say something will take an hour, you're almost guaranteed to be wrong, at best you might fall somewhere near that, but you're almost certainly not going to take exactly an hour.

I think that estimating in best case / worst case ranges is useful for two reasons. First it lets you convey uncertainty. Instead of just double a number you made up, you can let people know where you're very certain (narrow range) and totally guessing (wide range). The second valuable thing about ranges is that you can use them to make estimate about projects as a whole. If a project contains a lot of uncertainty, it's results are likely to be uncertain.

We use this technique at LiquidPlanner to generate more realistic schedules, which is pretty damn cool.

The second best thing to do when estimating is update your estimates whenever they change. If you learn something that is going to affect a ship date, speak up!

</comment><comment><USER19> HN's server should automatically insert this link any time the topic of estimation comes up:

[http://www.quora.com/Engineering-Management/Why-are- software...](http://www.quora.com/Engineering-Management/Why-are-software- development-task-estimations-regularly-off-by-a-factor-of-2-3)

</comment><comment><USER20> "Software Estimation: Demystifying the Black Art" provides some interesting insights on the topic. [http://www.amazon.com/Software-Estimation- Demystifying-Pract...](http://www.amazon.com/Software-Estimation-Demystifying- Practices-Microsoft/dp/B00B9ZD20K)

</comment><comment><USER21> In my experience the only thing that improves estimates is being radical about breaking tasks up into small, well defined pieces. If my estimate is 8 hours I'm thinking a workday, which might mean 3 days or more. Avoid the 8 hours thermocline :-)

This has a cost though - most of the big tasks can only be broken up semi- honestly (as opposed to a totally made up division into subtasks) after a significant initial part is done, perhaps to be thrown away. This means they cannot really be estimated, go away, it's done when it's done. But if the iterations are reasonably short then at least the management can watch the estimates grow exponentially in real time. Maybe it sounds pessimistic but at least it minimizes the incentives to make fantasy estimates.

</comment><comment><USER22> I am simply _horrible_ at estimating. I get paid to work on difficult (at least to me) problems; things I haven't done before. A typical project involves trying 9 things that don't work before I find the 10th that does. There is no way I can estimate that sort of thing.

Thank goodness I'm pretty good at managing (i.e. reducing) expectations. When pressed for impossible-to-estimate estimate I fall back to giving a range: "2 weeks to 2 years"

</comment><comment><USER23> Every time I have given a "I do not know, I have never done anything like this before, it will require research, it may take a few days or it may take a few weeks" the response from the manager asking has _always_ been:

"So can you do it by X". Where X seems to be totally arbitrary from a dev perspective.

I have never had a manager say "Ok, get to it and keep me informed".

</comment><comment><USER24> If a developer put in enough time to correctly estimate every quote, he would spend more time estimating than working. I tend to be too optimistic in my estimates, but at least its consistent such that "double it and add a bit" turns my optimistic estimates into accurate estimates.

</comment><comment><USER25> I have always found it interesting how people think things like this are unique to their line of work. Estimating is difficult in any non-trivial operation. Think of roads, buildings, bridges... almost any new product.

<comment><USER7> Estimating construction projects is much easier than software.

Roads? In any developed country, they are a known quantity. Their cost and time can probably be estimated to with a small delta, calculated by the foot (or metre). I think every single street in my city is pretty built the same way.

Buildings? Ask a developer in a new subdivision how long House Model B will take to put up after they've already built 5 of 'em. A new office tower? We've built a few of those.

Bridges? Choose one of the three designs. It's not like you're going to bother trying to invent a new kind.

Your particular piece of software? Unfortunately, still much more like a unique little masterpiece than a construction project, and much more difficult to forecast.

<comment><USER26> And yet construction projects are notorious for going over budget... for small off-the-shelf construction projects (2 miles of road for example) it's feasible, but a new motorway?

And if the weather's bad, the contractor will be claiming for more down days in that 2 miles of road than expected - so there is still an expensive variable.

<comment><USER7> Off the top of my head, two reasons construction projects are notorious for going over budget would be because of labour (union) costs, not to mention corruption (cf. Quebec's Charbonneau Commission).

Why single out weather? Lots of human activities are impacted by weather. What's the analogy to software?

<comment><USER26> > Why single out weather? Lots of human activities are impacted by weather. > What's the analogy to software?

To point out there's still a large variable in the construction projects isted, and it's not as cut and dried as you made out.

Here in the UK (land of rain) the weather is a major source of extra costs in small (under £1M) projects. Source: chief surveyor of a county council's highway department.

The contracts are well negotiated by the construction firm (and I understand is an industry standard clause, so you can't just hire a different firm), so if work can't be done on your project due to inclement weather, they will put in a claime for their labour costs for thse days, plus hire of plant that's on-site. AFAIK they won't get the full cost, but they're good at putting in frequent claims :)

</comment></comment></comment></comment></comment><comment><USER27> Double the time? I'd say quadruple in most cases: [http://blog.pmrobot.com/2011/09/5-steps-to-estimate- software...](http://blog.pmrobot.com/2011/09/5-steps-to-estimate- software.html)

</comment><comment><USER28> [http://www.dilbert.com/dyn/str_strip/000000000/00000000/0000...](http://www.dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/70000/5000/900/75988/75988.strip.gif)

</comment><comment><USER29> <http://en.wikipedia.org/wiki/Planning_fallacy>

</comment><comment><USER30> Why can't people know what they don't know?

</comment><comment><USER31> I can't estimate time because the requirements often times change.

<comment><USER32> Exactly; the question in part reduces to "Why can't specifiers get requirements right the first time?"

<comment><USER33> 1) Scope bloat can come from all sides. I've sat in meetings with eager-to- please devs who insisted on getting clients excited for gizmo-flavor-of-the- month x ("hey, how about we add a Facebook button to have customers share what they bought with their friends!") to the scope of a project just to make themselves look good to their bosses, only to lament about the enormity of how much they had (promised) to do at crunch time.

2) Too often, there is a lack of communication between clients, devs, and project managers. If the project manager is 1) unfamiliar with development (happens a lot, actually) and 2) is unable to correctly walk a client through every nook and cranny of their requirements, then it creates a situation where the client can have expectations in mind that are at odds with the requirements that devs are given.

A great example would be a 'simple' payment system as part of a larger e-commerce site. The client says they have store gift cards, credit cards, and PayPal. Perfect. The dev builds the payment system for the client, and, upon demo, the client sees that there's no option for tax-exempt purchases. "Well, 75% of our business comes from non-profits!" "Amazon lets you do it, it shouldn't be that hard!"

Then, the client notices that nowhere can you process refunds. "Refunds weren't in the original scope," the dev says. "Well, great, but now we can't use this product at all," says the client. Who is at fault? In the client's mind, they're so used to using websites with built in refund and tax-exempt options that it never crossed their mind to include it in their requirements walkthrough with the project manager. On the dev end, devs are very "to the letter" when it comes to requirements. They see credit card, PayPal, and gift card, and implement all three and call it a day.

In my mind, when the requirements bloat, it's a failure on the part of the project manager, whose job is to make sure that nothing gets lost in translation and to make perfectly clear the process for change management. It's a blessing when a client is tech-savvy enough to understand that you cannot miss a single detail.

<comment><USER32> You've left out one role: the developers including the project manager being familiar enough with the domain to ask "Would you like fries with that?" ^_^. In general the model of developers as being "very 'to the letter'" without such a feedback loop is to be avoided, one of many reasons the Waterfall model is very poor.

Your examples are good ones: it's not unreasonable to expect them to know about refunds, but non-profits are a less common example. Although B-to-B is often sales tax free, when you're buying for something to resell (that's where I'm familiar with it, from working for a VAR where I was often the one adding serious value).

</comment></comment></comment></comment><comment><USER34> Because it is impossible. Let me see if I can find that recent article that articulates it better than I can.

<comment><USER34> <http://zinssmeister.co/it-ships-when-it-ships></comment></comment>


Q-Yachts wants to be 'Tesla of the Seas' - <AUTHOR> https://electrek.co/2018/08/24/q-yachts-tesla-of-the-seas-all-electric-day-cruiser-yacht/ <comment><USER2> "Yacht" is a nice branding touch, but this is much more of a boat or cruiser than a "yacht", even by the standard definition [1]. Still, a cool toy for rich people.

[1] [https://en.wikipedia.org/wiki/Yacht](https://en.wikipedia.org/wiki/Yacht)

</comment><comment><USER3> That's a much much much smaller market though.

I also find it very odd that some people want a motorized yacht. There's an almost unlimited source of renewable energy: wind. And it's fun to sail.</comment>