Ask HN Mods: Can you make submission URLs human-readable? - <AUTHOR> By now, I probably stumbled a dozen times upon the problem that HN links do not reveal at all what they are about. To solve this problem you could maybe simply add the title string to the item ID like this:

   https://news.ycombinator.com/item?id=7535606-can_i_delete_my_skype_account
 I think that would be fairly easy to implement and it could be easily made backward compatible by forwarding the old links to the new format. With a dash as separator it's still possible to select the ID with a double click (at least on my system). I think that would be a great improvement. Thanks! <comment><USER2> I like StackOverflow URLs; f.e.:

      /questions/22881084/couldnt-find-bar-with-id-472021-polymorphic-associations

And every URL that matches /questions/22881084 redirects to the main URL.

The URL of this news would become:

      /items/7536719/ask-hn-mods-can-you-make-submission-urls-human-readable

<comment><USER3> I hate those. They contain duplicate information, mostly for the sake of Google rather than users. The fact that /questions/22881084 still works is a nice touch, though. Guess why it's there? People sometimes still type URLs by hand. In that case numerics are actually much nicer than a long-winded textual URL. (An interesting approach would be to use alpha encoding, like ba, bc, bc, etc for the index. More information, easier to type on mobile devices.)

The only case when I like title-based URLs is when they're hand-crafted, memorable and short. Something like example.com/movies/terminator2. Even then you run into problems, because it could be terminator_2 or Terminator_II, or whatever. The moment that URL turns into Terminator_2_Judgment_Day I begin to question its usefulness.

What's wrong with synthetic IDs, anyway? People go on and on about "readability" of URLs, but you have to evaluate it in the proper context. _Where_ are they more readable? If I'm in the browser, I already have the title at _three_ places on my screen (tab, window title, page itself). Sequential numeric ID gives me additional information about order of the articles and sometimes even allows for neat tricks, like skipping to the next article by incrementing the number.

<comment><USER4> Expecting users (or even yourself) to manually enter URLs like "/movies/terminator2" is just not going to work long-term if you can generate the URL based on the title of the page.

It's also not necessarily duplicate information (more like extraneous information), nor is it a disadvantage to have readable URLs. I'm going to explain why by weighing the pros and cons of the main options as I see them.

/questions/how-do-i-foo-bar

Doesn't allow renaming, can't have duplicates with similar titles. Since the lookup key is "how-do-i-foo-bar" it's a variable width string, which is less ideal than a fixed width number/string.

/questions/342993123

Doesn't have the problems above, but now it's not readable. Users can see these URLs in search engines and perhaps more significantly, when hovering over links to see where they go. Google's own SEO guide recommends readable URLs.

/questions/342993123/how-do-i-foo-bar

Best of both worlds. If you redirect "/questions/342993123/*" to "/questions/342993123/how-do-i-foo-bar", you can even allow users to rename titles without having to store the old URL, all while having one canonical version of each "question".

One last thing, those IDs aren't sequential, they're just unique. If you increment a HN news article URL you'll probably end up in a comment (because articles are just root comments), or on other sites, a deleted/spam submission. Sequential only works for content that doesn't change, and most content changes.

<comment><USER3> When I said "duplicate", I meant that both the number and the title are in themselves sufficient to locate the article.

I get the renaming scenario, but I think it is an edge case.

Most duplication can be avoided by appending date or user name to the title _if_ there is already a similar title in the database.

/questions/foo_bar-by_mherkender /questions/foo_bar-2001-01-01

At least this way _unique_ URLs will be short(er) and more memorable.

Overall, though, I think you overestimate the usefulness of named URLs, because you concentrate on specific cases like people linking to something bad on YouTube (that still has an appropriate title) without giving coherent description. There are other cases too. A lot of them. They just aren't as annoying/memorable.

