What to do about GNU? - <AUTHOR> http://smalltalk.gnu.org/blog/bonzinip/what-do-about-gnu

<comment><USER2> I quite like the idea to separate the GNU and FSF labels and approaches to development. The GNU projects working together in more integrated fashion is closer to the original idea of an integrated "GNU system". But GNU has also accumulated a lot of more standalone projects, so instead of axing them or adding unnecessary dependencies by trying to graft them together, I like the idea of transitioning them to be "FSF" projects, each managed by their own teams, with the FSF serving in a support role to provide resources, publicity, and possibly funds.

<comment><USER3> I don't necessarily think it's about dependencies, but more about the fact that it's impractical to have 1 guy per project considering all the small software now under their umbrella.

Regrouping things together and saying, for example, this one guy is the head of text processing means that he becomes the go-to guy for all the 1-logical- unit software that goes into that group. While traffic per project might be small, over all the projects it would be enough to warrant assigning a guy to it.

</comment></comment><comment><USER4> I really think that GNU should cut off GNOME, not make it part of a pruned core group of GNU projects. Under his proposal (focus on development/build/POSIX/GNOME) GNOME _really_ seems like the odd one out.

<comment><USER5> Well, there are different parts to Gnome.

There's Gnome the window manager library and there's Gnome the "Graphic Environment" the shell and related applications (Gnome-shell, Nautilus, etc).

Gnome the window management library would make a great thing to put within a tighter GNU. It is the basis of Xfce and Ubuntu Unity as well as the Gnome Shell. Taking the underlying library out of the current tug-of-war over interfaces between these environments would be nice. And I realize there's also the Gnome 2.0/Gnome 3.0 issue in libraries but I'd say a more neutral umbrella would still be useful.

<comment><USER6> Just one small nit to pick, Xfce uses the project's own window manager, xfwm. Xfce and GNOME have their glib/GTK+ core in common.

<comment><USER7> Unity also uses compiz instead of Mutter. He was talking about gtk and the support libraries, where you split off Gnome Shell the desktop and leave gtk the toolkit.

</comment></comment></comment></comment><comment><USER8> Context: <https://news.ycombinator.com/item?id=4956899>

</comment><comment><USER9> Do fsf make any impact on everyday computer users?

Take mobiles and tablets, all I see is walled gardens created by large businesses. The longer you use a device the more you invest into it and the more locked in you become.

I would have thought this would be an area which fsf could make a difference in. Instead of a solution I get the impression that fsf would just support a gnu mobile os which would do nothing but create another silo for locked in content and purchases.

<comment><USER7> Ubuntu Phone is going to be running on top of glibc and the regular GNU coreutils.

You can also stick Plasma Active from KDE on top of most phone hardware, given driver support, and get another mobile OS running on top of GNU.

The FSF isn't supposed to be an OS company. They are a foundation for free software. They wanted to make a POSIX compliant free *nix, and did. Their stuff also happens to work with Linux by design. You can take it or leave it, but they aren't a commercial entity to push consumer adoption.

</comment></comment><comment><USER10> _> There are too many projects in GNU. Micromanagement is impossible at this scale, therefore nobody really tracks them. This has many problems: the signal-to-noise ratio in the list of GNU software projects is low, the different projects are not as coherent as they could be, there is little or no mentoring for new GNU maintainers, and so on._

Somebody should curate GNU and come out with the subset that's signal minus the noise. One could argue that this is what distros are for, but there really needs to be something upstream of the distros. Likewise, there's Debian, which is great, but perhaps there needs to be something else that does a different level of curation.

<comment><USER7> In the modern world most of those projects hosted by GNU should have ended up on Sourceforge / Github / etc anyway. A GNU hosted project should be a blessed core component of the GNU OS, not a peripheral like a chess program.

<comment><USER11> Github is maybe lacking for a semi-major free software project looking to create a web presence. It does have source hosting, projects pages, and a bug- tracking system, but it doesn't let you upload builds for downloading any more (without a bit of hackery). There are probably other features that would be useful too, like having some sort of forum for users. Github is also kind of cluttered with small projects and forks. It maybe has kind of a low signal-to- noise ratio.

And Sourceforge is . . . Sourceforge.

It might be useful for there to be a website that would fill in the gaps. It would provide semi-major free software projects with the tools and hosting to create real web presences. It wouldn't even necessarily have to provide source hosting.

(Edited twice.)

<comment><USER7> Launchpad?

</comment></comment></comment></comment><comment><USER12> I think GNU needs to re-launch. Not re-invent itself, or re-do things. Just re-launch.

</comment><comment><USER13> Step one should be to rebrand itself with a less obtuse word.

<comment><USER11> You know, that might actually be a good idea. Sounding more hip (without sounding stupid) could actually help. gnu.org could also use some serious redesign. Brand is important.

Also, fsf.org doesn't immediately scream at you what the FSF is and why you should care. They might want to work on that.

<comment><USER14> I agree on the fsf.org observation. If you look at the EFF as a comparison, their website has the tagline "Defending your rights in a digital world," which makes their mission clear.

</comment></comment></comment><comment><USER15> Isn't gnome in serious trouble right now, losing developers, users and distributions? Even leaving aside my personal views on the software, "the GNOME project is clearly a successful community, and we all should learn from it" is at odds with the impression I've got from e.g. [http://blogs.gnome.org/otte/2012/07/27/staring-into-the- abys...](http://blogs.gnome.org/otte/2012/07/27/staring-into-the-abyss/)

</comment><comment><USER16> The first thing I'd do is rename it. I'm not kidding. Inside jokes are fine when they're inside jokes, but when they're the actual face of the project, all they do is alienate outsiders.</comment>


Before Netscape: Web browsers of the early 1990s (2011) - <AUTHOR> https://arstechnica.com/information-technology/2019/05/before-netscape-forgotten-web-browsers-of-the-early-1990s/ <comment><USER2> Looking at the second screenshot in this article (the one titled "An early CERN Web browser, circa 1990"), I feel this is what I'd like the modern web to be: crisp, clean, high density information, using colors only where it is relevant.

Modern web pages have become a seizure-inducing cacophony of colors, fonts, animations, ads, videos and intrusive modals ("please sign up", "subscribe to our newsletter", "do you accept cookies?", "please disable ad-block", "people in <your town> are excited about this new weight loss product!") etc.

<comment><USER3> I'm going to get flamed for this but, if all you're interested in is the text, you could do worse than Lynx. I mean, it's not pretty, but it does get to the point. For sites that absolutely require JavaScript to load content you're screwed, but it does a surprisingly decent job on many others. Can be helpful if you need to avoid becoming distracted.

<comment><USER4> I actually used text based browsers as my main thing for a few weeks, when I had really bad internet. Ran it thru ssh on a VPS, much faster that way. I found the w3m browser gave the best formatting and mouse support.

<comment><USER5> When I have a slow internet connection I use the Dillo browser with CSS and image loading disabled. Dillo is also really snappy even on an old computer.

[https://www.dillo.org/](https://www.dillo.org/)

</comment></comment></comment></comment><comment><USER6> I remember the first time I saw Mosaic - a friend of mine was reading a digital graphic novel. I was absolutely gobsmacked at how incredible that was: not only did someone create something in a country far from mine, I was able to look at it in my home—perhaps minutes after its creation. So quickly, we become accustomed to the amazing.

<comment><USER7> I remember first seeing Mosaic when I started taking classes at Brown University. The university CS department people had very wisely set it up so that any CS students could not only very easily create their own Web pages from files in their home directory, but also easily do CGI scripts that were publicly accessible. The easy CGI wasn't so great for security, but was fabulous for lowering the barrier to experimenting.

Using that CGI, I wrote several services, mostly in Perl, and one in C. (The C one was so that I could use the GD library to draw some GIF parts of a hypermedia image of the main workstation lab, with faces of people there, which machines were free, etc., since it wasn't doable as well in HTML at the time.)

After seeing it at the university, I also went and and installed Mosaic and a the NCSA or Apache HTTP server at my workplace (where I was in an R&D group), and wrote some demonstrations of it (e.g., doing our engineering documents in it instead of Interleaf/FrameMaker, clickable hypermedia floorplan).

I'd actually already been on the Internet as a kid (gateways, email, Usenet, ftp, etc.), and had already worked with a few offline hypertext systems before I saw the Web (as well as being aware of earlier grand visions), but the Web was obviously going to let us do Internet things we couldn't before, and also accelerate bringing the goodness of the Internet to everyone. (Well, we dropped the ball on some of the goodness, but it still happens, just not as much nor nearly as universally as we'd hoped, and we can still improve that.)

</comment></comment><comment><USER8> I first used SPRY Mosaic as provided by CompuServe (my first ISP). I had written an article for a late 1995 special edition of Doctor Dobbs Journal which still has my screen image captures of the SPRY Mosaic browser:

[http://www.drdobbs.com/web-development/clientserver- developm...](http://www.drdobbs.com/web-development/clientserver-development- and-the-world-w/184409740)

<comment><USER9> [https://en.wikipedia.org/wiki/Spry_Vegetable_Shortening](https://en.wikipedia.org/wiki/Spry_Vegetable_Shortening)

I mentioned this in a different comment, but I have a jar from back then with that name. Early "if they'd only done research" brand accident. Or maybe they meant to?

</comment></comment><comment><USER10> How about the forget tradition of Netscape developers dunking their heads in toilets?

[http://totic.org/nscp/swirl/swirl.html](http://totic.org/nscp/swirl/swirl.html)

<comment><USER11> To be fair, I'd stick my head in a toilet for $100,000. $200? Not so much.

</comment></comment><comment><USER12> Anyone here ever used the web-browser that comes with GeoWorks/New Deal? Pretty amazing software. In the late 90's I was studying in Poland. In the computer lab of my dorm there were two Windows PCs and half a dozen text terminals. People were always waiting to use the more modern machines. The terminals were only good for e-mail (via telnet). They were XT-class machines with Hercules graphics. One day I decided to put a copy of GeoWorks on one of them. From then on I could always surf the web whenever I want. People were quite amazed to see a full GUI on a 12" monochrome screen.

</comment><comment><USER13> I recently built xmosaic on macOS with very little extra installed/modified. It was quite fun.

[https://twitter.com/radiofreejohn/status/1132137894158618624](https://twitter.com/radiofreejohn/status/1132137894158618624)

</comment><comment><USER14> Lynx is still in use these days, and has been around since 1993.

[1] [https://en.wikipedia.org/wiki/Lynx_(web_browser)](https://en.wikipedia.org/wiki/Lynx_\(web_browser\))

</comment><comment><USER15> Back then I used lynx on the text terminals at university and shortly after upgraded my PC at home (running Linux) from 4 MB to 8 MB of RAM (which did cost about an arm and a leg) so that I could run Mosaic with its statically linked Motif libs on it... When I think back the thing that amazes me most is the fact that I ran a Unix system along with X11 and a Motif application in all of 8 MB of RAM.

I still use lynx now and then even today. Haven't seen any Motif app for a long while, though.

</comment><comment><USER16> somehow, seeing Mosaic in 1993 or so was not a big deal.. Gopher was in use and the various FTP clients to transfer files, and Mosaic seemed like a small step from those, just unified into a page. Composable HTML was not a thing yet. The GUI was so primitive compared to daily desktop software, that it wasnt very compelling. Public access to a unified Internet was also not a thing yet, networks were restricted and siloed by governance and protocols. Usenet news already had some binaries if you really wanted to distribute or look for something, but the content was limited. basically, not a fan on first looks

</comment><comment><USER17> There were so many more of these, many will remember HotJava but what about Oracle's entry: [https://en.wikipedia.org/wiki/Oracle_PowerBrowser](https://en.wikipedia.org/wiki/Oracle_PowerBrowser)

<comment><USER18> And you can (barely) still download and run the Amaya browser from the W3C today (that was from the mid 90s)

</comment></comment><comment><USER19> If anyone is wondering what was Netscape's first big feature differentiator was, it was inline JPEGs. Mosaic could just display GIFs inline. JPEGs would require an external handler, typically LView on Windows, or xv on Linux.

<comment><USER20> Netscape's huge differentiator was running on 16-bit Windows. All the other browsers needed either NT or a Unix workstation. This was prior to Windows95 so regular folks were still running Windows 3.1.

<comment><USER21> I remember running Mosaic on Windows 3.11 with WinSock in the 93/94 time frame. Maybe this was a 3.11 thing though... I never tried it with standard 3.1.

</comment></comment></comment><comment><USER22> I think in those days all the well-known graphical browsers (Mosaic, Netscape) were proprietary, although free for personal use.

I think I used a browser in Emacs for quite a while. There was also the Chimera browser mentioned elsewhere.

<comment><USER19> I believe NCSA Mosaic was BSD.

Andreesen was _hated_ at UIUC in the mid 90s for essentially taking the NCSA work and and then getting rich off of it. Then to add insult to injury he called his company Mosaic Communications. The university went after him for the trademark infringement (or whatever), but I don't think there was anything legally wrong with him taking the code. Not only was Netscape, not the only company spun off of the Mosaic work, but pretty much every browser had some NCSA code in it for years and years.

<comment><USER22> I don't remember that, and can't find a source for it. The source code was released, but I don't think it ever had a license that allowed commercial use, and was it licensed commercially to many others.

Edit: including to Spyglass, for their browser, which was later licensed by Microsoft for Explorer.

<comment><USER23> I think Netscape was a clean rewrite of the source code of NCSA Mosaic, but with the benefit of past experience and being able to look at the code. Not illegal, but still somewhat dodgy, and understandable that people who worked on the NCSA version might get mad. I remember hearing that Andreesen was none too popular at UIUC after founding Netscape, and the lawsuit over the trademark; there's a source for that here:

[https://www.jwz.org/doc/about-jwz.html](https://www.jwz.org/doc/about- jwz.html)

</comment></comment></comment></comment><comment><USER24> Did anyone else ever use Arachne?

<comment><USER25> I remember trying it in the mid 90s and then not using it much. I remember it being quite slow. The lack of even rudimentary multi-tasking caused it to hang easily. I could see where it might be useful in a lab with 8086 and 286 machines. But I think even at the time, this software had what seemed like a high cost, like $99. If there had ever been a DOS-only port of Lynx (without requiring Win32), that would have been a better option instead.

Since the 486 I used could run Windows 3.1, Trumpet Winsock and Netscape and later Opera were good enough for the times. It was claimed that Opera was written in assembler (and it did feel like it was faster than other browsers) and it introduced MDI (tabbed) browsing.

<comment><USER26> Arachne's still (freely) available though it hasn't been updated since 2013 (and 2010 for the last Linux (curses) version). There is now a version for 386 and better which should be a bit quicker: [http://www.glennmcc.org/](http://www.glennmcc.org/)

There's also a DOS version of Lynx (DOSLynx) that's been around for some time: [http://www.fdisk.com/doslynx/doslynx.htm](http://www.fdisk.com/doslynx/doslynx.htm)

</comment></comment></comment><comment><USER27> I used MacWeb [1] on my PowerBook 145b in the early 90s. Lovely solid machine, 25 MHz Motorola CPU, 4 MB RAM, and a massive 80 MB hard disk. And yes, it was possible to surf the web with that, with information dense content, mostly text (the "T" in HTML and HTTP!).

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

</comment><comment><USER28> Let's all remember that the first client-side scripting language was Tcl (inside ViolaWWW).

[http://www.viola.org/viola/vw/brief.html](http://www.viola.org/viola/vw/brief.html)

> (If this were rendering on ViolaWWW, the button could actually be live on > this document page!)

Loss of functionality well before JavaScript. ;)

</comment><comment><USER29> _rolls out 300bps acoustic coupler to slowly watch lynx update on a remote system...._

Ok, so I really used 2400bps and later 14k4 all the way up to 56k (speed!) for IP based traffic. It didn't take long using 300bps to demonstrate the wisdom of upgrading.

</comment><comment><USER30> Interesting to see Viola mentioned so prominantly here, and to see its impact on Andreesen, Mosaic, and Netscape. Whilst I'd never used it myself, I ran across it a year or so back when looking at how the n=modrn browser mechanics were estabished: navigation, history, bookmarks, scropting. Viola extended many of these concepts, and explored ground that's since been lost; Applets, scripting (Tcl), stylesheets, frames, forms, equations editor, columnar layouts, sidebar as integral element, and more.

Its descriptive pages are well worth revisiting.

[http://www.viola.org](http://www.viola.org)

</comment><comment><USER31> I remember running WebExplorer on OS/2 in the mid 90s. Was pretty good!

</comment><comment><USER32> There was also tkwww in 1992. [https://en.wikipedia.org/wiki/TkWWW](https://en.wikipedia.org/wiki/TkWWW)

</comment><comment><USER33> I used the Atari browser CAB [1]. It had auto reload capabilities, you could have the browser open in a window in the background and it would reload the page while I was editing the html in the foreground window. Very handy for developing. Not sure about timeframe though, 98?

[1] [https://atari.clauss-net.de/cab.html](https://atari.clauss- net.de/cab.html)

</comment><comment><USER34> Cello was the first graphical browser I used after Lynx for a short while. Though I appreciated the graphics in Cello, I did initially find the Web (graphics or just text) to be messy compared to the much more orderly Gopher. Once I started dabbling with HTML and made a crude site for my employer, I quickly went from office clerk to webmaster. At that point Gopher was pretty much forgotten.

<comment><USER35> I also used Cello, on an early Windows NT beta. It was multi threaded and async, much nicer and faster compared to Mosaic. Problem was it was also very buggy and crashed all the time. After some time I returned to Mosaic that would run without crashing.

</comment></comment><comment> 1-6 I've been playing with browsh (brow.sh) on terminal. I've fallen in love with 'the modern text-based browser'

</comment><comment><USER36> Mosaic, gopher and text based one. Use the text to play go (WeiQi) and lost as refreshed under 19.2k modem is too slow.

</comment><comment><USER37> Lynx was widely used at my university when I started there in 1993. I remember vaguely not liking Mosaic and other early inline graphic browsers, not because they weren't revolutionary, but because they were too slow on our relatively slow networks and phone connections.

</comment><comment><USER38> This maybe a little off topic but... wait what? CERN had their own OS? What was its name?

<comment><USER39> NeXTStep, Steve Jobs made a company NeXT after being kicked out from Apple. This OS became the foundation of the Mac OSX. [1]

Aside from NeXTStep, it was even before Linux was born. There were many historic BSD derivatives in that moment.

[1]: [https://stackoverflow.com/questions/473758/what-does-the- ns-...](https://stackoverflow.com/questions/473758/what-does-the-ns-prefix- mean)

<comment><USER11> _> So in his spare time, [Berners-Lee] wrote up some software to address this shortfall: a little program he named Enquire. It allowed users to create "nodes"—information-packed index card-style pages that linked to other pages. Unfortunately, the PASCAL application ran on CERN's proprietary operating system. "The few people who saw it thought it was a nice idea, but no one used it. Eventually, the disk was lost, and with it, the original Enquire."_

Sounds like this was pre-NeXT, or at least on another in-house OS. It would be interesting to see what it was all about.

<comment><USER40> The Wikipedia article on ENQUIRE says it ran under SINTRAN III (the standard OS for many Norsk Data mainframes in the 1970s-1980s). So not a CERN-specific OS, just one not known to many people outside European users of mainframes at the time.

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

</comment></comment></comment></comment><comment><USER41> Having been involved in the BBS scene from the very early 80s and being involved with all things computer related since then, I have experience with all the browsers listed, and could name a few others.

</comment><comment><USER42> I clearly remember using the web browser bundled with early NYC ISP The Pipeline in like 94. Netscape eventually came and blew it away, but it wasn't bad for what (I think) was the work of basically one guy.

</comment><comment><USER9> I had Mosaic as well as Spry. I always thought it funny that my wife had an old antique jar in the kitchen (still have it) for flour that was for a brand of lard called "Spry"

</comment><comment><USER43> My first graphical web browser was Slipknot. From what I remember you would telnet into a shell account and it essentially acted as a graphical front end for Lynx.

<comment><USER43> (Realizing I miswrote that yesterday — obviously the point of Slipknot was that you would dial up to your shell account, because you didn't have telnet access on your machine.)

</comment></comment><comment><USER44> Install mosaic to really get into the mood.

[https://snapcraft.io/mosaic](https://snapcraft.io/mosaic)

</comment><comment><USER45> Ahh, I am young. I started with Netscape 2. But I do remember some older machines with Mosaic... by 1996 Mosaic was already useless.

</comment><comment><USER46> I quite liked Arena and Chimera (the Xaw one, not the predecessor of Camino) in my early Linux days. Although Netscape 2/3 quickly took over.

<comment><USER47> That Chimera was pretty nice, all right:

[http://freshmeat.sourceforge.net/projects/chimera- www](http://freshmeat.sourceforge.net/projects/chimera-www)

In a similar category, but using Gtk, was Ralph Levien's gzilla [https://www.levien.com/gzilla/](https://www.levien.com/gzilla/)

</comment></comment><comment><USER48> sadly, missing one of my favorites: NCD's mariner (yeah, the x11 terminal company).

</comment><comment><USER49> Just imagine how many little bits of diarrhea and pubes they ingested</comment>


Forecast, don't guesstimate your software projects - <AUTHOR> https://www.reaktor.com/blog/forecasting-method/ <comment><USER3> TFA uses a lot of words to say very little.

I don't care if your estimate is drawn from the hip or projected using a state of the art Monte Carlo or machine learning model. It's still an estimate. Still, any number of things that weren't in your model could shift the deadline: people getting sick for a long time, people quitting, people getting promoted out of their critical role, organizational dependencies not delivering on time (other dev teams, legal etc), all of these things have happened to me, and when they do, they can throw off your project for _months_.

No model can take these things into account, and if it does, it will yield an estimate like "three weeks up to a year" which is useless, and I didn't need your SOTA model to get that answer. Unless you're really only doing cookie cutter stuff, the best form of estimate I've seen used is continuous estimation + being willing to cut features to make it to deadlines with something usable, even if incomplete (build a bike, not half a car). This isn't always possible, but when it is, it saves a lot of headache and makes everything run smoother. But it starts with accepting the fact that you don't know everything from the start.

<comment><USER4> The article is about forecasting not estimation. That's the point. Don't estimate. Measure.

It usually goes without saying that most forecasts do not include provisions for black swan events. It's generally assumed that going bankrupt or other project externalities will have an impact on the delivery.

<comment><USER5> Author of the article here.

I agree with this response. We are normally not asked to predict for situations where something big changes in the team. But I of course acknowledge that these things do happen. When you have a stable team, the numbers that this method yields are also very stable.

<comment><USER6> I agree with the top comment. The "method" is basically:

 _Instead you can look at the team's historical data and apply statistical techniques._

Except that is already what every experienced developer is already doing, albeit in an intuitive way.

Intuition is superior here, because statistical models don't work for creative domains, and anyone who says so has something to sell.

<comment><USER7> My experience is that most project managers take a non-probabilistic approach.

Say you have your usual list of breakdown tasks and assign a time/budget estimate for each in terms of "low", "most likely", and "high". The intuitive answer is to sum up the "most likely" for your total estimate. However, this ignores the probability that a delay in one task affects others.

Instead, if you take into account the covariance relationship between tasks (using historic or simulated data) you often find that "most likely" summation has a quite low probability of being met. For the org that applied this, there was a less than 20% chance we'd meet or best that intuitive estimate. No wonder we were chronically over budget and over schedule!

<comment><USER8> I've been reading the "Software Estimation: Demystifying the Black Art" from Steve McConnell.

He introduces a distinction that, at least for me, has been instrumental: estimations and plans are different things.

Estimations are honest, based on past performance data and probabilistic on their very natures.

Plans are, on the other hand, built with a target date in mind, taking into account the estimate previously made, desired delivery dates from customers and everything we are so used to.

By planing fulfillment of tasks closer to the estimates, you decrease the risk of the plan failing. You can build a shorter schedule and assume that staff will work overtime, assume more optimistic estimates and so on, but, then, the risk of failure will be higher. Such risk will, of course, never be zero though.

It's a simple distinction, but it has important implications. We don't feel anymore the pressure of making pessimistic, therefore dishonest estimates just out of fear of being pressed to cut the schedule. And also gave us a better argumentative tool to negotiate schedules with our clients.

I think it's also useful for making all the probabilities a bit clearer to project managers. It's like "OK, I know that you need me to commit with a delivery date, but I'm also going to make clear to you that there are some risks involved and I wanna make everybody aware of them"

<comment><USER7> That's an important distinction. The way we handled it was by letting managers define their acceptable level of risk and then use the model to define the estimates in that context.

For example, if they were ok with a 60% chance of making or beating a cost estimate, the forecast could be much more aggressive than, say, a management expectation of 90% chance of being on budget

<comment><USER8> Thanks for sharing this. I think I'll experiment presenting the situation to a customer using such model as soon as I have a opportunity. Sounds good.

<comment><USER7> This might be helpful:

[https://www.nasa.gov/pdf/741989main_Analytic%20Method%20for%...](https://www.nasa.gov/pdf/741989main_Analytic%20Method%20for%20Risk%20Analysis%20-%20Final%20Report.pdf)

It's a straightforward enough primer that it can be done in Excel, including simulating the data if necessary.

Even if this type of model is too simple for actual estimation, it's a useful (and sobering) tool to help managers understand why their intuitive estimates can so often be incorrect.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> > And here's the brutal question: what good are estimates if they hardly ever > align with reality? You could have spent that time on building software.

No one has ever been able to answer this question for me.

In my experience the accuracy of estimates is highly variable. Experienced developers who know each other and the system they're working on well tend to offer more realistic estimates, but even on the most smoothly run teams it's still fundamentally guesswork.

From my perspective it seems like the only real effect of estimating units of work is making developers resent people outside their team. Sure, it gives product people a number they can say when they get harassed about when something will be done, but it's no more accurate than one they could have just made up on their own.

I don't think I see any fundamental difference between estimating and what this author calls forecasting in this respect. It does seem like generating these metrics could consume less time than meeting to make up estimates, but it's not obvious to me that it always would be.

What real value does this add to any business? Any product or business people here? I'm genuinely curious what the purpose of estimating is. It feels like nobody is winning. Product and business people get annoyed by missed "estimates" because what they really want is to know the future, which is impossible. Developers resent being asked to predict the unpredictable. Not to mention I don't know any programmers who prefer talking about doing stuff over actually doing stuff -- all the meetings that come with management styles that include things like estimates feel like an enormous waste of money.

Who is winning here?

<comment><USER10> There are two very important reasons for estimation:

1\. Coordination with other teams or real-world events. In most decent-sized companies there are many people involved in a product or feature launch: product marketing, brand marketing, support, not to mention other dev teams. Many times these teams will need to broadcast external, hard dates (e.g. "our PR firmed lined up exclusives with journalists on date X") Being substantially late can affect lots of other people. However, importantly, this is not always the case. If you're estimating for the benefit of coordinating teams, _be very explicit about which other teams depend on your estimates, and why_.

2\. To prioritize and decide which features to build. Prioritization is solely about balancing expected benefit with expected cost, so if you're wildly off about the cost, your time may have been better spent building something else. Again, though, if you underestimate by a bit, but in the end come up and say "I wouldn't have really worked on things in a different order anyway" then nothing was really lost. I can definitely think of cases, though, where if I really knew how long something would take at the start I would have chosen to do something else, or at least do it in a different way.

<comment><USER11> > our PR firmed lined up exclusives with journalists on date X

That is the problem.

Wait for the product to get to an acceptable form, and then call the press in for tomorrow!

<comment><USER12> Getting a PR or marketing campaign up must be done in parallel to the dev work. It can take a few months to find the right journalists in the right publications , get their attention and get their time. On another note, some product launches are also times with fixed date events (Back to school (media industry), CES (Consumer electronics), any other expo in any other industry). it is key to time the dev deliverables. and if you need to chose between two features to dev, well, you need estimates as in inputs.

Estimates are not perfect, you should not spend 5 man days to plan 2 months of work. Planning can be done with guestimates and best effort and when done right, are super useful.

</comment></comment></comment></comment><comment><USER13> The disdain for estimates in some of the comments here indicate that there is an organizational problem in the way those estimates are solicited, rather than a problem with the idea of estimating work itself.

I used to work for an organization where engineers so universally loathed the idea of estimates that I was convinced that it was just a necessary evil. But a few months ago I joined an organization where the relationship between engineering (which I'm in) and business is not very adversarial. Here, estimates are a tool to answer the question "how much work should we take up in the next sprint without burning ourselves out?". The estimation process is not loved, but it's not hated either.

<comment><USER14> 1) Most of HN is young and has never worked on the business side of an org where they had to do things like lose a customer because the feature they wanted is taking too long to finish or repeatedly push back multiple expensive dependent non-engineering projects because engineering keeps hitting development roadblocks.

2) A lot of developers really hate committing to any kind of estimate because they're really just not that good at estimating for a variety of reasons and getting stuck in a commitment that turns out to be unrealistic really sucks.

3) In my experience a good portion of orgs really are bad at business- engineering interactions and end up in adversarial relationships like you're talking about where engineering is seen as "those guys that refuse to commit to any deadline and suck at communicating status I can plan around" and the business owners are "those guys who don't understand what they're asking for and are constantly trying to micromanage to get blood from a stone". Also in my experience, neither side is entirely innocent in these situations.

<comment><USER11> > A lot of developers really hate committing to any kind of estimate

In development (as opposed to production) I personally fight against any commitment if it comprises the "what" as well as the "when".

You fix the date of the next release and provide me with a prioritized list of bug fixes and features to work on? Nice, let me start to work!

You think that a specific new feature could improve our sales and you let me drop anything else and call you back as soon as I have any news? Wonderful, I'm already analysing the issue in my head!

Anything else, and I'll let you know that your dreams are not likely to come true.

<comment><USER15> The iron triangle[1] is a well known model. If the "business" side insists on "engineering" breaking it, they are not serving their function.

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

</comment></comment></comment></comment><comment><USER16> I thought that we'd solved this problem - don't do estimates but rather adjust what we build to fit the available time. And estimates of what is going to be shipped get more and more accurate as time goes on (because you can ship what you've already built), whereas estimates of time remaining can continue to be wildly inaccurate for as long as you like (scope creep etc).

Then the end of the allotted time you have a product. Maybe it's not good enough. So you either give up or you allot more time to it. But the product should be usable as-is and solve some of your problems.

Problem I have with the above is that it requires developers to be honest and put in consistent effort, but that's more of a leadership and motivation issue.

<comment><USER3> I agree, but that's still a form of estimation though, you're just estimating that you'd be able to deliver on your list of features in the time you have. You could be wrong, and then end up with less features, or be forced to spend more time.

<comment><USER17> i don't think the claim was that we're no longer estimating. the author was attempting to articulate the process of estimation, where initially one promises the world in N amount of time. As N draws near you reduce feature / scope as needed.. and perhaps when the deadline hits and all you got is a int main(void) { printf("hello world"); return 0; } you figure out what you can make due with where you're at. i like this approach and it resonates with a lot of other great comments in this post.

</comment></comment></comment><comment><USER18> 99% of teams that need estimations are not in a phase where they are designing something that is hard to estimate. And those that are usually are prudent enough to not bother R&D with project planning(yet).

99% of engineers are working on things that CAN actually be estimated fairly accurately. New CRUD APIs? New ETLs? New React component? New integration with a product that has a published API? New service? New message format? New protocol? Whatever. Just break it down enough until it's very clear what it takes to get it done. There will be a few unknowns but you can call them out as risks. Try to eliminate risks first and raise a flag so your manager/PM can adjust his forecast.

The thing is, everyone wants to be "working on the next big thing" so much that they actually believe they are working on something groundbreaking that cannot be estimated. Either that or they are not qualified for the job yet(hence they need to learn something new, which can be unpredictable). They just need to be grounded and it's a fairly easy journey. They are all probably emulating the symptoms of those in 1% by believing they cannot estimate their work.

<comment><USER19> > Either that or they are not qualified for the job yet (hence they need to > learn something new, which can be unpredictable)

IMO this attitude is pretty prevalent, and _extremely_ harmful to software engineers. Software frameworks, methodologies, and techniques change very fast [1], and if you think that someone who needs to learn something is unqualified for the job, you are going to have an inherently adversarial relation with the engineers on your team.

Learning is and should be a normal and expected part of the _day-to-day_ job of a lot of software engineers today. I think this contributes a fair bit to the problem of estimation.

[1] In contrast, I haven't seen a ton of novel developments in project management since the early 200s, we are still beating the drum of "Do Agile Not Waterfall" almost 20 years later

<comment><USER20> Yeah, the status-quo for me for several years has been "I don't know" because _most_ things I build end up needing to debug something I don't have an immediate answer for, or construct something new, or talk to a new team, or find a new lib, or change a new setting, or migrate to a new platform. If I'm repeating work I'd done many times before, that's something that should be made more flexible and automated so I don't need to do it any more. (these of course exist, but you're pretty easily replaceable if this is a super-majority of what you do daily)

So my estimates are pretty much always "if it's well-built, documented, and fits what I expect, a week or less. If not, up to 2 months or more, but I should know more in 2 weeks". Getting a more accurate estimate quite often means spending as much or more time investigating than it would take in the optimistic case, so usually the answer becomes "give it a shot and we'll decide again later". Sometimes I have good news, sometimes not.

\---

We sit on top of _millions_ of lines of code, changing faster than we can _read_ much less _understand_. You cannot know it all, nor is it worthwhile to try in the vast majority of cases. Poking into new territory is common, and the ability to do so effectively is a super important skill.

<comment><USER18> Code organization (part of Architecture) matters a lot here. Especially in large code bases. Software is meant to be "soft" or pliable easily. To do that, one should be able to alter a module without having to understand the whole system. If a small task takes too long, there's a problem with the software architecture or code organization.

<comment><USER15> I think GP's "millions of lines of code" references the code that runs all the systems outside of your particular org's architecture.

<comment><USER18> Got it. Better to stick to tried and tested "boring" stuff and actually code small functionality yourself than chasing a thousand line library for trivial stuff.

At work, someone used a 3rd party library to send stats to a server in json format and "standardized" on it. 100s of developers had to now learn this new library and it's APIs and one bug caused everyone a bit of hassle. It probably made the original dev's job just a little easy but made it a bit hard for everyone else. These things do happen. The point is to learn from this and make better decisions over time, not give up and say we can't get better. Trying to provide an estimate forces you to think more carefully and become better over time.

<comment><USER15> A poor library choice or two is not even 1% of the systemic dependencies any system has if it's working at a reasonable level of abstraction.

> "not give up and say we can't get better"

Not sure why you feel the need to state this straw man? That is not my opinion, nor do I think it is the GP's.

<comment><USER18> It was not a counter argument to anything per se. Just pointing out that even with episodes of failed estimates, there is reason to continue estimating.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> The purpose of providing an estimate is to get the person asking off your back, so you can go back to getting work done. Beyond that, there's little to no value. People ask for estimated because lies are strongly preferred over uncertainty.

<comment><USER22> Estimate are useful in software businesses for a wide variety of important reasons:

\- so you can tell the customer when they can reasonable expect to get something they need

\- so you know when you will need to be ready with the next project on the agenda

\- do that you will know when you might consider adding resources to a project to make it go faster (yes, this is not always possible, but it sometimes is)

\- so that you will know if your funding runway is sufficient for your R&D needs

\- so that you can compare two or more different projects when deciding what to work on; time to completion can be an important consideration in these decisions

</comment></comment><comment><USER23> > For example, the historical throughput of your team can be used to run a > simulation of future throughput. Some outcomes will be more likely than > others and you can use these numbers to come up with statements like: "41 > items or more can be completed in 30 days with a certainty of 85%".

As usual, there are two base assumptions to this:

\- your work environment didn't and won't have any significant change for a long time (tools, requirements, team composition etc.)

\- your team output is somewhat stable, with no month with 300 tickets and others with only 50 tickets.

In my experience these two assumptions are surprisingly rare to justify in any decently growing company.

In particular as company grows, tools change, organization and processes change, people change. On top of that there is often seasonality.

We can still throw around forecasts, but IMO in these conditions it has no more legitimacy than random guesses.

<comment><USER5> Author of the article here.

Significant changes will indeed make your forecast not come true. But mostly people are not asking to predict for situations with significant changes.

Incremental changes will just be incorporated in the forecasts over time. The forecast continually adjusts to new information becoming available.

It's interesting to know that after about ten work items completed the number become pretty stable. So it's easy to reset or adjust the forecast in case of a big change in the team.

I was personally surprised to learn how stable the output of a team is if its composition doesn't change. Tools have some impact on productivity but so big that you have to throw away your predictions. No one is complaining anyway if you over deliver a little.

<comment><USER23> > people are not asking to predict for situations with significant changes

That's for coming up changes. Your predictions will also be of poor quality after a significant change as you lose the link with historical data.

In the end there might be only a small window between two changes where they are worth anything.

To be clear I am not saying you shouldn't make prediction anyway, just that the effort to come with "a system" is not worth it in a lot of situation.

For context, tech industry has one of the highest turnover, a team losing/gaining a member is not some rare event. A new boss coming in to change process or teams isn't either.

[0] [https://business.linkedin.com/talent- solutions/blog/trends-a...](https://business.linkedin.com/talent- solutions/blog/trends-and-research/2018/the-3-industries-with-the-highest- turnover-rates)

</comment></comment></comment><comment><USER24> Also see the classic Joel on Software article from 2007 - _Evidence Based Scheduling_

[https://www.joelonsoftware.com/2007/10/26/evidence-based- sch...](https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/)

It's still in FogBugz.

[https://www.fogbugz.com/Evidence-Based- Scheduling](https://www.fogbugz.com/Evidence-Based-Scheduling)

</comment><comment><USER25> The only projects I can accurately forecast is the one I have already implemented elsewhere. Meaning 90% of it is a rehash of something done elsewhere. Companies do this because... well.. reasons. Anything else novel/unique/innovative by definition can't be predicted well because if you knew everything from the start, there isn't any innovation being made. Many of the good companies that exist today pivoted from a broken prior idea or discovered a market while experimenting. This applies to every part of software development.

<comment><USER18> How often do you _really_ do novel/unique/innovative stuff? Honestly.

<comment><USER26> There's pretty much always something novel or unique in the way things are put together. I recently had a project that was at first glance a pretty trivial "enter data, verify it, package as XML and send to a backend". Until we realized that the combination of privacy requirements and an industry spec would have required us to do schema validation of the XML in the browser. And apparently the only Javascript library which does that is machine translated from C, not very stable and doesn't support UTF-8.

<comment><USER27> O/T but was it XML Schema specifically, or just XML DTDs that you needed to validate against? For the latter case, there's [1] (my proj), plus the option to rewrite XSDs into DTDs (under natural assumptions eg no local element redefinitions) without having to wrestle with Xerces and/or libxml (which hasn't formally completed XSD support anyway) and emscripten. You might also have luck by transpiling Xerces/Java to JavaScript using Google's j2cl+closure-compiler (which works very well if you can swallow bazel and/or isolate the actual j2cl Java app from its bazel wrapper).

[1]: [http://sgmljs.net](http://sgmljs.net)

</comment></comment></comment></comment><comment><USER28> _Some outcomes will be more likely than others and you can use these numbers to come up with statements like: "41 items or more can be completed in 30 days with a certainty of 85%"._

I did something similar recently:

I started with taking the 20 tickets we closed and plotting story points vs actual time they took. Results were as follows:

\- 8s were mostly garbage, but consistently took more than one sprint.

\- 1s and 2s were also garbage but always took less than a 5.

\- 3s and 5s were fairly consistent, but at the same time could take up to 100% more.

Conclusion: split up all 8s if possible, treat 1s and 2s as 3s.

Second, I removed the outliers and created a distribution of point-per-sprint rates.

The result: 5.6 points per sprint with a standard deviation of 2.5 - <USER2> bad, but from that I could tell that our chance of delivering more than a given amount of points per person per sprint was(assuming a normal distribution):

85% for 3 points. 60% for 5 points. 17% for 8 points. 4% for 10 points.

Conclusion: per sprint we should either take one 5 point task or two 3 point tasks, but avoid 5 + 3 and never take on a 5 + 5. Also take a 3 if we didn't deliver the previous sprint.

Last point: some outliers were estimated somewhat highly (5), but took much less. One feature they had in common was the word "analysis" in the ticket title.

I guess the lesson here would be to ask: are we really planning on taking a whole sprint(two weeks) to analyse something?

</comment><comment><USER29> I appreciate new approaches to software estimation. But while this is an interesting approach, it fails to adequately address the primary issue: defining a "unit of work".

If it were possible to predict, with any degree of confidence, that task A (to do) is approximately equal to, or a 1/x fraction of, task B (completed), then the estimation problem would not be nearly so difficult to begin with.

Yet that's what this approach requires.

So cool idea, but not terribly applicable to actual projects in my opinion, unless you're able to break down projects into easily definable and predictable units of work (and yes, I know that there are various frameworks that attempt to do just that, with mixed results).

<comment><USER5> Author of the article here.

Unit of work is explicitly vague because it refers to the units you are using in your project, be it user story, requirement, epic, bug etc.

You do not need to know the size of each unit. In fact the method I describe acknowledges that there is variance in the size of each unit.

Some people advocate "same sizing" units of work. I have always thought that was a weird idea because it would imply making small units bigger. How would you make the unit that describes changing the color on a button the same size as integrating with an API? You can't even if you would have perfect knowledge of the amount of work required.

<comment><USER30> From TFA:

> Throughput is the amount of work that comes out of your project by unit of > time. It's up to you to decide what units make sense for your context. Days, > weeks, sprints, stories, bugs, epics – anything goes as long as you're > consistent.

Using days/weeks/sprints as your unit of work for determining throughput seems circular. If you want to know how many weeks of work your team can produce per week then you don't need a monte carlo simulation to tell you that.

Using stories/bugs/epics is flawed too, I think. You can have a fantastic model for your team's throughput in stories per week, but that doesn't tell you anything about when the project is going to be done unless you know how many stories there will be. There are two variables here (throughput and quantity) and you can't get useful information out of the product of them for free.

To see why, imagine that you take only the minimum amount of effort to very roughly divide the project into sensible-seeming chunks. In that case, your throughput in chunks per week will be meaningless (i.e. your model will have a confidence window which is uselessly wide) because the chunk division will have barely any relationship at all to the amount of actual work in each chunk. Now imagine that you're a bit more diligent in your project planning and look in a bit more detail at the work that will be involved. You've done some work to clarify what code will need to be written, and your confidence window will narrow accordingly. Now imagine that you're even more diligent. And so on, and so on. You eventually end up with zero error in your model, but in the process you've completely determined what code will need to be written, and the project is finished! Congratulations, you've invented waterfall. There's no free lunch here as the intro paragraphs of the blog post promise.

I assume that in practice you're stopping at some point in the middle of the extremes of doing nothing and planning out every line of code, and then applying your statistical model at that point, but I think you'll still be thwarted by the (at that point) _partial_ disconnect between the chunk divisions and the actual amount of work in each chunk. We've all experienced innocent-seeming tasks that end up consuming vast amounts of time unexpectedly, and various degrees of this phenomenon is what fundamentally ties the amount of error in any pure "stories per week" model to the amount of effort you spend planning and estimating the stories. No free lunch.

<comment><USER29> Exactly. I read the article fairly carefully, but the logic seemed circular to me. For a novel project, the problem of how to divide it up into predictable units of work remains. It's always the black swan little subprojects that destroy an estimate, and this approach doesn't help with those unforeseen events. If I could avoid those that reliably, I'd be able to estimate projects with a high degree of accuracy, even without using this approach.

In my experience, only increased subject matter expertise and a solid team with lots of experience can minimize the black swan events, and even then not 100%. They still happen with disheartening frequency.

And as you say, it doesn't buy you much if you want to measure how much work your team does per day/week/month, either, for the reasons you describe.

</comment></comment></comment></comment><comment><USER31> As a freelancer, I often do not see the problem in the estimate or forecast as such, but in the willingness to accept an honest / realistic one. This of course has a direct impact on my sales position. To make a long story short: Most people want to be lied to as long as time is what is being sold.

</comment><comment><USER32> There are a lot of responses here that boil down to: "Just use your intuition." This _is_ a legitimate way to estimate, however, like any estimation technique, it has weaknesses that make it inappropriate for many situations.

What's most helpful is to abandon the idea that there's "one true way" of estimating and instead educate yourself about the many estimation techniques that exist, and when and where to use them.

Also keep in mind that estimates are inherently political, that they can be used to guide or to destroy, and that may be the dominant factor in the choice of technique to use.

For a very good introduction to all of these factors (and others), and a survey of numerous estimation techniques, I recommend reading "Software Estimation: Demystifying the Black Art" by Steve McConnell.

</comment><comment><USER33> FYI: Scrum.org changed its Scrum Guide in 2011 to use the term "Forecast" instead of "Commitment":

source: [https://www.scrum.org/resources/commitment-vs- forecast](https://www.scrum.org/resources/commitment-vs-forecast)

</comment><comment><USER34> Meteorologists have trouble predicting if it will rain in 2 weeks. And that's with a highly sophisticated model of the earth's weather.

How can a team predict when various idea's are implemented into a software system... Too many interdependent things going on in software...

</comment><comment><USER35> > you can just start by writing down start and end dates of each chunk of work > in your process

End date is usually easy: "when someone closes the ticket" but maybe "when it was released" is better?

I have trouble determining the start date though. Some ideas: "When the customer reported it", "when the ticket is created", "when someone planned a release date for the ticket", "when the ticket was commit to in a sprint backlog", "when the ticket is assigned", "when the ticket was assigned to the one who finished the ticket", "when someone clicked on 'start progress'".

Each possibility comes with its own kind of noise and some requires additional discipline.

<comment><USER5> Author of the article here.

I normally recommend when starting out to take a small segment of your process first and then widen it as you get more experience.

For the start point I usually try to think of these aspects:

\- Can work still be cancelled at this part of the process. If so it's probably not the right spot to measure the start date.

\- Can work still be reprioritized at this point in the process? If so that will significantly widen the precision of the predictions that the forecast will make.

Also note that setting a the start date at the moment of commitment still gives you valuable insights in how much work you will be a able to next.

For setting the end date I think when the software is released is the most interesting point to measure. As always it depends on context. If you do a yearly release this doesn't make any sense because the granularity of all your predictions will be a year.

</comment></comment><comment><USER36> In short: don't try to estimate how much time each item takes. Calculate the baseline of past tasks and extrapolate into the future.

It's a good start on the path to more realistic estimations. But it does not yet satisfy what has in my career always been the main purpose of estimates: _relative_ cost analysis.

When colleagues ask me how much time a task will take, responding by "well, tasks take on average 8 days" is not helpful. They need to know _which tasks are worth the cost_.

How could we come up with estimates that are both evidence-based and relative?

</comment><comment><USER37> Forecasting time to move an item through dev cycle is best done this way, using historical data.

But if you want to know how long it will take to build "new system we have never done before" then, we are back to the estimation because i have to build a model of what the system will be - and although Incan think Inammaccurate I won't be ...

In then end forecasts and estimations are just able to answer two things - when _wont_ it be ready (ie it's definitely going to take longer than two months) and _have you thought of all the foreseeable risks?_

</comment><comment><USER38> Reading though the comments, it strikes me as we are all talking about things at many levels of abstraction. Forecasting should work fine for tasks defined at a fine granularity - we mostly take 5 days when we estimate 3 days. However, they fail fast when you are talking about a 6 month project. There are more variables and dependencies involved.

It also seems like the author is not from US and their definition of stable team might be very different from what I have experienced :)

</comment><comment><USER39> I used to say the software project would be done two weeks after the last change to the requirements and specifications. No more "just one more thing".

</comment><comment><USER17> i kinda started thinking about how project estimation and deadlines fit into our process of software development. For example, say you're building some feature and you guesstimate it'll take you 3 weeks to implement, maybe it's non trivial but not too hard. How do you convince yourself, or your stateholders, that spending an extra 2x-3x of time would result in delivery a better product.

in other words, if all software was built with the bare minimum amount of time to ship, i think we'd miss out on a lot of quality and a bunch of features that weren't thought out enough. so there are people that somehow are able to stop this rushed process of development and posit that the solution requires additional thought and planning. They go slower to move faster and knowing how to do this I think is a mark of an excellent engineer.

anther interesting element to this is that when one is granted the additional time, the outcome progresses our field. As an example, someone spent _a lot_ thinking about how to implement a concurrent wait-free list data structure. how are you to convince your PM that we have to delay the "onboarding popup" feature because you'll be spending the next 3 months investigating wait free data structures.

</comment><comment><USER40> There's an entire book about forecasting which may also be relevant (not just to time estimates)

[https://en.wikipedia.org/wiki/Superforecasting:_The_Art_and_...](https://en.wikipedia.org/wiki/Superforecasting:_The_Art_and_Science_of_Prediction)

<comment><USER35> I would love to have a prediction market for the plans at work. I fear management would mostly not appreciate such honest assessments though and nobody is prepared to think in probabilities.

</comment></comment><comment><USER41> Good estimates come from experienced estimators, and to me that is pretty much "guesstimating". No one is ever completely correct though, the estimate needs to acknowledge risks and how they may blow out time, cost or quality, then mitigate those risks or manage them.

</comment><comment><USER42> Unrelated; Why is there no rss feed for this blog? I can't find it. It seems they've interesting topics and I'd like to keep posted when there's new content. Do the expect me to go to their website every day to check?

<comment><USER43> Here is the RSS feed: [https://www.reaktor.com/feed/](https://www.reaktor.com/feed/)

<comment><USER42> Thanks Couldn't find it on /blog/feed, also not in source.

</comment></comment></comment><comment><USER44> Everything based on historical data doesn't work for me, because there are too many variables.

</comment><comment><USER45> Guestimate? There's already a real word for that (estimate). Is it automagic too?

</comment><comment><USER46> Isn't this basically what Scrum and story points do?

<comment><USER47> Although wait, what is this?

> In one project my team decided to start pair programming when the time it > took to complete a task was in danger of violating our forecast.

They tried to hurry up to stick to the "forecast"? Okay no thanks, not for me.

<comment><USER5> Author of the article here.

The thinking here was that work that reaches a cycle time that is higher than 85% of the other work we completed is probably worth some extra attention. Is the person working on it stuck? Is the problem so complex that it might be useful to sit down and have a look at it together?

We all felt it was a good motivator to work together on a regular basis. Or at least step up the amount of communication around that unit of work.

<comment><USER47> My intuition would be: our "forecasting" solution is never going to be 100% right. Here's an example where it's completely wrong, scrap the "forecast" and get the work done. Don't sleep in the office overnight, don't throw more developers at it; acknowledge no forecasting system ever will get creative work predictions/forecasting correct.</comment></comment></comment></comment>


Ask HN: Is learning to code = learn JS/HTML/web only? - <AUTHOR>

I could not frame this title properly but what I really wanted to ask you is that majority of the players in coding tutorials (codeacademy.com etc.) have their homepage saying "learn to code" and all it does is to start with Javascript and stuff. Shouldn't learn to code equate to basics of computer science, algorithms, data structures etc. or those things don't matter much? Am I thinking too much here ? <comment><USER2> Those "learn to code" guides are the equivalent of "learn how to take care of your car" that teach you how to change the oil. It's enough for a casual user who wants to automate some repetitive tasks or customize his blog. It's definitively not enough if you want to be serious about the craft and become a mechanic/build real software.

</comment><comment><USER3> You might like this article: <http://norvig.com/21-days.html>

<comment><AUTHOR> Yes very good read. thx for sharing.</comment></comment>


Comcast neighborhood WiFI - <AUTHOR> https://wifi.comcast.com/hotspots.php

<comment><USER2> not sure if this is the same thing, but i've seen something like this a few months ago. To connect to the interwebs, just select the "xfinitywifi" network to connect to, then sign in to xfinity account in the landing page! ..

..BUT

the connection _sucked_ since the signal was from other units in my apt. building....

<comment><USER3> Here's my humble head-scratch: you pay for a comcast internet access, you might have bought or you're leasing the cable modem + wireless router, and perhaps there's an opportunity to opt-out (somewhere), but nonetheless my neighbor (who must at least have an xfinity account) is streaming their content through my connection. Somehow it seems like wireless usury.

<comment><USER2> you're right, i'm no longer mooching off of my neighbors now(maybe because the connection was so bad) but i feel like it's not unethical because comcast made it available, so why not use it?

</comment></comment></comment><comment><AUTHOR> Like most people, I'm not normally a Comcast fan, but this is really interesting.

It's really convenient in San Francisco because I can almost always find a network to connect to, but I do wonder about security implications of having this feature enabled by default on my home router.</comment>


Scientists create a pattern so complicated it's impossible to duplicate - <AUTHOR> https://www.livescience.com/micropattern-cannot-be-forged.html <comment><USER2> Warning!

Site will throw a full page "AdBlocker Interference detected..." modal screen over the content.

Another domain to add to my Tampermonkey HN block list.</comment>


Sequester Cancels NASA Outreach - <AUTHOR> http://www.universetoday.com/100949/sequester-cancels-nasa-outreach/ <comment><USER3> The sequester is a big sick joke. A bunch of toddlers are throwing tantrums in DC right now, trying to scare the public over big bad cuts.

The truth is, America has a priority problem. We have more than enough money to spend. The toddlers in DC are used to getting their way and free spending like crazy (thus the trillion dollar deficits). Now they're being forced to make choices, and they're openly attempting to scare the public.

The best example of the sequester con is the White House tours. It's a big lie that they can't keep it open, pure propaganda.

The things we're free spending money on right now are disgusting. We have money to drone the planet and murder thousands of civilians, but not to hire teachers and fix bridges. We can keep Guantanamo open and spend money torturing people, but we can't keep our schools open. We can give the theocrats in Egypt lots of money, but we can't keep a simple NASA outreach program. We can spend a trillion dollars on the mostly pointless and highly dysfunctional F35 that will barely ever see action, but we supposedly can't keep the FAA operating at max capacity. Biden can spend a million dollars on one night hotel stays in Paris and London, but the White House has to cancel various Easter celebrations.

<comment><USER4> I agree with you to a large extent, but you're doing the same thing by making sweeping mischaracterizations.

For example, you mention 'Biden can spend a million dollars on one night hotel stays in Paris and London.' I looked into this, and indeed two one-night stays in each city totaled up to about that amount. But in each case, they booked out over 100 rooms. Now the VP certainly has an entourage of secret service agents and personal assistants, but the majority of those rooms were likely occupied by policy administrators of one sort or another there to meet their opposite numbers in Paris and London. This is why state visits are a big deal; on TV we just see handshakes and maybe a snippet of a speech, but all sorts of diplomatic work - trade negotiations, extradition discussions, etc. - <USER2> place out of sight of the cameras. State visits are planned months in advance so that bureaucracies can coordinate the international dimension of their activities around them. A million bucks is cheap at the price if it advances economic progress.

Now you may not have noticed, but one of the more interesting things in the state of the Union speech the President gave last month was a commitment to a new US-EU Free Trade Agrreement, which would be the largest trade deal in history: <http://www.bbc.co.uk/news/business-21439945> which would be worth hundreds of billions annually in increased economic activity. You bet I want the VP to take a bunch of policy wonks along with him when he goes overseas.

I think the first step in getting beyond tantrum politics is to address things on their merits and in their proper context, not in the form of zingers and stereotypes.

<comment><USER5> From what I know about Biden it would probably be better if he did not make these trips. He seems to be a very good politician but as I have learned more and more about him I seriously doubt he has the ability to make sound decisions. Not that he has a lot of competition in his profession.

How about we just send the experts next time.

<comment><USER5> Sorry I should have provided more background. Biden has been covered on HN extensively. No intention make a political statement just pointing out Biden's particularly poor decision making on issues I (we?) tend to care most about.

On privacy: [http://www.wired.com/dangerroom/2012/12/joe-biden-private- em...](http://www.wired.com/dangerroom/2012/12/joe-biden-private-email/)

On IP: [http://www.techdirt.com/articles/20110413/12094013882/joe- bi...](http://www.techdirt.com/articles/20110413/12094013882/joe-biden-theres- no-reason-to-treat-intellectual-property-any-different-than-tangible- property.shtml)

On major internet issues: [http://gizmodo.com/5041044/vp-candidate-biden-is- no-friend-t...](http://gizmodo.com/5041044/vp-candidate-biden-is-no-friend-to- file-sharing-net-neutrality-protection-or-online-privacy) <http://news.cnet.com/8301-13578_3-10024163-38.html>

</comment></comment></comment></comment><comment><USER6> The sequester is serious business in science. A scientific workforce and the equipment they need must be maintained; it's not easy to ramp up or down capacity as demand and funding levels shift. The pipeline for an individual into a high-level science career is measured in DECADES. If you screw with funding levels for a few years you're blowing a gigantic hole into the side of your already-leaky pipeline.

Science was a pretty lousy career choice before all this started, but these budget shenanigans will only drive the smartest and most capable young people out of science for better paid, less uncertain vocations.

<comment><USER7> Absolutely. As a grad student about to graduate from a prestegious biomedical institution I'm looking at no new grants for the next (few?) years. The NIH is likely zeroing any new grants in order to maintain current grants. Guess what industry I cannot graduate into!

The upside I guess is that I will likely attempt to create my own company instead. A far riskier proposition. But I'm on the far end of the spectrum - few of my peers are doing that though - they're finding jobs in other industries.

</comment></comment><comment><USER8> Meh. NASA outreach sucks in any case. They manage to make space look boring - ever watched one of those conversations between middle schoolers and ISS crew? Just get the kids a few sci-fi books instead, you'll get a much more enthusiastic and motivated next generation of engineers.

<comment><USER9> Have you ever watched a rocket launch on NASA TV? For me, it doesn't get much more thrilling than that. And I've seen some in person.

<comment><USER8> So the coolest events on NASA TV are those in which the "outreach" people play no role and just let the cameras speak for themselves. I agree.

<comment><USER9> I think you're being unfair. I don't know how large the crew is for those events, but I'd venture to say all would call themselves "outreach people". I take your point that a lot of what airs is not very good, but to throw all outreach efforts under the bus is uncalled for.

Another outreach example that allows you to rove the same terrain as the Mars Science Laboratory: <http://mars.jpl.nasa.gov/explore/freedrive/> . I'd say this is pretty damn cool, and actually informative.

The folks who do this work are rather nervous right now.

</comment></comment></comment></comment><comment><USER10> I think it is worth mentioning that in addition to the $900 million in cuts required from the sequester since the sequester has gone into effect, Congress has proposed cutting their funding an additional $300 million this year. Therefore, pinning all this to the sequester seems a little unfair. [http://www.app.com/article/20130321/NJNEWS17/303210108/Seque...](http://www.app.com/article/20130321/NJNEWS17/303210108/Sequester- spending-bill-chop-NASA-funding)

Sadly I worry these cuts are more political than practical, but then again it just says the programs are being suspended until they are reviewed so hopefully they'll still come back and maybe some waste will be discovered in the process too.

</comment><comment><USER11> I like how the decision makers say we need to grow out of our debt problems. Then they cut programs like this? Do they think we will actually grow with cuts to STEM education? The advent of the internet, biotechnology, hell...even proprietary trading. Almost all the recent growth cycles have been fueled by STEM.

The decision makers are foolishly creating a massive technical debt.

</comment><comment><USER12> From the article: the cuts are "hitting where it hurts: in education and outreach". Is that really where it hurts for NASA? What about space exploration and research? Aren't those a little more important?

<comment><USER13> Without education and outreach, perhaps there won't be enough talented and engaged people to take part in designing, building, and operating the equiptment for space exploration?

<comment><USER14> Sure. The NASA Outreach Program. Teaching our kids how to design, build, and operate spaceships. Without it they're all going into liberal arts.

Sorry, but I have a feeling education and science will survive the Sequestocalypse just fine. Although if we don't get the budget under control today, our kids won't have the money for space exploration in the future.

</comment></comment></comment><comment><USER15> Guess that clears enough budget to buy more F35's. Because what future needs inspired engineers right?

<comment><USER16> Don't forget about a replacement for the M4: [http://www.bloomberg.com/news/2013-03-19/army-carbine- progra...](http://www.bloomberg.com/news/2013-03-19/army-carbine-program-may- waste-1-8-billion-report-finds.html)

Obviously the F35 is more important though. Who honestly thinks the future of air warfare will be with drones. </sarcasm>

</comment></comment><comment><USER17> Go to space, do cool things....outreach problem solved.

</comment><comment><USER18> Weren't people trying to choke NASA before the sequester? Is the effect of the sequester more significant than previous efforts to slash NASA budget?

</comment><comment><USER4> That's pretty depressing.

</comment><comment><USER19> Compromise: one-way missions to Mars for a select group of politicians.

</comment><comment><USER20> Is it possible to create a Kickstarter for public sector services?

<comment><USER21> Yep, for a significant period of American History, a good bit of long-distance travel was over privately constructed and managed turnpikes. Their financing was very much in the Kickstarter model:

"American turnpikes were stock-financed corporations seemingly organized to pay dividends, though acting within narrow limits determined by the charter. [F]or the American turnpikes the hope of dividends was merely a faint hope, and never a legal obligation. Odd as it sounds, the stock-financed "business" corporation was better suited to operating the project as a civic enterprise, paying out returns in use and esteem rather than cash."

<http://eh.net/encyclopedia/article/Klein.Majewski.Turnpikes>

</comment></comment><comment><USER22> I guess JPL isn't doing their open house this year =(

</comment><comment><USER23> On a related note, air travel this summer is going to suck. More so than usual: [http://www.nytimes.com/2013/03/23/us/politics/ohare-tower- ma...](http://www.nytimes.com/2013/03/23/us/politics/ohare-tower-may-become- sequester-victim.html?hp&_r=0)</comment>


Ask HS: can TensorFlow be used for combinatorial optimization problems? - <AUTHOR> Working on a scheduling problem - I have heard of  neural networks being used for this problem domain but wasn't sure TF covered this domain. <comment><USER2> You can use the tensor formalism to express combinatorial problems, but these will not be smooth, so gradient descent algorithms will not work. However, you can turn such boolean tensor problems into huge SAT problems and solve them with SAT solvers. See for example here: [https://github.com/mmaroti/uasat](https://github.com/mmaroti/uasat)

</comment><comment><USER3> In general, TensorFlow and other automatic differentiation frameworks (Chainer, Torch, Theano, etc.) operate on gradient descent of smooth functions. If you can recast your combinatorial problem into a smooth function, then these frameworks may be applicable. However, most combinatorial optimization problems aren't readily transformed into smooth functions, so this is unlikely to be straightforward.</comment>


REST For the Wicked - <AUTHOR> http://sudosoldiers.github.io/rest/#/

<comment><USER2> Nice list of words.

<comment><AUTHOR> [http://i.imgur.com/TJaL85e.png](http://i.imgur.com/TJaL85e.png)</comment></comment>


Show HN: Private banking tools for the rest of us - <AUTHOR> I'm excited to share Automated "Sweep" Transfers are now available in the Astra app. "Sweeps" are typically only available via private banking – they automatically move any funds over a given threshold to another account so you can save more without overly affecting your cash balance. Astra is the first app to offer this advanced banking functionality to the everyday consumer! Would love any and all feedback on our new feature.
http://bit.ly/2RcLWWo <comment><USER2> Sounds great, but I see nothing on your site telling me why I should trust you with my banking credentials.

<comment><AUTHOR> Thanks for the feedback. What would you expect to see? We are probably doing it but could do better at sharing that info.</comment></comment>


Try Demo: Play space invaders on computer browser & control with an iphone/ipad - <AUTHOR> http://www.webdigi.co.uk/blog/2012/using-an-ios-device-to-control-a-game-on-your-browser/

<comment><USER2> Good work. Finally some good use case for QRcodes to pair device and computer.

</comment><comment><USER3> cute. though it hangs sometimes.

<comment><AUTHOR> probably the hacker news traffic load</comment></comment>


ICO startups band together to create $100M grant fund for Ethereum projects - <AUTHOR> https://techcrunch.com/2018/02/16/ethereum-community-fund/ <comment><USER4> So much money and yet this is what they are betting on: [https://www.stateofthedapps.com/](https://www.stateofthedapps.com/). I just baffles the mind, how much money is being thrown at this. I think Ethereum is still mostly just a foggy idea of something that might have potential. But it is nowhere near ready to host any dapp that creates value. The chief problem is that while you can execute code in a decentralised manner, you cannot interact with the real world in a decentralised manner. You still need to have a trusted source of information from the outside world. And if that wasn't enough of a problem, anything that isn't a stupid game is going to run into legal hurdles very quickly.

<comment><USER5> Oh the cynicism here is so sad. To everything there is a season, I guess. Anyway! Does the Dai stablecoin not undermine this idea that nothing worthwhile can be built on Ethereum? Don't like ICOs? Neither do I. While the evolution of ICOs in 2017 was really interesting I think DAOs (and things like DAICOs) will see more prominence in 2018. It is an exciting world!

<comment><USER6> It's a common error of judgement to assume that people who don't share your unvarnished enthusiasm are cynics. One way to test for this is to see if you can intelligently address the concerns of "cynics" without just waving your hands and invoking the rosy future you imagine. It can be helpful to look to the past and present and try to understand why people have reservations, and address them comprehensively.

<comment><USER7> The original comment was cynical wasn't it?

</comment></comment></comment></comment><comment><USER8> This is a sensible move, I think.

Of all the cryptocurrencies, ETH at least has a story about why it might have intrinsic value in the medium-term, beyond pure speculative passion: i.e. its use as a platform for smart contracts. But that potential only gets realised if more people use it for more significant purposes, rather than just for functionless ICOs or trivial games.

On the other hand, if this injection can help ETH grow this year, the backers of this fund should more than make their money back.

It's going to be an interesting year, I think. It's easy to shout bubble bubble bubble, and easy to shout buy buy buy. My hunch is that the reality will be more interesting than either.

<comment><USER9> My understanding of Ethereum is that it markets itself as a smart-contracts platform, and you need to have an associated coin (Ether) to pay people to run the platform.

But the number of Ether is fixed at 100,000,000ish. Which means that if the platform is successful, the coin will increase in value indefinitely. But I don't see why those who 'miss out' on the presale etc. (think banks, governments) would choose to hop on board at a later date - <USER3> gifting money to early adopters - when they'd be better off simply creating a new coin (or indeed forking Ethereum and awarding themselves more Ether). It all just seems very unstable, game-theory-ish situation.

<comment><USER10> > But I don't see why those who 'miss out' on the presale etc. (think banks, > governments) would choose to hop on board at a later date - <USER3> > gifting money to early adopters - when they'd be better off simply creating > a new coin

This exact same argument has been repeatedly given to explain why Bitcoin would never break above $10, $100, $1000, whatever, or why Ethereum was doomed to stay in the pennies. Clearly the late adopters see more value in entering than they see a problem with gifting money to earlier adopters.

Creating a new coin or forking doesn't solve anything, they would be alone and it wouldn't have any value if nobody wants to trade in.

The value is what people value it at. Just because the supply is bounded doesn't mean its value will increase indefinitely.

<comment><USER9> > Creating a new coin or forking doesn't solve anything, they would be alone > and it wouldn't have any value if nobody wants to trade in.

Well, is the point of Ethereum to make some cash at the expense of later investors (basically a Ponzi scheme), or does the platform have some intrinsic value? Point is, the platform itself can be duplicated at little cost (it's an open source project after all, just fork it), so the cost to the (new) user should be low (or more importantly, _stable_ ), even if the value proposition is high.

This logic leads me to conclude that almost all the value of Ether is purely speculative and could disappear at any time.

<comment><USER5> The software can be duplicated but the network of devs, users, validators, etc is harder to duplicate.

The intrinsic value of ETH is to use it to pay for transactions on the Ethereum platform. These transactions are used to form dApps that can be run without censorship. I would have said the value of that is TBD but now I'd stay that some minimum value has been determined (ICOs, DAOs, the Dai system, games, etc.)

</comment></comment></comment></comment></comment><comment><USER11> Really good/bad mixed feelings on this.

\- Is it legal for effectively crowdfunded projects to then fund other projects?

\- Ethereum has integrity, willing to change its core technology in order to become more scalable. But...

\- Is "paying off" developers to build apps for it just evidence of the lack of apps naturally/organically being built?

\- Yet Seed Stage funding from traditional VCs has dried up, so is this effectively a market response from technical-oriented now-wealthy investors, to make up for it?

I think these are hard yet important questions. Obviously, who doesn't wish they were rolling in this kind of cash to dole out? At the same time, we already have people building P2P dApps with our system ([https://github.com/amark/gun/wiki/auth](https://github.com/amark/gun/wiki/auth)), you know, the ones that Ethereum/Dfinity/etc. can only dream of doing even after they hit their scaling goals (realtime character-by-character updates on decentralized social networks - [https://www.youtube.com/watch?v=C3akdQJs55E](https://www.youtube.com/watch?v=C3akdQJs55E) , 3D multiplayer VR games - [https://www.youtube.com/watch?v=s_m16-w6bBI](https://www.youtube.com/watch?v=s_m16-w6bBI) , etc.), so it seems nonsensical that so much money is being offered to build Ethereum apps - is there genuinely a lack of developers?

<comment><USER12> I think right now the easy money is all in ICO's. Talented developers have much more incentive to just create a new coin than develop a dAPP on Ethereum. Eventually, this ICO craze should slow down, and it will make more financial sense to develop on top of existing coins.

<comment><USER13> Take a quick look at how many of those ICO tokens are built on top of Ethereum: [https://coinmarketcap.com/tokens/](https://coinmarketcap.com/tokens/)

Most of those are connected to some kind of dApp project.

</comment></comment></comment><comment><USER14> Every day I'm further convinced that all that's happening in this space at the moment is that cryptocurrencies are soaking up enough fiat money to push it at someone to come up with a good reason for them to exist.</comment>


Gnuastro (new GNU project) released - <AUTHOR> https://www.gnu.org/software/gnuastro/ <comment><USER2> Personally I find that many people in the astrophysics department I worked in used either IDL (an abysmal language, for which there is a free GNU compiler) or Python+Astropy+Numpy+Scipy+Matplotlib (which are all free software). While I really love the work that GNU does, I get the feeling that they have a lot of NIH when coming up with new projects to work on -- maybe they should focus on Hurd or start some new and innovative projects.

</comment><comment><AUTHOR> Official announcement [1]

[1] [https://lists.gnu.org/archive/html/info- gnu/2016-05/msg00017...](https://lists.gnu.org/archive/html/info- gnu/2016-05/msg00017.html)

</comment><comment><USER3> Nitpick: there is but one GNU project but many GNU packages. Octave, R, Gnome, gcc, Emacs -- these are all just some examples of GNU packages.

<comment><AUTHOR> Sorry. The "(new Gnu project)" part was picked up from the announcement's Subject header. But it is stated as "an official GNU package" in the body.

Can the HN title here be changed?</comment></comment>


Snapchat Says Sorry for Data Breach, Updates Apps With Find Friends Opt-Out - <AUTHOR> http://techcrunch.com/2014/01/09/snapchat-updates-android-ios-apps-with-new-security-features-and-finally-says-sorry-for-december-data-breach/ <comment><USER2> A ridiculously tepid non-apology apology considering the scale of the breach.

<comment><USER3> They said the word "sorry," which is an improvement.

</comment></comment><comment><AUTHOR> It's taken a while but SnapChat has finally said sorry for their infamous data breach. But the question still remains is what would you do if your were one of the victim of the 4.6 million usernames and phone numbers that were leaked. Would you just accept an apology? I don;t thinks so.

<comment><USER4> My username and phone number were leaked. I have felt no negative impact from this happening. I am mildly annoyed that someone went through the process of making a full database, but I willfully gave my phone number to snapchat for the express purpose of letting people identify it with my username.

I accept an apology.

</comment></comment><comment><USER5> Cut the guy some slack, he also has to learn. Do you think you would have known straight away how to defend your company against the press, hackernews haters and how to apologize to millions of people when you were 23??

<comment><USER6> I wouldn't have bet $3,000,000,000 I did though.

</comment></comment><comment><USER7> I know it's hard for companies to admit it when they make mistakes / fail, but I think it's important that they do. There's always the risk of litigation etc.. but I think that at the end of the day, given that you can't undo the past, it's always best to come froward and apologize. I know it's talking from the sidelines, and there are probably a lot more considerations that go into it, but as a consumer I do feel better about a company that fails and then takes responsibility for it.

<comment><USER8> I don't think Snapchat has admitted to any mistakes. What they have said is they are sympathetic to users who have had their data stolen by hackers.

They are using the word sorry in the "we are sympathetic" sense, not the apology sense.

Sorry you feel that way. Sorry your kid got sick. Sorry your car got broken into. The classic non-apology apology.

</comment></comment><comment><USER9> Snapchat has always had the option to provide my mobile phone number in the iOS app so people can find me by my number. I've never filled it in because I was always uncomfortable giving out my phone number to some random app. When the data breach happened, I checked and my phone number was not in the leak.

To clarify: the only way your phone number would be known by Snapchat and thus could have been leaked is if you provided it to Snapchat manually, correct?

<comment><USER10> Not on Android. As far as I can tell, I never provided my number to Snapchat, aside from installing the app.

</comment></comment><comment><USER11> He should apologize for turning down $3B USD from Facebook.

edit - To answer your question: to his shareholders and employees holding options, because it was the right decision from a CAGR perspective.

edit 2 - if they get acquired 2 years down the line for $5B, it will still just be a CAGR of less than 30% from the FB offer. It's OT though, so I'll leave the post up to collect my downvote punishment.

<comment><USER12> That would have been the right decision.

However Facebook making such an offer is just nuts. What are they buying? 90% or more of the snapchat user base is on Facebook. Why dont they make their own? Make a seperate app, make a new brand and push it on fb.

<comment><USER3> They did make a separate app called Poke and it was heavily pushed.

It worked out as you would expect.

</comment></comment></comment><comment><USER13> Too late, already deleted my account. It was a useless app anyway. I personally had no use for it. Friends would send me random stuff all the time but I honestly didn't care. It was usually mass chats anyway.

</comment><comment><USER14> Opt-out should be default for this to be even relatively meaningful.

<comment><USER15> User's had to opt-in to give Snapchat their phone number. I think this let's you opt-out, even if you had previously opted-in.

</comment></comment><comment><USER16> So how does an apology make anything better?

<comment><USER17> It's a classic result in psychology that people who suffer from what can be attributed to human error feel better after whomever they deem the culprit apologises in a was they deem sincere. More practical examples include studies noticing that patients tend to sue less after surgeons (personally) apologised for negative outcome of surgery.

Expressing sympathy (which is generally considered distinct) also has an impact, although that can be less surprising.

Explanations generally consider the preference for a consistent world-view — think "We now all agree it was Brad's fault, let's now move on" above scape- goating.

In this case, an apology would mean: users were not wrong to trust a well- known app with their personal information, security professionals who warned the company about the breach were not wrong to follow white-hat protocol; the company should have acted on it. It's not clear in this case that 'sorry' is an apology, as much as a show of sympathy. As I wrote in a previous comment, I haven't seen a single user complain about negative effect (or read much on teenager-oriented platforms) so I doubt the sympathy actually is towards typical users; on the other hand, the head-wrangling on Hackers News, and late apology, seem to point at a real concern among security professionals who see standard lowered. I would assume the largest issue is to have the indifferent callousness of Snapchat management contaminate the tech industry, and its perception by the main public; I would actually relate that to the lack of outrage at Snowden's revelation, and a couple more recent news on privacy: "Our personal information is violated, stolen? Whatever…" Snapchat would make 'Silicon Valley' part of that line. Admitting that this is unacceptable would help regain the general perception that personal information needs to be handled with care, generally is and that large brands can be trusted to protect it (be it from black-hats or unwarranted government officials) — yet again, I'm not sure we can read this in SnapChat's message.</comment></comment>