[http://stackoverflow.com/questions/22883751/this-is-not- so-h...](http://stackoverflow.com/questions/22883751/this-is-not-so-helpful- is-it)?

I read a small magazine about PC games, and I recall using ID jumping for navigation a lot. When the numbers are below 1000, it is easier to remember and type "article=234" than "/article/Does+Assassin's+creed+break+new+ground?".

Also, I sincerely think that the trend for named URLs has more to do with Google that what users want or like. If Google liked super-long URLs with lots of punctuation, most websites would do just that and people would find ways to rationalize the trend. This doesn't automaticall mean title URLs are wrong, but it's somewhat different from "everyone like them".

<comment><USER4> Using dates is a good alternative, but they're not a universal solution. If Microsoft open-sources Windows XP you can be sure that dozens of articles titled "Windows XP open-sourced!" will end up on HN that day, and a site that rejects articles because they have the same title as another has a bad user interface. That said, if there's a small enough amount of content, it might be good enough.

I'm not saying sequential ID URLs are bad, they're still possible in my suggestion, I was just explaining how navigating by incrementing a number isn't plausible for sites with large amounts of user-generated content. It usually doesn't scale.

Anyway, I'm not overestimating the advantage of readable URLs. You haven't given any reason why readability isn't an advantage in URLs, and I've given several explicit reasons why they are (SEO, hovering over links, etc).

</comment></comment></comment></comment></comment><comment><USER5> Here are two bookmarklets which might accomplish what you are requesting:

        javascript:window.location=window.location+'&title='+document.title

        javascript:window.location=window.location+'#'+document.title

I don't mind the simple IDs for HN URLs.

The thing that I have the most trouble with is when bookmarking comments sections by dragging the "XX comments" link to my bookmarks bar, the title then saves as "XX comments" rather than the title of the article. This might be a browser / HTML issue though, I tried adding a "title" tag but that didn't fix it.

Updated bookmarklet below:

        javascript:window.location=window.location+'&title='+document.title.replace(/[^A-Za-z0-9]/g, "_");

<comment><USER6> If you add converting non-url-safe characters to dashes I would call that bookmarklet a >90% sufficient solution that doesn't need any server-side changes.

Users who need a readable URL just use the bookmarklet.

<comment><USER5> Just replace document.title with document.title.replace(/[^A-Za-z0-9]/g, "_"); and it should work with all titles.

</comment></comment></comment><comment><USER7> That is a good request. What will make the old url does not need any forwarding is add a new get parameter, such as:

[https://news.ycombinator.com/item?id=7536719&title=Ask_HN_Mo...](https://news.ycombinator.com/item?id=7536719&title=Ask_HN_Mods:_Can_you_make_submission_URLs_human- readable)

</comment><comment> Pirate-of-SV Or by using anchors, it's backwards compatible by design.

        https://news.ycombinator.com/item?id=7535606#can_i_delete_my_skype_account

<comment><USER8> One would want to ensure that the anchor was guaranteed to be distinct from every id on the page (e.g. if this submission had title 'up_7536771', browsers would jump to your upvote button if the title was just appended).

<comment><USER9> You can just prepend a character that is valid in the URL but invalid for an id, like a colon. E.g.

      https://news.ycombinator.com/item?id=7536719#:ask_hn_mods

</comment></comment></comment><comment><USER10> Why not actually have separate resources (and URLs) for each story, rather than have all stories ever as 'item'?

        https://news.ycombinator.com/items/7535606/can_i_delete_my_skype_account

<comment><USER3> I never understood why people are so hell-bent on advocating [https://example.com/item/7536855](https://example.com/item/7536855) over [https://example.com/item?id=7536855](https://example.com/item?id=7536855), or even [https://news.ycombinator.com/?item/7536855](https://news.ycombinator.com/?item/7536855) in human-readable websites.

The last form is short, allows for the simpler routing and much easier linking on the backend as you don't have to do any magic to resolve relative URLs. That's a tangible benefit, and it can make some code and operations much simpler. (For example, you could add an alternative page called item2, and it would happily reuse all the resources of item just via relative URL resolution.) Ability to use direct links () also means more readable templates and easier time finding what links where.

The first form is supposedly "hierarchical" and "more semantic". What does that buy us in practical terms?

<comment><USER11> Most modern routing systems I've worked with can match against any of the URL schemes you describe, without any difference in flexibility. Segments of the path can be tied to hardcoded routes, or passed into handlers as parameters, or any combination thereof. And relatively URLs work just fine as "/comment/123". I'm not sure I understand what you mean by "direct link".

<comment><USER3> With enough code you can parse anything. My point is that query-based linking can greatly simplify your overall codebase and let the _standard URL resolution_ in the browser do most of the work for you.

Let's look at two examples: example.com/?article/123 vs example.com/article/123.

In the first case you can link to example.com/assets/main.css by simply using . It will work with no additional code. It will work from the root of the website, from ?article/123, or ?article/456, or ?any/other/place/you/want.

In the second case you need to reverse your routing logic, because "" will work on some pages, but will break on paths with more nesting (such as example.com/articles/about_it/123).

In ASP.NET MVC, for example, linking looks like . They've added a shorthand for it in Razor 2, but that means that the overall codebase is even more complex: your templating engine parses the content of your templates, find things that look like virtual URLs, reads the routing table, performs reverse relative resolution, and spits out the altered URL. It is extremely difficult to debug if something goes wrong. Is all this complexity really warranted?

If you're using PHP/Apache, query strings have an additional benefit of not needing any routing setting in .htaccess. Makes deployments somewhat more straightforward.

Also, you can easily implement "areas" with different assets by creating an actual sub-directory with an alternate index script, then copying and editing assets. This is way, way easier and more maintainable than all of the dynamic solutions I've seen.

"Wait", some people say, "but what if you change stuff?" If you change something on the backend, you change your routing tables to match it, so the external URLs stay the same. Yes, you still need routing. But now it only does one thing. You've decoupled routing from other components and made templates much simpler and more readable.

<comment><USER12> IMHO the most important reason for not doing so: queries are not made for that! Queries are queries, not routes. You should route with routes (completely unexpected), not with queries. The difference between query and route actually _means_ something to the software interacting with your site.

I only hate one thing more that using queries where you should use routes: using routes where you should use queries (especially common in shady SEO stuff).

> query-based linking can greatly simplify your overall codebase and let the > standard URL resolution in the browser do most of the work for you.

It does not simplify my overall codebase at all. In fact, query routing will add lots of unnecesary code to my codebase if I have to parse the query as a route, while the route is already parsed as a route.

> In the second case you need to reverse your routing logic

Id's just  with a leading slash. Again, that's what / is for.

> If you're using PHP/Apache, query strings have an additional benefit of not > needing any routing setting in .htaccess.

I think that was exactly what early 2000s forum developers thought, but as they learnt soon it was a really bad idea.

Don't do that. Please.

<comment><USER3> _IMHO the most important reason for not doing so: queries are not made for that! Queries are queries, not routes. You should route with routes (completely unexpected), not with queries._

This does not highlight any practical or even realistic theoretical benefits of using routes over queries. Besides, it's called "path", not "route", and I don't know of anything in URI spec that would support your vision.

       The query component contains non-hierarchical data that, along with
       data in the path component (Section 3.3), serves to identify a
       resource within the scope of the URI's scheme and naming authority

_Id 's just  with a leading slash. Again, that's what / is for._

This breaks if you need to re-deploy to a sub-directory.

 _I think that was exactly what early 2000s forum developers thought, but as they learnt soon it was a really bad idea._

The only reason I know of that it was bad idea in 2000s is because early search engines arbitrarily assigned different values to words in query strings. This has changed.

<comment><USER12> > Besides, it's called "path", not "route"

Path and route are synonyms (I might be confused because of my mother tongue) and I wanted to highlight that fact: you should use routes (paths) to route.

> and I don't know of anything in URI spec that would support your vision.

[http://tools.ietf.org/rfc/rfc3986.txt](http://tools.ietf.org/rfc/rfc3986.txt) section 3.4 the very first sentence says: "The query component contains non- hierarchical data"

Your proposal "?article/123" seems very hierarchical to me. You even used path-like syntax and "routing via queries" sounds inherently hierarchical. You should use a path instead.

> This does not highlight any practical or even realistic theoretical benefits > of using routes over queries.

Of course it doesn't if you strip the important part of my comment :P Quoting myself: "The difference between query and route actually means something to the software interacting with your site."

It's akin to inventing your own HTTP verb.

> This breaks if you need to re-deploy to a sub-directory.

Then you should use <base>. That's why it's there, so you don't have to jump through hoops.

Using queries for navigation is just as bad as the defunct habit of using hashbangs, which served a purpose when there was no alternative. The technology moved forward and we have better solutions.

<comment><USER3> Firstly, routing is not inherently hierarchical. It's a process of mapping pieces of URL to variables with the purpose of figuring out which action to call. So your argument that implies routing it inherently related to URL paths (by the virtue of their names) is invalid. It can and often does involve queries.

Secondly, if you ever tried to implement a web framework from scratch, you would quickly see that routing something like "?controller=blah&action=blah&id=123" is MUCH easier than dealing with virtual paths. Aside from relative URL issues in templates, you also need to deal with differences between real assets and everything else.

Thirdly, my proposal does not go contrary to rfc3986. "The query component contains non-hierarchical data" is not the same as "query component must not contain any hierarchical data". If it did, you could also argue that it's "wrong" to put an address int query string, because, hey, it's a hierarchy. (And again, routing is not inherently hierarchical.)

Fourthly, base tag doesn't deal with the original use case I described and is a PITA to maintain.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> While I agree that HN URLs are are very non-descriptive, one problem of the proposed solution might be submissions that get their titles edited by mods later?

<comment><USER14> That's not an issue if _only_ the ID is used to identify the submission, whereas the title slug is only human-readable fluff. E.g

        /item/1234/original-submission
        /item/1234/edited-title
        /item/1234/arbitrary-string
        /item/1234/

This could also be done with the current query string approach, e.g.

        /item?id=1234&title=original-submission
        /item?id=1234&title=edited-title
        /item?id=1234&title=arbitrary-string
        /item?id=1234

OP's suggestion of having the title be part of the ID would be quite inelegant, but possible if the real ID is only the digits up to the first hyphen.

Ideally, the title would be completely ignored, but other titles would redirect to an URL with the current title.

<comment><USER15> I actually think the OP's suggestion is the most elegant of everything I've seen here.

It's a matter of aesthetics.

</comment></comment></comment><comment><USER16> What about items which do not have titles, like comments?

<comment><USER17> Either nothing, or:

[https://news.ycombinator.com/item/7536783/pearjuice-what- abo...](https://news.ycombinator.com/item/7536783/pearjuice-what-about-items)

Or:

[https://news.ycombinator.com/item/7536783/pearjuice- comment-...](https://news.ycombinator.com/item/7536783/pearjuice-comment-on- Ask-HN-Mods-Can-you-make-submission-URLs-human-readable)

</comment></comment><comment><USER18> It's an interesting suggestion, but I'm not sure I clearly see the value, especially compared to the other things we have to do.

(I'm going to demote this thread now, rather than kill it, so anyone who wants to can continue discussing.)

</comment><comment><USER19> Why is this a "problem"? I frankly consider it a feature: the URL is shorter, and it encourages people to put a real title next to the URL that is actually designed for humans to read and understand. Schemes that embed titles either lock tbe title in for all time (which is clearly problematic and confusing once the URL changes) or make the title just ancillary URL cruft. (I believe Wordpress goes with the former, while most other websites go with the latter, including reddit and Stack Overflow; I would be willing to believe that I'm wrong about Wordpress, though.)

The ancillary URL cruft version of the feature means the page effectively now has an infinite number of possible URLs and no effective "canonical" one without running into the "title changed" problem. It doesn't let you know what's on the other side before clicking, because you can change it to read whatever you want (or remove it entirely, for the people who like the intrigue or surprise). By making the URL longer it is more likely to be broken apart and formatted horribly. It causes people to go "engh, the URL is sufficient" and then not provide their own title, leaving the reader to have to read the mangled "all lower case, no punctuation, space characters missing, truncated" version of the title out of the URL; and even when the mangled form is clearly confusing it makes adding the title again more costly (longer message that night no longer fit that feels horribly redundant).

Of course, if the URL is further designed to be human rememberable or human guessable, where you can reasonably expect the user to type the URL in is, that's great! restaurant.example.com/menu/ is an amazing URL; but restaurant.example.com/8364928/restaurant-s-daily-menu/ has neither of these features: these "embed the title" schemes are just abusing URLs as storage for content that simply should not be in the URL.

It certainly isn't like this is some requirement for success: YouTube has done very well for itself without succumbing to the "embed the title" mistake. Facebook does not embed titles of posts in their URLs. Pinterest and Instagram could easily build such a feature out of the short descriptions attached to images, and Twitter could have snipped some of the tweet text, but thankfully none of them chose to. Even after being "in the game" for many years, Google (of all people) did not do this for Google+ either (though some might say Google+ isn't highly successful, and some even blame the URLs, it should be clear that tacking a title to the end of the URL would not solve any of their problems ;P).

Really, there is only one benefit I've ever seen for putting the titles in the URLs, which I think was most eloquently described by a user on reddit a few years ago in a thread on this very topic. I have provided a link to this thread, but will point out that this is a very niche use case that itself should probably not be encouraged :/.

        http://www.reddit.com/r/AskReddit/comments/1gbl0u/why_does_reddit_put_titles_in_their/

<comment><USER20> "these "embed the title" schemes are just abusing URLs as storage for content that simply should not be in the URL."

I don't look at it this way. I think readable URLs are part of the way the web was designed - this idea that URLs map to individual documents and not to an application that has to translate between the URL and the resource it represents.

Quite to the contrary: Having a database id in the URL is sticking model/data layer logic where it doesn't belong - the view layer of the APP.

As for the permalink problem on changing titles you can simply store a history of redirects for every title that the article has ever had to the current, active URL.

<comment><USER21> Having an id in the URL lets you have a key to uniquely query. Without it, you would have to disallow identical titles.

What benefit do you get from having a title in the URL?

I think of a URL as simply an easily repeatable parameter of a web request. The URL is only one parameter of the request, but it's the only one that's easy to repeat.

</comment></comment></comment><comment><USER22> [https://news.ycombinator.com/item?id=7536719&title=this+is+a...](https://news.ycombinator.com/item?id=7536719&title=this+is+a+stupid+idea)

</comment><comment><USER23> Although I like this idea, I wouldn't want this feature to get prioritized over making the layout "responsive" on mobile browsers.

(I've tried a few HN "apps" on both iOS and Android. Either they reinvent the UX too much for my taste, or they're no-login/read-only ... or even if they get those points correct, they have intermittent "no comments" errors when there are in comments. Sigh. Really I just want the web site. Albeit updated to work better on smaller screens.)

<comment><USER24> What's wrong with the desktop version?

It works great on my 320x480 screen in landscape. The only thing that would make sense would be to limit the viewport width, other than that I don't see anything wrong.

<comment><USER25> I personally find reading HN on a mobile device really frustrating. Horizontal scrolling is awkward and navigating between comments is frustrating. HN isn't winning any awards for UX.

I really do believe that HN is poorly designed for end users. The UI is not forward with intent, or pleasurable to use. It's been literally years and the expired link issue hasn't been addressed. ---No, I'll stop you right there. It's been acknowledged as an implementation bug, but not __addressed __. PG 's lack of user empathy and stubbornness make HN worse.

The only reason people come here is the content.

</comment></comment></comment><comment><USER26> I agree, but it's probably easier to implement a simple URL forwarder somewhere else to not mess with HN for now, specially that things are changing a bit: [http://blog.ycombinator.com/meet-the-people-taking-over- hack...](http://blog.ycombinator.com/meet-the-people-taking-over-hacker-news)

<comment> k-mcgrady Wouldn't this be the perfect time to suggest changes? It's important to let the new people in charge know what the community would like I think.

<comment><USER26> Yeah totally agreed on this. +1 for this and for other suggestions.

</comment></comment></comment><comment><USER27> here are (my) URL rules which have served me very well over the years.

• URL-Rule 1: unique (1 URL == 1 resource, 1 resource == 1 URL)

• URL-Rule 2: permanent (they do not change, no dependencies

to anything)

• URL-Rule 3: manageable (1 logic per site section, no

complicated exceptions, no exceptions)

• URL-Rule 4: easily scalable logic

• URL-Rule 5: short

• URL-Rule 6: with a targeted keyword phrase

one is more important than two to six combined, two is more important than three to six combined, and so on.

adding a "human readable text thingie" slug is number six. least important. meanwhile it makes 1 to 3 much harder, and runs against nr. 5.

so basically: don't do it, never. it complicates everything. if you can give a fulfil "human readable" and "short" and every other rule, do it. i.e.: www.example.com/a/contact is great. even www.example-shop.com/a/blue-coffee- maschine is great, but www.example.com/b/343435354-you-can-write-here- everything-you-want-and-i-will-trigger-a-redirect-if-its-wrong is a very very bad idea.

</comment><comment><USER28> If you feel you need to append a title to the URL, why not just do [https://news.ycombinator.com/item?id=7536719&title=Ask](https://news.ycombinator.com/item?id=7536719&title=Ask) HN Mods: Can you make submission URLs human-readable

It shouldn't break the URL and the user will see a title in it.

</comment><comment><USER29> I'm just guessing here but one of the reasons might be to prevent ranking high in search engine results. Search engines bring in lots of misguided traffic and lots of users which don't fit into the HN community. Again I'm just guessing...

<comment><USER30> #shit_HN_says

<comment><USER31> No, as fun as I'm sure that glib comment was to write, he's not making that up. HN does keep a low Google footprint. I don't know how much it has to do with keeping the community small, but I appreciate that comments I write here don't immediately get nailed to the front of a Google SERP.

Here's Paul Graham, briefly, on the subject:

[https://news.ycombinator.com/item?id=5808982#up_5808990](https://news.ycombinator.com/item?id=5808982#up_5808990)

<comment><USER29> thanks for providing the link. couldn't find it myself, but this was the statement I had in the back of my mind.

</comment></comment></comment></comment><comment><USER32> I'm sure there are many more useful changes that could be made which would bring greater benefit to the community.

Adding the 'initial scale' meta tag so that people can more easily use the site on their mobiles would be a great start.

</comment><comment><USER33> Can we start please with many far more annoyUnknown or expired text.

</comment><comment><USER34> Instead of changing the URL you could use the "title" attribute on the "a" tag. On most browsers hovering over the link will display the attribute.

<comment><USER35> How does that help in situations where HTML isn't being used, though? I'm thinking of plain text emails, discussion forums that don't allow custom markup, discussion forums that generate markup automatically for URLs, and so forth.

<comment><USER36> I find long URLs to be annoying in email since you never know if they will get wrapped and broken somewhere along the way. And, if you're emailing a URL to someone you are presumably providing some text to explain what it is, so why do you need extra junk in the URL?

You can already add whatever you want to the URL if you really think it needs to be verbose:

[https://news.ycombinator.com/item?id=7536719&title=whatever-...](https://news.ycombinator.com/item?id=7536719&title=whatever- I-want-here)</comment></comment></comment>


Drilling surprise opens door to volcano-powered electricity - <AUTHOR> http://theconversation.com/drilling-surprise-opens-door-to-volcano-powered-electricity-22515 <comment><USER2> Besides creating electricity, there are many potential industrial uses of magma:

"Magma serves as a heat source, replacing fuel in magma smelters, magma forges, magma glass furnaces, and magma kilns...Other uses for magma include obsidian farming, trap design, melting ice, igniting fires, and even garbage disposal." [1]

[1] [http://dwarffortresswiki.org/index.php/DF2012:Magma](http://dwarffortresswiki.org/index.php/DF2012:Magma)

<comment><USER3> Then one day someone leaves a sock on the ground starting a series of events that ends with everyone in Iceland being either dead or insane.

<comment><USER4> Urist Björnsson cancels Pickup Item: on fire

</comment></comment></comment><comment><USER5> The problem with geothermal power is access. It's the reason why Iceland is almost entirely powered by renewables, and why the rest of the world isn't.

So if Iceland finds pockets of magma at 5km, it's only really a breakthrough if you can access magma at shallow depths in other regions.

<comment><USER6> There is, however, access in a number of regions where geothermal can be quite useful.

Iceland doesn't have a large population (332,000), but it's relatively close to Europe (or at least Ireland), and there have been proposals to link it via undersea transmission cables to the European grid.

Other significant resources exist around much of the Pacific Rim, including in Hawaii (limited population and a long way from nowhere), Japan (high population and critical energy resource ocnstraints), the Philippines, New Zealand, and the Pacific coast of the US. One of the largest present geothermal installations is The Geysers in California, with just under 1 GW of installed capacity. The largest geothermal resource within the US would be the Yellowstone supercaldera, and though this is presently protected from development, it represents a vast energy potential, as much as 20% of present US electric generating potential under some estimates. The National Park Status means that research is highly limited, so take with a very strong dose of salt.

Other significant resources exist in Kenya (another rift zone, as is New Zealand). Given Africa's status as a developing region, this is potentially hugely useful.

Geothermal has been significantly developed in many of these areas. I did some digging and apparently the Philippines has developed as much as 50% of its potential, where it provides 16% of the nation's electricity needs. Japan and the US have also done considerable development, as, of course, has Iceland.

[https://en.wikipedia.org/wiki/Geothermal_power_in_the_Philip...](https://en.wikipedia.org/wiki/Geothermal_power_in_the_Philippines)

Geothermal offers a number of very useful characteristics in a renewable / sustainable energy mix, including:

⚫ Base-load potential. Geothermal runs 24/7, is dispatchable (that is, you can throttle it up or down), and balances the nondispatchable nature of wind and solar energy.

⚫ Proven. Geothermal has been in active commercial production for decades. This is proven technology.

⚫ Relatively low local impacts. Plant footprints are small and local environmental disturbance fairly limited. Water needs and the possibility of locally-induced earthquakes (most minor) are possible concerns.

But it is still limited to specific locations for high yields. And if you're drawing sufficient amounts of thermal energy from even high-yield caldera, it can take a considerable period of time (decades) for a geothermal zone to recover. This is particularly a concern with "EGS" (enhanced geothermal systems) in which boreholes are drilled into otherwise only marginal zones. Often a single borehole's useful life is limited to a decade or two.

<comment><USER7> > there have been proposals to link it via undersea transmission cables to the > European grid

A transmission cable is sometimes discussed, but so far Iceland has been taking advantage of the fact that aluminum smelting is a workable way to congeal cheap power into transportable money. Aluminum smelting is typically by electrolysis [1], and aluminum is light and compact relative to its value so easy to ship, so smelting aluminum and exporting it essentially allows you to "export electricity". Not at the same rates as you could sell actual electricity, but with easier transport/storage characteristics that makes it still attractive. The largest power plant in Iceland (a hydro one) is entirely purpose-built solely to power a smelter [2].

[1] [https://en.wikipedia.org/wiki/Hall%E2%80%93H%C3%A9roult_proc...](https://en.wikipedia.org/wiki/Hall%E2%80%93H%C3%A9roult_process)

[2] [https://en.wikipedia.org/wiki/K%C3%A1rahnj%C3%BAkar_Hydropow...](https://en.wikipedia.org/wiki/K%C3%A1rahnj%C3%BAkar_Hydropower_Plant)

<comment><USER6> Right. Much as food production is an alternative to exporting water, aluminum (or fertilizer) productions are alternatives to exporting energy.

You'll typically find aluminium smelters where electricity is cheap. E.g., the Pacific Northwest / Western Canada, where ample hydroelectric resources exist.

<comment><USER8> > Much as food production is an alternative to exporting water

There's only very little water in exported food, so as long as you're not using non-replenishable sources (like fossil water) or limited sources (like rivers) for food production, the amount of water that is actually exported is negligibly small.

<comment><USER6> _There 's only very little water in exported food_

The point isn't how much water is physically _in_ food exported, but how much was required to _create_ it. From this Forbes article:

[http://www.forbes.com/2008/06/19/water-food-trade-tech- water...](http://www.forbes.com/2008/06/19/water-food-trade-tech- water08-cx_fp_0619virtual.html)

 _We don't realize it as we sit down to a meal, but most crops require huge volumes of water to grow: 65 gallons to grow a pound of potatoes; 650 gallons for a pound of rice._

 _Often, food supplies are only maintained at the expense of literally emptying some of the world's great rivers, such as the Indus in Pakistan, the Yellow River in China and the Nile in Egypt. Elsewhere, underground reserves are being pumped dry._

 _But increasingly, countries are giving up on trying to feed their populations from their own resources and are switching to food imports. That means they are also importing the water embodied in the crops, or virtual water. Every ton of wheat arriving at a dockside carries with it, in virtual form, the thousand tons of water needed to grow it._

And if you're looking at meat, it's much higher -- about 2,500 gallons per pound of beef.

Similarly, it's not that you're going to get zapped by electricity when touching aluminum, but the _amount_ of electricity required to _extract_ that aluminum is vast.

<comment><USER8> Maybe you should have actually read my comment: I was explicitly excluding cases where river or fossil water is being used.

And the "65 gallons of water per pound of potatoes" is utter bullshit. Whether rain falls on untouched grass land or on potato plants does not matter to the water ecosystem.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> I'd love to see an xkcd "What if" follow up to this article exploring the idea of pin-holing the planet with these vents, the peak PW output, and the effects of the resulting cooling.

<comment><USER10> I just submitted a question on "running out" of renewable energy that included this scenario, so fingers crossed!

</comment></comment><comment><USER11> About about using the $1 Billion in natural gas they burn off every year in North Dakota for electricity instead of just heating the atmosphere.

[http://www.dailymail.co.uk/news/article-2269517/The- picture-...](http://www.dailymail.co.uk/news/article-2269517/The-picture- space-shows-U-S-oil-field-burning-gas-power-Chicago-AND-Washington-cheaper- selling-it.html)

[http://www.nytimes.com/2011/09/27/business/energy- environmen...](http://www.nytimes.com/2011/09/27/business/energy- environment/in-north-dakota-wasted-natural-gas-flickers-against-the- sky.html?_r=0)

<comment><USER12> I seem to be one of the few persons commenting so far who actually lives in the region and regularly reads local reporting on issues in North Dakota (a state neighboring my state). Western North Dakota, where the Bakken Shale oil boom is occurring, is very sparsely populated and historically had minimal infrastructure. It takes TIME to build pipelines to move the natural gas brought up by oil drilling operations to natural gas customers. Pipeline proposals are currently in regulatory review. There isn't even pipeline infrastructure in place yet for all of the petroleum production in North Dakota--much of the oil produced there is brought to broader markets in tanker trucks, and the truck traffic volumes are putting a lot of stress on highway roadbeds until the highways can be upgraded. Right now there is a boom economy in western North Dakota, with extremely high wages, low unemployment, a shortage of single women,

[http://www.twincities.com/national/ci_22382285/north- dakota-...](http://www.twincities.com/national/ci_22382285/north-dakota-oil- boom-unsettles-gender-balance-some)

and established businesses in the region importing workers from as far away as Illinois just to keep up normal operations as workers quit to join oil field crews. There hasn't been time to build infrastructure yet to move away the natural gas to markets that will pay for the gas--especially because the price of natural gas all over the United States has crashed because of the huge increase in production in the last few years. But given time, yes, there will be infrastructure in place to transport Bakken Shale gas to other markets, and I'm sure that we here in Minnesota will be as glad to have North Dakotan natural gas to supplement our nuclear-powered energy grid as we already are to have North Dakotan petroleum brought in by truck. Once more pipelines are built, the entire United States energy economy will become more flexible.

Still to be figured out is the economics of converting natural gas deliquefaction terminals (those cost BILLIONS of dollars and years to build or convert) along the Gulf Coast into liquefaction terminals, so that the United States can get into the business of exporting liquified natural gas. It could happen. North Africa and the Arabian Peninsula used to flare off all of their natural gas incidentally brought up during petroleum production--there was no local market for it. It took a long time to develop natural gas liquefaction; now there is international trade in natural gas that was undreamed of when I was growing up.

<comment><USER13> I don't get it. If you don't have the capacity to transport what you are producing, you can't be producing. Or put very simply: you can not be allowed to burn off unwanted gas. The cost is certainly not _zero_ , it is an enormous sum that dwarfs whatever profit they could hope to get from selling it, and it is failed states only that would allow this massive negative externality.

There seems to be no learning in the American midwest. Every other time some novel way of destroying the environment comes along, disenfranchised states quickly clear out _all regulatory law_ to make place for the new boom, and when it's over they are left with unemployed single men with a bunch of new trucks and a wrecked environment while the companies made off with the profit.

<comment><USER14> Burning the gas as waste contributes CO2 to the atmosphere, but burning the gas for productive reasons still produces that same CO2.

If it were burned for productive reasons, some of the thermal energy released would be stored in chemical bonds formed by the manufacturing of any number of things, but most of it would ultimately still be released into the atmosphere as waste heat during _some_ stage of its use.

There is the angle that if more natural gas were used to generate electricity, then less coal burning would be required. That certainly is an argument for getting and burning more natural gas in power plants, but barring that possibility in the present due to poor logistics, we will still be burning that coal whether the natural gas is burned off as waste, or whether it is never pumped up in the first place.

We could also spend money taking the gas and shoving it back where it came from, but that really is not practical.

The bigoted attitude towards the mid-west is uncalled for, even if you don't like what is going on in North Dakota.

<comment><USER15>
      > Burning the gas as waste contributes CO2 to the
      > atmosphere, but burning the gas for productive
      > reasons still produces that same CO2.

True, but if has to be burned, it may as well be productive. Moreover, if it's burned unproductively now, then presumably there is other productive CO2 being released now as well (unless we start accepting black-outs). There could be as much as two units of CO2 being released now, versus a single unit of CO2 otherwise. So that's more CO2 over a short time-scale.

There are time-scales over which releasing CO2 is more or less harmful; I don't pretend to know the critical ones. However, it seems self evident that if that rate of release can be slowed, then its consequences will be less harmful, even if the total amount of CO2 released by T_{infinity} is exactly the same.

<comment><USER14> > _" Moreover, if it's burned unproductively now, then presumably there is > other productive CO2 being released now as well (unless we start accepting > black-outs). There could be as much as two units of CO2 being released now, > versus a single unit of CO2 otherwise. So that's more CO2 over a short time- > scale."_

I assume that either way, we are going to eventually burn it until depletion. We can't keep it up forever, we will need to switch to renewable energy at some point and that renewable energy will be carbon neutral.

It's a shame that it is being wasted instead of used for something productive, but I am just not convinced that it is some sort of environmental disaster.

<comment><USER16> I don't think we will run out of gas before we switch to renewables. The supply of gas (as in, the amount of gas that can be produced per month) is limited and the demand for energy is always increasing, so prices are always going to go up. As new technology develops, and with economies of scale, renewables are getting cheaper. I think we'll get past the tipping point where renewable generation + storage is cheaper than fossil fuels well before we actually run out of gas. Being inefficient with our resources (like burning gas like this) means we'll be much worse off when that happens.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> For many years I imagined that space faring future humans would depend on hydrogen gas clouds as the source of their energy. Think: intergalactic highways with gas-stations at such formations. But this brings another resource to mind: In the future, we might view planets, not merely for their mineral resources, but also for the heat that may be trapped within them (AFAIK not all planets have a hot, molten core).

Autonomous planetary settlement bots; colonizers of planets. Harnessing the energy trapped within the planet to refine minerals on the surface or terraform the surface.

<comment><USER6> Stars are fusion plants.

Sufficiently large planets are dual gravitational + fission plants. There's pretty good reason to believe there may be active natural sustained chain reaction fission reactors within the Earth's inner mantel / outer core (for reasons the geologists / geophysicists are better able to explain, apparently not in the core itself). There's also considerable latent heat from formation -- even after 4.5 billion years (rock is a good insulator).

But not all planets have molten interiors (Mars doesn't). And many aren't particularly accessible: Venus has that little atmosphere problem, Mercury's a tad toasty, and gas giants don't give your legs a leg to stand on. Plus gravity.

Visions of spacefaring humans are, I suspect, mostly strongly fantastical:

[http://www.antipope.org/charlie/blog- static/2007/06/the_high...](http://www.antipope.org/charlie/blog- static/2007/06/the_high_frontier_redux.html)

[http://www.antipope.org/charlie/blog- static/2009/11/the_myth...](http://www.antipope.org/charlie/blog- static/2009/11/the_myth_of_the_starship.html)

[http://physics.ucsd.edu/do-the-math/2011/10/why-not- space/](http://physics.ucsd.edu/do-the-math/2011/10/why-not-space/)

<comment><USER18> I don't buy it. Those articles just make it sound like any truly future craft needs to include a biome and fission reactor; in short, an aircraft carrier with Wisconsin fast plants. But sci-fi has been pointing us in this direction for ages. The Apollo missions were amazing, Space-X is amazing, but they are very much more like knarrs ([http://en.wikipedia.org/wiki/Knarr](http://en.wikipedia.org/wiki/Knarr)) than the caravels ([http://en.wikipedia.org/wiki/Caravel](http://en.wikipedia.org/wiki/Caravel)) that came later and found the new world.

<comment><USER6> Um. What exactly are you suggesting.

Oceans are capable of being crossed by little more than someone clinging to or sitting on a log (not with a particularly high survival rate, mind). Or bundles of papyrus reeds or balsawood rafts, as Thor Heyerdahl demonstrated. I personally know several people who've _rowed_ across oceans. Some of them multiple times and/or multiple oceans.

The odds of rowing to Ceres or Alpha Centauri, let alone the Andromeda Galaxy, on a log raft, are rather slim.

</comment></comment></comment></comment><comment><USER19> It sounds like they didn't intend to drill into magma, but is it possible to survey the land and intentionally find magma near the surface to exploit in this manner?

If not, isn't the question of whether you can effectively harness the energy or not moot?

<comment><USER20> Not going to say its easy. But you can pretty accurately map magma under the surface using seismology. I believe it requires an earthquake and having the correct equipment in place, so its far from ideal. But it does work well.

<comment><USER21> It's been awhile since I've sat in on geology, but I seem to recall that they can use short-range seismic signals (by firing a shotgun shell into the ground). I'm not sure as to the resolution -- one could imagine getting better resolution firing multiple shells simultaneously over a certain area. My $.02

<comment><USER22> 30 years ago remember USSR used underground nukes at least once specifically for exploration of oil/gas in Siberia.

<comment><USER14> _" 39 explosions for the purpose of geological exploration (trying to find new natural gas deposits by studying seismic waves produced by small nuclear explosions)"_

(As well as several other interesting tests/uses)

[http://en.wikipedia.org/wiki/Nuclear_Explosions_for_the_Nati...](http://en.wikipedia.org/wiki/Nuclear_Explosions_for_the_National_Economy)

</comment></comment></comment></comment></comment><comment><USER23> Tap Yellowstone's geothermal. See if we can't get greedy enough for energy extraction that we end up preventing a supervolcano.

<comment><USER24> I do wonder to what extent we can mitigate potential future volcanic activity by preemptively pulling energy out of hot spots like this.

The odds are low, but a supervolcanic detonation in Yellowstone would be one of the most serious threats to the United States (or even the planet), so if we can mitigate it slightly while actually profiting from the process that seems worth pursuing.

</comment></comment><comment><USER25> _According to the International Geothermal Association, 10,700MW of geothermal electricity was generated worldwide in 2010_

I doubt they said that.

<comment><USER26> Why?

<comment><USER27> Power is a measure of... power, not energy. MW/year is a silly unit. In the US energy production on an annual basis is given in BTUs, or Joules (usually quadrillions of BTUs, depending on the scale). Perhaps the article meant 10.7 GW of installed production capacity. Regardless, that's about 0.3 quadrillion BTUs per year, which is a blip compared to the world's energy consumption.

<comment><USER28> > Perhaps the article meant 10.7 GW of installed production capacity.

The original report does indeed, the article misquoted (and possibly misunderstood) it. Here is the exact quote and its surrounding paragraph:

> In 2005, there were 8,933 MW of installed power capacity in 24 countries, > generating 55,709 GWh per year of green power, according to the > International Geothermal Association. IGA reports in 2010 that 10,715 MW is > on line generating 67,246 GWh. This represents a 20% increase in geothermal > power on line between 2005 and 2010. IGA projects this will grow to 18,500 > MW by 2015, which based upon the large number of projects under > consideration appears reasonable if not conservative.

> Regardless, that's about 0.3 quadrillion BTUs per year, which is a blip > compared to the world's energy consumption.

note that the quote is about electricity generation, not power consumption in general.

Still a blip though, in 2008 global electricity generation was estimated at 20261 TWh, geothermal production thus accounting for ~0.3% of global production.

A few select countries have fairly high geo ratios though: Iceland's at 30% geothermal, the Philippines at 27%, El Salvador 25%, Costa Rica at 14% and Kenya at 11.2% (2010 numbers).

The US are the biggest producer of geothermal electricity (29% of global production, #2 is the philippines at 18%) but the ratio matches global, geothermal is 0.3% of the US's electricity production.

</comment></comment></comment></comment><comment><USER29> Old trick. The USSR built geothermal power plants since 1966. But this tech is only available in very specific geological conditions. What is more energetically interesting in Scandinavia is their experimental thorium reactor.

</comment><comment><USER30> Would mining too much geothermal energy hurt the earths dynamo like in the movie The Core :)?

<comment><USER31> The short answer is, we don't know. The longer answer involves a lot of evidence that we can't hurt it that much. But then again, in the 1900's farmers were forced by law to dump their waste ag chemicals into the Atlantic ocean, so wait 100 years and we'll see.

More importantly are the subtle differences to ground water temperature when wells are drilled close together in densely populated areas. This is a bit off-topic for the OP, but I went to an alt-energy talk where someone was all jazzed about geo-thermal. I asked if anyone's done any research about what the cold water pumped into the well does to the water table, or whether you could trigger fungal blooms underground and render otherwise potable water undrinkable. They, as you can guess, didn't have an answer.

Alt-energy is all exciting and holds such potential until you realize that bituminous coal was once the miracle solution to having everyone burn wood.

</comment></comment><comment><USER32> "Drilling opens door to volcano-powered surprise"

Sounds like somebody's hit the Happy Fun Stuff. Everybody watch out, FPS is about to hit the floor.

</comment><comment><USER33> I am not sure if it's a good thing that I saw this headline and immediately thought of Dwarf Fortress.

<comment><USER34> Just so long as they steer cleer of the hollow adamantite veins, we ought to be fine.

</comment></comment><comment><USER35> Why is it so much harder to drill a hole 10-20 km deep (where the mantle is predictable) than 2 km deep?

</comment><comment><USER36> What could possibly go wrong :)</comment>


The longer it has taken, the longer it will take (2015) - <AUTHOR> https://www.johndcook.com/blog/2015/12/21/power-law-projects/ <comment><USER2> I'm seeing this happen yet again on a project at work which has been super badly managed, it has been going for ~ 1 year (which is a pretty long time for what it actually is).

The deadline for project completion is 1 October. The due date is approaching quickly and 4 weeks ago, the other teams were telling me their stuff was mostly done and now it's just time for tidy up and bug fixes (which sounded dubious); However, now they're all working extremely long days and weekends just to complete.

So we went from almost being done 4 weeks ago with the finish line just days away, to clearly being under quite a lot of pressure to deliver and obviously still a lot to do.

The other thing is, people seem to be spending time on things that aren't really important and not tackling the actual work.

Maybe a lot of this comes down to stress and fatigue from their expectations not being met which ends up affecting performance.

<comment><USER3> Some usual questions that come to mind...

Are the individual metrics/incentives aligned with progress on the project? Is anyone panicking? Is anyone trying to appease someone else who's panicking, by giving an inaccurate appearance of progress/work? Is anyone stalling for time, while they try to move elsewhere?

Is there a project plan with work breakdown (and interdependencies, and preferably resource allocations) that shows what you've done, and what you still have to do? Are the incomplete tasks broken down to the resolution of 1-2 days, or to hours? Is the plan complete, or is there substantial work to do that doesn't appear in the plan? Is the completion on the plan accurate? How frequently is slippage being checked, and how does that happen? Does anyone have incentive for the plan be inaccurate at this point?

Are people working on unimportant things because they're blocked on important things by dependencies on other people, but don't want to say it?

Is everyone still putting in full effort, and committed to the project success? Or have some given up on the project, and are focused on shielding their careers?

(Even if the project effectively isn't working from a plan, has bad morale and panicking, there are conflicts of interest, etc... it might not be too late for a good manager to rally everyone around an achievable new plan, possibly including revisiting the requirements. Given that the project is in trouble, I suspect it would need _believable_ buy-in from upper management and the "customer" for this project, or people will still feel doomed, rather than focused on making it work.)

</comment></comment><comment><USER4> In Project Management class I learned about Parkinson's law which states "work expands so as to fill the time available for its completion". That about sums up my life.

</comment><comment><USER5> It's fascinating to watch first hand, management's inability to properly estimate project timelines. I think it's from a lack of really digging in and solving the thousands of tiny problems that eventually add up to solving whatever larger problem it is the general organization was trying to solve originally.

Instead, I've seen mostly attacking a problem head on which involves a really inordinate about of planning, more planning, some execution, and then more planning. Planning so much, that timelines must be altered to make room for more planning.

That's been my experience though.

I believe the desire to blow through timelines planning instead of executing, is born out of fear and what I call the sensation of movement. Fear because management doesn't want to mess up and miss something important. The sensation of movement causes management to incorrectly perceive work is being done.

At the end of all of this, nothing is done because no one has done any of the work to accomplish it, they've only been planning.

<comment><USER6> I'm beginning to doubt the reality of anything ever being done in the first place. Done software is dead software that nobody uses anymore.

It seems more fruitful to talk about gradients and equilibriums of desired changes.

<comment><USER7> I want to agree. But I use TeX. And really, it does as advertised. And set a line for where it stops.

</comment></comment></comment><comment><USER8> Note that one property described is not true of all distributions. I've used the exponential distribution to predict completion times before, and the exponential distribution has the simple property that on average completion is always the mean completion time at zero away. I have no idea if this is accurate or not, just that I've found the simplicity convenient. In contrast, for the power law distribution used in the blog post the mean completion time _from now_ increases as time passes. (In both cases, average time from _start_ to finish increases on average as time passes.)

I chose the exponential distribution because it's the maximum entropy distribution for a positive number with known mean: [https://en.wikipedia.org/wiki/Maximum_entropy_probability_di...](https://en.wikipedia.org/wiki/Maximum_entropy_probability_distribution#Positive_and_specified_mean:_the_exponential_distribution)

<comment><USER9> So in my limited understanding, the exponential distribution popular because it's very easy to work with -- you can actually analytically solve some queueing problems, for example, that wouldn't be possible with other distributions.

But power-law distributions show up over and over in things that people here care about: file size, network traffic, process lifetimes, etc etc. In these cases the exponential will drastically underestimate the fat tail.

<comment><USER8> A power law distribution is roughly as easy to work with here as exponential. The blog post contains the power law results for this case, which are fairly easily obtained through a conditional average (conditioning on t > t_0).

The important question you bring up is which is more accurate, which I don't have an answer for. But perhaps a reader has data on this. I will note that I compared exponential against some FOIA request processing data while back and thought it was okay, though I don't remember anything quantitative; see here: [https://news.ycombinator.com/item?id=21032750](https://news.ycombinator.com/item?id=21032750)

I think it's likely that something with more parameters like a log-normal distribution would be better than either, but intuitively I doubt you'd be able to get simple equations for the mean remaining time out of that.

One problem with the power law model is that the expected duration at t = 0 is 0. The exponential model does not have that problem. You could fix this for a power law by not having power law behavior for short times.

<comment><USER9> I learned about the prevalence of Pareto distributions in computer systems from Harchol-Balter's _Performance Modeling and Design of Computer Systems_ [0] (which, I will admit, I properly understood perhaps 25% of).

She reported the Pareto distribution of process times from first data collected in 1997[1].

[0] [https://www.cs.cmu.edu/~harchol/PerformanceModeling/book.htm...](https://www.cs.cmu.edu/~harchol/PerformanceModeling/book.html)

[1] [https://www.cs.cmu.edu/~harchol/Papers/TOCS.pdf](https://www.cs.cmu.edu/~harchol/Papers/TOCS.pdf)

</comment></comment></comment></comment><comment><USER10> The thing that makes this non obvious is not just that things take longer than you think, but rather as time goes on you have to adjust your expectation of completion to be longer.

For example, if there is a project that is meant to complete in a week. It has now been two weeks, so one week over budget. Most people would think that finishing the project is right around the corner, but rather the expectation should be that it will take another week or two weeks. If you get to the end of a month, same applies - the expectation should be that it will be another month, not that it is right around the corner.

<comment><USER7> Worse, is when folks take a late project and add people to it. They don't realize this is just adding to the work, so will almost certainly just increase the time.

You may get lucky and one of the new additions throws out the current plan. Cuts from the sunk costs. Probably, though, that will be its own trap. You'll think you understood your success for the next time.

<comment><USER11> That's Brook's law: "Adding manpower to a late software project makes it later,"

</comment></comment></comment><comment><USER12> Has anyone checked the underlying assumption (that the there's a power law involved)? My belief was that most long tailed distributions don't actually follow a power law.

<comment><USER8> Probably a year or more ago I compared some data on FOIA request processing times reported by US government agencies against an exponential distribution (not power law). I used the given mean and compared the predicted median against the actual median. Was acceptable as far as I was concerned, though I'd have to redo the analysis to actually get quantitative.

With a power law there's no mean or median starting at t = 0, so this sort of comparison isn't possible given the FOIA request data available. I'd be interested in seeing the data on the tails to see if those are power law distributed.

Edit: I'll do a quick quantitative check. Using data from the CIA's 2018 FOIA report (p. 18): [https://www.cia.gov/library/readingroom/foia-annual- report](https://www.cia.gov/library/readingroom/foia-annual-report)

 _Simple track:_

Mean: 32.21 days

Median: 12 days (exponential prediction: 22.33 days, 86% error)

 _Complex track:_

Mean: 368.49 days

Median: 306 days (exponential prediction: 255.42 days, 17% error)

Not the best fit but could be worse.

</comment></comment><comment><USER13> I do this to myself too but I've gotten better at it. The longer I take to do something, the more I feel it has to have to show as being worthwhile, and that feeds back poorly.

I'm pretty sure orgs also have this problem.

</comment><comment><USER14> My favorite related (not a power law distribution) example of this: life expectancy grows with age.

For some people that's really intuitive and others can use it as a more practical stepping stone on the way to understanding what happens in projects.

<comment><USER15> The life example is weaker than the project example.

In the project example, not only does the total project time increase with spent time, but the time left increases with spent time.

</comment></comment><comment><AUTHOR> OP here. I recall a similar passage in Thinking Fast and Slow by Daniel Kahneman. He was part of a committee to rewrite textbooks and everyone estimated it to be part of a normal distribution instead of a power law. He lamented how even trained psychologists were bad at estimating completion times in spite of being aware of the data.

I think this holds for most human endeavors that have intellectual property as the end result - software projects, books, doctoral thesis, etc.

Two questions - 1- I would really like to understand why? 2- I have always thought lean is the answer to the above in a startup context but really curious of hear of others.

<comment><USER9> Not just intellectual endeavours, the planning fallacy shows up everywhere.

I have a book called _Industrial Megaprojects_ by Murrow[0] which gives a lot of examples of financially disastrous multi-billion dollar projects. His conclusion? It's not really the _doing_ of the project that was wrong, it was that the projects shouldn't have been done in the first place. The estimates and preliminary investigations were underdeveloped and this typically leads to overoptimism.

Bent Flyvbjerg has also done a lot of work on megaprojects[1] and his basic conclusion is that well-estimated projects don't get built, because almost no megaproject is ever viable or cost-effective in itself. So there's a survivor bias towards "bad" projects, ones that are poorly planned in the first instance, magnifying the effect.

In terms of software, agile/lean has the advantage of limiting commitment. It's easier to terminate something that's cost very little and not gotten far than to terminate something that's several years and millions of dollars into going nowhere. The former can be dismaying and annoying. But by the time serious time and money have been spent, there's a sunk-cost fallacy and often, personal pride or status of powerful individuals is involved.

[0] [https://onlinelibrary.wiley.com/doi/book/10.1002/97811192010...](https://onlinelibrary.wiley.com/doi/book/10.1002/9781119201045)

[1] [https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2424835](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2424835)

</comment></comment><comment><USER16> I wrapped a probability distribution around this very phenomenon a few years back:

[https://statisticsblog.com/2013/05/30/uncovering-the- unrelia...](https://statisticsblog.com/2013/05/30/uncovering-the-unreliable- friend-distribution-a-case-study-in-the-limits-of-mc-methods/)

The expected duration converges to exactly double your wait time so far. I've found the "unreliable friend" distribution to be very useful in my modeling!

<comment><USER17> Your "exponential timer" page 404s, unfortunately.

</comment></comment><comment><USER18> Operating room variation: "Everything takes longer than it takes."

<comment><USER19> Hofstatder's law: It always takes longer than you think, even after accounting for Hofstatder's law.

<comment><USER20> It's fun, but it's not true. Some projects finish in time when planned with a large margin of safety.

<comment><USER9> In defense of Hofstadter's Law: it's about perception more than actual outcomes. And it doesn't predict infinite time. It can be converging to a limit, just that the limit is higher than expected.

</comment></comment></comment></comment><comment><USER21> Taleb might say this is a sibling to the Lindy Effect

[https://en.m.wikipedia.org/wiki/Lindy_effect](https://en.m.wikipedia.org/wiki/Lindy_effect)

<comment><USER22> Hey mentions the Lindy effect. I don't think I learned anything new here, except there's a scientific name for something pretty intuitive.

</comment></comment><comment><USER23> I've heard this paraphrased another way as the time it takes a company to reach its peak is its half life. The faster a company grows, the faster it will also decline.

</comment><comment><USER24> See also: getting kubernetes into production anywhere.

</comment><comment><USER25> Often there are powerful incentive effects at work that can explain the "lateness". The party making the estimate may be rewarded for making optimistic estimates (winning a bid, winning votes, staying in power). And that reward may be greater than the penalty for being "late", which can often be blamed on factors that appear unpredictable.

So the challenge for organizations who want predictability is to set up their system to balance the rewards and penalties to get the desired result.

<comment><USER26> I think that's definitely a factor. I came into a project once where that had happened. The initial estimate was a mistake and the contractor decided to up the estimate incrementally whenever they reviewed status. The client became annoyed because "every time they estimate completion, it is taking longer." (I had worked for both and came in as a third party and due to that, was able to get things back on track.) The initial situation brings me to the other major factor I see in these situations. Anything that was overlooked or comes up unexpectedly results in more work. The situations where unexpected situations result in less work are as rare as hen's teeth. This results in underestimating more often than not.

</comment></comment><comment><USER27> The root cause is usually poor resource estimates (ie. not spending enough time estimating effort before committing to timelines).

Some estimating techniques: [https://www.simplilearn.com/project-estimation- techniques-ar...](https://www.simplilearn.com/project-estimation-techniques- article)

For a team's ongoing everyday tasks, I've used parametric estimation with some success by defining team weekly capacity for productive work and then summing up the parametric estimates for all backlog tasks. You can then get a rough idea for the number of weeks to complete a bigger, more complex task.

You can even build a model to automate this estimation.

</comment><comment><USER26> I recall a study that IBM did on S/W defects decades ago. My recollection is that they concluded that the more defects had been found, the more still remained. That sounds like a corollary to "the longer it has taken, the longer it will take."

</comment><comment><USER28> Isn't this obvious?

This is why features get cut and crunch is a thing. There are only so many ways to prevent the finish line from falling off the horizon.

<comment><USER29> I think what this points out, which may be counter-intuitive, is that if there is sufficient complexity in the project that has driven it to be late, there is likely hidden complexity that will push it even further.

Complexity grows exponentially (a graph of inter-relationships) and so even cutting a feature isn't enough to curb the ballooning complexity of an over- scoped or poorly estimated project.

I could be projecting from past experience ;)

</comment></comment><comment><USER30> Definitely applies to doctoral thesis projects, especially the writing up! :D

</comment><comment><USER31> Are there exceptions? If so, what is special about them?</comment>


I'm Sick of This - <AUTHOR> http://github.com/raganwald/homoiconic/blob/master/2009-04-08/sick.md#readme

<comment><USER2> Interesting. We have sort of solved this problem in Perl. When you want to add a method to a class, you do it by applying a role. If two roles conflict, like by adding a method with the same name, you have to resolve the conflict, or the class won't compile. (The class can rename methods, but you can also call the method with a name that will always work; $instance->Role::Name::method.)

We can also apply roles at runtime. This means you can add a method to a single _instance_ of a class. So Rails could add its version of sum to its own instances of Array, and Classifier could do the same. Then there would be no conflict, except when Classifier tries to add sum to the Rails array... but at least you get a fatal error message instead of unexpectedly wrong behavior.

We can do better, though. The way around this problem is to implement (and CPAN) a role that adds a sum method to arrays, and to have both Rails and Classifier use that role. Then they can both share arrays, and when one tries to apply the sum role, the already-applied sum role will be used instead.

They both get their sugar, the sugar is isolated to the smallest area possible (a single instance), and they can both confidently share those arrays-that- can-sum.

And oh yeah, with Moose::Autobox, you can apply roles to Perl's native types (arrays, hashes, etc.), and call methods on them. So this is not "pie in the sky", it's an already-solved problem for us :)

Edit: ContextL also provides an interesting solution, "layers". Each module can define their own layer, add their own sum method to it, and activate it inside themselves:

        (defclass array ...)

        (deflayer rails-sum ...)
        (define-layered-method sum :layer rails-sum ((self array)) ...)

        (deflayer classifier-sum ...)
        (define-layered-method sum :layer classifier-sum ((self array)) ...)

        (in-package :rails)
        (defun count-users (users-array)
            (with-active-layers (rails-sum)
                (sum users-array))) ; uses rails' sum method

        (in-package :classifier)
        (defun count-results (results-array)
            (with-active-layers (classifier-sum)
                (sum results-array))) ; users classifier's sum method

        (in-package :my-app)
        (defun broken-code (array)
            (with-active-layers (rails-sum classifier-sum)
                 ;; ERROR, methods conflict
             ))

This is a pretty good approach, but not as good as agreeing on semantics in advance.

<comment><USER3> _We can also apply roles at runtime. This means you can add a method to a single instance of a class. So Rails could add its version of sum to its own instances of Array, and Classifier could do the same._

This is possible with Ruby, but culturally rare. Quite possibly because (blamestorming mode=ON) Rails simply patches whatever it wants, whenever it wants and many people follow its lead. I personally avoid the practice because it is difficult to contain in Ruby. For example, if I am handed an Array it is easy to extend that instance with its own #sum method, and when I'm done with the array I can remove my own extension.

However, what happens if, while I am still holding this extended array, I pass the array to some other method that wants to extend it with a #sum method? Same problem. Working on an instance method does reduce the scope of each modification and thus make collisions statistically less likely, so I am all for it. But at the same time, when I step back and look at the big picture, I yearn for something that solves the problem in a more fundamental way.

<comment><USER2> It is interesting... Perl has such a reputation for being unmaintainable that Perl programmers today are very careful to spend extra effort making their code as maintainable as possible.

I think a lot of practicing Ruby (and Python) programmers are under the impression that Ruby magically solved Perl's maintainability shortcomings, and so they don't invest any effort into writing maintainable code. The result is ... unmaintainable code :) It turns out that programmers write the unmaintainable code, not programming languages.

<comment><USER3> I feel that using patterns or coding conventions to make Ruby metaprogramming maintainable is isomorphic to greenspunning higher-level programming practices with if statements and gotos. It is assuredly what a good programmer does to get the job done with the tool that is provided. But a toolsmith thinks about ways to improve the tool itself.

</comment></comment></comment></comment><comment><USER3> Off topic: Thank-you HN for having a "Don't editorialize the article's headline" policy. Over on proggit this was submitted with the title _Metaprogramming has its pluses and minuses._ I feel that statement completely misses the point of the post.

[http://www.reddit.com/r/programming/comments/8ayr1/metaprogr...](http://www.reddit.com/r/programming/comments/8ayr1/metaprogramming_has_its_pluses_and_minuses/c08qdd8)

<comment><USER4> Usually, I would agree, except in this case the title gives absolutely no indication as to the topic of the article. Putting the word metaprogramming somewhere in the title would have been better.

<comment><USER3> Well, I could say "I'm sick of this metaproggraming shit." But I'm not sick of the metaprogramming, I'm sick of the conflicts. Or there's "I'm sick of the conflicts between other people's metaproggraming shit." That's closer to it, but doesn't capture my disappointment in the lack of progress in writing better tools. So there's "I'm sick of the lack of really cool metaproggraming shit" which is actually what bothers me and has the informal profanity I was going for.

So... Please feel free to fork my repo and retitle it _I'm sick of the lack of really cool metaprogramming shit_ with my blessing.

<comment><USER5> The blog post title is fine, it's the post on HN that could use a little context. I think that's the point of this thread, anyway.

</comment></comment></comment></comment><comment><USER6> It disgusts me on levels I cannot describe that this is standard operating procedure for ruby modules (gems, etc) and is the main reason I could never use it. Adding and replacing methods on builtin classes? Are these people out of their minds?! I don't understand it. I've used monkey patches once or twice and it always feels really dirty.

<comment><USER7> Ruby, despite having 4? sigils as scoping operators, pervasively screws up or simply doesn't have support for scoping.

It really should have support for having class modifications scoped to your module (and accessible manually from outside), but I couldn't find it.

If the language is such that everything "should" be a method on the broadest- possible class, people are going to monkeypatch, because it feels "wrong" otherwise. People just want to write idiomatic code.

In Objective-C this ends up not being an issue, because there's very little usage of non-Apple libraries -- plus the default way of adding methods doesn't allow replacement, and Apple libraries are well-versioned (if you build your app for >10.4, API changes in 10.5 are invisible).

<comment><USER8> _why's done some work on this: <http://github.com/why/potion/tree/master>

         Scoped mixins. Basically, you can modify
         object behavior within a scope. So changes
         to core classes can be localized.
         ++ INCOMPLETE ++

</comment></comment></comment><comment><USER9> I love how Scala solves this problem (or rather, provides the same functionality while avoiding the problem altogether):

[http://louisbotterill.blogspot.com/2009/02/scala-implicit- co...](http://louisbotterill.blogspot.com/2009/02/scala-implicit- conversions.html)

[http://www.codecommit.com/blog/scala/scala-for-java- refugees...](http://www.codecommit.com/blog/scala/scala-for-java-refugees- part-6)

Edit - more links, more detail:

[http://technically.us/code/x/the-awesomeness-of-scala-is- imp...](http://technically.us/code/x/the-awesomeness-of-scala-is-implicit)

<http://scala.sygneca.com/code/simplifying-jdbc>

</comment><comment><USER10> Alan Kay wrote a paper about a very elegant metaphor to solve this, it's called "Worlds":

        http://www.vpri.org/pdf/rn2008001_worlds.pdf

You create a "world" for your Classifier gem, which (in a trivial implementation) makes local copies of any global objects when they're modified instead of actually changing them. ActiveSupport runs in yet another "world", and knows nothing about the "local" changes to the global variables Classifier made.

<comment><USER2> I don't think this is quite what Worlds are. Worlds would not allow you to have a data structure that is used by both Rails and Classifier.

FWIW, ContextL is closer to the solution:

<http://common-lisp.net/project/closer/contextl.html>

But it's still better to just add a standard "array that does 'sum'" to the language, or for Rails and Classifier to cooperate.

<comment><USER11> Cooperation is dandy if n = 2, but for n > 2, this can get cumbersome. Unfortunately method names like 'sum' are very attractive.

A language/library designer shouldn't have to think of "all of the short or otherwise possibly overloaded nouns and verbs people might like to use, ever." Being able to say you are going to do a 'sum' which means X in this particular context is very powerful.

This notion should also be unified with version control. (As in OS X, where a process only sees the versions of libraries that it is supposed to run against.)

<comment><USER2> _A language/library designer shouldn't have to think of "all of the short or otherwise possibly overloaded nouns and verbs people might like to use, ever." Being able to say you are going to do a 'sum' which means X in this particular context is very powerful._

In this specific case, what's needed is more abstraction. Consider the approach Haskell takes:

[http://www.haskell.org/ghc/docs/latest/html/libraries/base/D...](http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data- Monoid.html)

</comment></comment></comment></comment><comment><USER12> What, you mean this?

~ $ irb

irb(main):001:0> Object.methods.size

=> 90

irb(main):002:0> require 'activesupport'

=> true

irb(main):003:0> Object.methods.size

=> 177

[ugh, no preview..]

</comment><comment><USER13> Uh... aren't we kind of burying the lede here?

Ruby has macros now.

For some limited definition of 'macros,' maybe, but screw it, I'm there.

Thank you, Mr. Braithwaite!

<comment><USER10> I've heard this in person and now here, but I can't find info on it - care to link me to these macros you speak of?

<comment><USER14> <http://github.com/raganwald/rewrite/tree/master>

</comment></comment></comment><comment><USER15> JSON.js does something similar. It puts methods in the javascript object prototype for generating and parsing json strings. WTF? Is it so inconvenient to just expose two functions to do this?

This was a problem because it broke some jquery functionality, and I ended up removing the portion of JSON.js that was updating the object prototype.

<comment><USER16> It was a big problem in the JavaScript world, until JQuery and YUI and Google came out and said "Thou shalt not modify Object.prototype" and started leading by example. But Prototype and Mootools and a bunch of smaller libraries still modify the prototypes of built-in objects, which is the main reason I won't go near those libraries. Unfortunate, since they're otherwise pretty good...

I think new versions of JSON.js (json2.js) don't modify Object.prototype anymore - Crockford has certainly learned his lesson.

</comment></comment><comment><USER17> I'm curious as to how lisp has dealt with this for 40+ years

<comment><USER18> I'm not a lisp expert, but my understanding is that CLOS uses packages for this.

In CLOS, methods (generic functions) live outside classes. So, like normal functions, their names are qualified by the packages that they are defined in. If you want the 'sum' method declared in package 'foo', you either import it into the package/namespace you're working in, or you fully qualify the name ('foo::sum', I think).

This lets you extend built-in classes within your package without getting in anyone else's way.

<comment><USER19> Great explanation. It doesn't really have to do with CLOS though. The package system works on any names whether you use classes or not (we don't).

One little detail I love because it illustrates Lisp's design style nicely. If you're using an exported (public) name, you say foo:sum. But if the name is private and you want to breach encapsulation to get at it, you say foo::sum. The language makes you state your intention, but makes it easy to do so and doesn't get in your way.

</comment></comment></comment><comment><USER20> A lot of this is solved by namespaces in Ruby (Modules.) Unfortunately, developers don't really apply them consistently. A best practice should be to put everything in it's own namespace. Been playing around with .NET MVC and C#, and this is something it manages really well.

<comment><USER10> How exactly are conflicting changes to global variables soved by namespaces?

<comment><USER21> I don't think global variables were mentioned in the article. Do you mean the global (top-level) namespace? If so, then yeah, "Don't do that" is pretty much the solution.

<comment><USER10> Sorry, maybe this isn't correct Ruby nomenclature, but I see Array simply as a global object, which can be modified, with rather obvious consequences. It's sad that I feel old enough to say this, but isn't this a problem that we solved a long time ago?

"Don't do that" is one solution, Alan Kay's idea of "worlds" is another.

</comment></comment></comment></comment><comment><USER22> I'd almost blame this problem on Ruby not having its own standard Array#sum method (or more likely it should be a method on Enumerable?). I'm guessing a lot of projects add their own, so it's a natural source of conflict.

Secondly, it seems like most conflicts like this occur between Rails and some other library. Rails, via ActiveSupport, adds a lot of extensions to core Ruby. I kind of wish it didn't. Framework or general purpose library developers should recognize that their library will likely be combined with many others and avoid conflicts by sticking to what's available in the standard, namespacing their code, etc.

I like Ruby, but I'll readily admit it's not a perfect language. I'm sure someday a better Ruby-like language will come along. Hopefully, it'll be a language with better support for avoiding these kind of conflicts without removing support for open classes. I'm sure it's an interesting technical challenge.

<comment><USER3> While I grouse about Rails, here is the challenge I posed last July at Rubyfringe: Forget about Rails providing all these extensions for Rails programmers to use. How does Rails perform this kind of metaprogramming for its own use? How can its own internal libraries use Array#sum while leaving Array unmodified for Rails programmers?

<comment><USER22> In my own library, I use inject instead of adding Array#sum. But, I know that's sidestepping the issue, not solving it.

Honestly, I'm not sure _how_ Rails uses #sum. I'm not sure whether they _really_ need it or not. I suspect not.

I'm not a big fan of a lot of non-standard additions to Ruby. For example, all the #try, or #returning, or even your #andand. I don't consider any of those to have enough intrinsic value to be worth the risk of collisions with someone else's subtly different implementation.

<comment><USER3> _I'm not a big fan of a lot of non-standard additions to Ruby. For example, all the #try, or #returning, or even your #andand. I don't consider any of those to have enough intrinsic value to be worth the risk of collisions with someone else's subtly different implementation._

#andand is soooooooo "raganwald." The Homoiconic Way is to use rewrite: #try, #returning, and #andand are all removed from your code and never conflict with other people's implementations ;-)

</comment></comment></comment></comment><comment><USER23> What is naked recursion?

<comment><USER3> Functions/methods that call themselves, as opposed to having a higher-level function that takes a function as an argument and does something recursive with it.

[http://github.com/raganwald/homoiconic/blob/master/2008-11-2...](http://github.com/raganwald/homoiconic/blob/master/2008-11-23/recursive_combinators.md#readme)

<comment><USER23> Ah, so naked recursion is recursion.

EDIT: I was going to criticize your idea that there is anything lacking in "naked recursion". It's a really powerful technique and in fact I just wrote a recursive function for production code an hour ago. Comment continued here: <http://news.ycombinator.com/item?id=555714></comment></comment></comment>


Happy Leap Day (Unless You're in Debt) - <AUTHOR> http://www.portfolio.com/views/blogs/daily-brief/2008/02/29/happy-leap-day-unless-youre-in-debt

<comment> daniel-cussen This is the worst-written Condé Nast article I've seen.

</comment><comment><USER2> "To correct this, Caesar decreed that 45 B.C. would be 445 days long."

Caesar got whacked in the Senate the very next year. Things that make you go hmmmm... :)</comment>


Spam trap - <AUTHOR> http://dfranke.us/spamtrap

<comment><USER2> Unfortunately, according to that malware presentation that was linked to here the other day, getting confirmed email addresses is still cheap. :/

</comment><comment><USER3> Source code: <http://dfranke.us/spamtrap.rb.txt>

</comment><comment><USER3> Wow. I definitely did not expect to see this link here.

<comment><AUTHOR> :) I clicked through to your homepage and thought this was really funny.

<comment><USER3> I really need to get around to updating that site. It still says I'm a student.</comment></comment></comment>


Opus codec available now in Asterisk - <AUTHOR> http://blogs.digium.com/2016/09/30/opus-in-asterisk/ <comment><USER2> Or you could just use FreeSWITCH, We've had OPUS for a long time, full WebRTC stack, and full Video MCU / Transcoding features. [http://www.freeswitch.org](http://www.freeswitch.org)

I understand Digiums concerns, but I feel they aren't warranted. There are open source equivelent patches out there to accomplish OPUS in Asterisk without the phone home element.

/b

</comment><comment><USER3> Does anyone have more detail on the licensing issues with Opus that caused the binary module/daily "phone home to Digium" license check?

<comment><USER4> I think they are concerned that there may _still_ be some unexplored patents which apply to Opus. If they don't track the numbers, then they may need to pay the absolute maximum license fee to a (future, unknown) patent holder because they can't bound the number of licensees.

That is, of course, assuming there are still IP issues. I'm not sure what made them concerned about that, if anything tangible.

Notably, the Opus license is voided when you enter Opus-related patent litigation with an Opus user. I think many(most?) companies which hold patents relevant to Opus also license Opus for their products; so they would be trading patent litigation for copyright litigation.

From the Opus licensing page¹:

When it comes to patents, it is difficult to say much without making lawyers nervous. However, we can say something quite direct: external counsel Dergosits & Noah has advised us that Opus can be implemented without the need to license the patents disclosed by Qualcomm, Huawei, France Telecom, or Ericsson. We can also say that Mozilla is confident enough in Opus to ship it to hundreds of millions of Firefox users. Similarly, Cisco and Google are also supporting Opus in some products. More companies are expected to do the same soon.

Mozilla invested significant legal resources into avoiding known patent thickets when designing Opus. Whenever possible, we used processes and methods that have been long known in the field and which are considered patent-free. In addition, we filed numerous patent applications on the new things we invented to help defend the Opus community. As a result, Opus is available on a royalty-free basis and can be deployed by anyone, including other open- source projects. Everyone knows this is an incredibly challenging legal environment to operate in, but we think we've succeeded.

1\. [http://www.opus-codec.org/license/](http://www.opus-codec.org/license/)

<comment><USER5> I wonder if they got shook down by a patent troll?

<comment><USER5> If so, Oracle did too:

> Transcoding the Opus codec requires a special license as it is subject to a > royalty agreement.

[https://docs.oracle.com/cd/E61547_01/doc/esbc_ecz730_mainten...](https://docs.oracle.com/cd/E61547_01/doc/esbc_ecz730_maintenancerelease.pdf)

<comment><USER4> I think they are referring to the non-litigation clause in the Opus license. Oracle probably charges extra for taking on the burden of potentially not litigating because of that license.

</comment></comment></comment></comment></comment><comment><USER6> Also see this for Asterix, Opos, VP8 and patents: [http://lists.digium.com/pipermail/asterisk- dev/2013-May/0604...](http://lists.digium.com/pipermail/asterisk- dev/2013-May/060419.html)

</comment><comment><USER7> Asterisk project home: [http://www.asterisk.org/](http://www.asterisk.org/)

</comment><comment><USER8> Does any modern Voip app use SIP?

<comment><USER9> Depends on what you mean by 'modern'. You may as well ask "Does any modern messaging app use XMPP?" Consumer facing open protocols are going extinct in favor of walled gardens and closed markets.

</comment></comment><comment><USER10> What IPR issues Opus has?

<comment><AUTHOR> Digium seems to think it has some, so they have been dragging their feet for ~3 years now. So this is a start.</comment></comment>


CoffeeStrap is in open beta - <AUTHOR> http://blog.coffeestrap.com/2013/04/19/and-coffeestraps-are-happening/

<comment><USER2> Gender selection is particularly strange. Male is depicted by a ♀ Venus symbol?! In fact, I wasn't sure which gender is where until I've used Firebug.

<comment><AUTHOR> It looks like, at this point [<https://news.ycombinator.com/item?id=5237265>], we really need to change it! :-)

<comment><USER3> <http://en.wikipedia.org/wiki/Gender_symbol>

</comment></comment></comment><comment><USER4> I imagine you'll get an overwhelming number of people who want to learn other languages but can only offer English themselves. How's the rate been so far?

</comment><comment><USER5> interesting idea! i think it would be great as a mobile app, so it could send you a notification if a language exchange partner is nearby.

I was also expecting a coffeescript & bootstrap mashup and was pleasantly surprised to find a language website!

</comment><comment><USER6> Nice job guys! Good luck!

<comment><AUTHOR> Thank you Simone! :-)

</comment></comment><comment><USER7> Tell me I'm not the only person who was expecting some kind of CoffeeScript and Bootstrap mashup.

<comment><USER8> Actually, I was very relieved it was not.

<comment><USER9> me too lol !</comment></comment></comment>


Ask HN: Is USA testing enough people for Covid-19? - <AUTHOR> <comment><USER2> Yes.

There's between 50k and 500k people in the US with covid19. At this stage it's fairly immaterial to give people tests that take 2 days to run.

If you have a temperature or a new cough, just assume you have it, and self isolate, ideally asking people to report they are self isolating too.

They should be doing mass temperature scans to find people with high temperatures at large events, subway stations, shopping malls, etc. Far easier to test en-mass, and gives an indication.</comment>


The Road to Mediocrity is Paved with Best Practices. - <AUTHOR> http://www.adambreckler.com/the-road-to-mediocrity-is-paved-with-best-practices

<comment><USER2> He ignores a lot of examples where best practices have simply become common knowledge, and you'd never consider doing it any other way. For example, structured programming - most languages don't even _provide_ a way to jump into the middle of a code block now. Avoiding self-modifying code, unless you live in Ruby-land. Lexical scoping, which is widely considered the only sane default among language designers today, though we're still waiting for mainstream languages to catch up. Multi-character variable names that don't have to start with one particular letter (Fortran, I'm looking at you). Automatic documentation generators - thank you JavaDoc. Garbage collection. Having classes manage their own memory in languages that don't provide garbage collection.

Today's "best practice" _may_ be tomorrow's fad - or it may be tomorrow's common knowledge. The differentiating factor is usually the ratio of actual experience to wild-eyed exuberance that its proponents have. So I'm betting that Rails is just a fad, but several of the XP practices like unit testing and standup meetings will have lasting impact.

</comment><comment><USER3> There are plenty of situations where mediocrity is a fine goal. For many projects, it's a step up. Perfect is the enemy of good.

<comment><USER4> but good is the enemy of great.

[http://www.amazon.com/Good-Great-Companies-Leap- Others/dp/00...](http://www.amazon.com/Good-Great-Companies-Leap- Others/dp/0066620996)

<comment><USER5> Tell that to Circuit City:

[http://www.bloggingstocks.com/2009/02/23/from-good-to- great-...](http://www.bloggingstocks.com/2009/02/23/from-good-to-great-to- bankruptcy-jim-collins-book-revisited/)

</comment></comment></comment><comment><USER6> I found the article meaningless. He says best practices are what everyone is doing, therefore the embodiment of mediocrity.

I find "best practices" to be a useful checklist, especially in an area new to me. If someone says it's a best practice, I take a look. Ultimately I may decide their advice is of a little value.

<comment><USER7> The fourth commenter at the blog makes an excellent point: people call it 'best practices', but they are actually 'common practices'. The reason something is a common practice, is because it has been shown to work or, lacking measurements to proove that something works, because it makes sense and 'just works'.

Moreover, it's just a non-sequitur to conclude from 'mediocre company X does Y' that 'doing Y makes a company mediocre'. What makes a company mediocre is in the things they cannot single out in clear statements of the form 'we should change practice Z, as it is not good.

<comment><USER8> Also it could be called "best goals" instead. I've seen a lot of companies that lie about what they really do, specially those certified with ISO and family.

</comment></comment></comment><comment><USER9> Nice and funny. But obviously, 'best' here refers to the best among all other approaches/practices, and not best among all those companies following the same 'best' practice.

</comment><comment><USER10> A big part of the problem with "best practices" is that the term becomes carte blanche to justify a particular decision without understanding the reasoning behind it. It's sad that it's become a kind of seemingly-authoritative buzzword.

</comment><comment><USER11> This is a short post mostly devoid of content, where the author argues that "Best Practices" are an oxymoron if everyone is doing them.

This is based on an assumption that at given point in time there isn't an ideal solution (or an approximation which is nearly indistinguishable) for a given problem.

I would disagree and say that while "best practices" can be a buzz word for industry consensus, there are plenty of "best practices" which are genuine best solutions.

This can be for a number of reasons, such as learning inertia on the part of users. You might be able to invent a "better" user interface convention but if it's unfamiliar or confusing to the majority of users used to an "inferior" convention it's not necessarily a better practice to use the newer convention.

</comment><comment><USER12> Best out of the set of possible practices, not out of the set of practitioners.

State of the art sounds impressive, but it merely means the best we have at the moment. Inventive people constantly improve it.

"Crossing the Chasm" talks about how most people in a given industry prefer to do what everyone else is doing. Progress comes from the technology "enthusiasts" (who simply love cool new stuff) and "visionaries" (who are excited by new application of the technology to give them a x10 advantage).

There's also the distinction between competitive advantage and hygiene factors. For the latter, it's cheaper and more reliable to just follow the crowd than to experiment with risky new ways - save that for improving your competitive advantage.

</comment><comment><USER13> Don't look at what is said but who is saying. I'll always take an advice from PG, DHH or Stanislaw Lem but never from Anonymous.

</comment><comment><USER5> Dismissing "best practices" out of hand, is sort of like slavishly following "best practices."

</comment><comment><USER14> These claims are logically looped, and for that reason are inconsistent. What he claims, is actually "Best practice is avoid best practices". And he justifies it with claims that following these practices causes mediocrity, because everybody begin doing same thing. Well, sometimes, the best thing you may want is mediocrity in something absolutely irrelevant and of secondary importance. For sake of freeing your time for really important things.</comment>