skysight-inc/HackerNews huggingface dataset:
What he said, apart from a few differences that I've found works for me (YMMV):

1. Do ENOUGH design and requirement gathering up front. Talk to stakeholders and users. Play around with any unfamiliar technology that you're required to use. In short, get your bearings before you start estimating.

2. Extract tasks that must be done. Each task should take less than a day or two to complete - larger tasks than this are often "lumps" of work which are harder to estimate accurately. Divide as needed. Don't forget testing, bugfixing, "polish" and all that jazz!

3. Estimate each task in IDEAL hours. Ie. "how many hours would this take if I could focus 100%, no interruptions, closed office?" Another approach is to estimate entirely using relative units - go google the "Poker Planning Game".

4. Add up total ideal hours. Then multiply by a risk factor. (My absolute minimum is 20% - that's if I have a complete lock on both the technology, the requirements and ALL other significant project factors.)

5. Figure out how many IDEAL hours you actually get done each week. How much effective time do you have left when you subtract meetings, interruptions, lunch, motivation lapses, etc etc? Divide the hour number from step 4 by these actual hours accomplished each week.

6. Now you know roughly how many weeks the project will take. Then take into consideration miscelleaneous external constraints. Will Joe Developer be there week one or is he tied up? Will Sue Tester go for a three week holiday to Hawaii at some point? Tweak the schedule further based on such known specific "X factors".

7. By this point you have a rough idea of when you will be done... in an ideal world. :)

Note: This is what I do for small projects or single iterations/increments in larger projects, ie 1-3 months for a few developers. Larger processes / project scopes = different techniques. Go google Agile/Scrum/other modern development methodologies. :)
French Internet piracy law defeated in parliament
Please don't use "M$"
> 150 odd million times (notwithstanding how god-awful it is!)

That's the funny part of it, people didn't want to listen to it in the first place. It's strange he didn't thrive on it and kill the meme like Hasselhoff did. Wait a minute...
I think it's a key insight that we can incrementally improve the law, but a credit-card bucket system must be fully implemented before anyone uses it. We can and do use this feature of the US legal system on a near daily basis to make meaningful improvements over time.

However, I think this point is significant: "People will die. It's a certainty. Some people are going to die as a direct consequence of legalization of marijuana." It's okay to release a crappy messaging website and iterate it into goodness, but it's irresponsible to do the same with medical software. In the same way, when people's lives are at stake, we have a responsibility to produce good laws from the start, so even if we don't get it perfectly right immediately, all of the complicated details that Steve brings up have to be thought through, or else there could be major negative consequences during the stabilization period.
I think the doubling comes from the fact that initial estimates are always that it would take x weeks if you were to work flat out 100% of the time. As this is incredibly unlikely to happen, you have to increase the estimate to take into account "overheads" (such as posting here...).
I like your "double until it's silly then go back a step" idea; it seems like a good way to get quick estimates.

I try to take into account how accurate my estimates will be: if a sub-task is something I've done alot, I stick with my estimate; if it's something where I think there's a risk of it going wrong I add more time (keeping a note of the estimate and the risk time separately - it makes project managers think you know what you're doing!). I then add them all up, divide by 0.7 (roughly how efficiently I convert booked hours into directly worked hours - the rest is email and meetings etc.). Also, any task where you have to write code that works with someone else's code, I double the estimate.
XMPP & AMQP in Ruby
"their products are no longer required" is a bold statement to say about a company pulling billions in profits. Ditto for "Nobody uses it anymore and nobody cares"
Strange, I fall on the lower quartile of the scale here. That said, I live in Florida where taxes are low and cost of living is low as well (not near what it is in SF). I charge based on what sort of work and who/what the work is for. If the client is exceptionally patient, straightforward, and easy to work with then their rate is lower. If the work is a royal pain, I'll ask for more. I guess the difference is that I don't do what I do primarily for the money, but rather because I just enjoy it. My day job takes care of the bills as it is.

If I went 100% freelance consulting I'd probably charge between 50 and 75, as that appears to be a sweet spot at the moment. Maybe higher as demand increased.
In earlier performance reviews, I was always called to task for my reluctance to commit to a number of hours for a task. Nowadays, I give better numbers and hedge my numbers by asking for multiple tasks at once (so I can triage and switch among them as needed, simmer and return). I don't like it when developers are micro-managed (and my managers understand that - e.g. they know I'll get it done and know they can't dictate it).

In my most recent 1.0 release with was done with Scrum and Sprints, what we observed happening was that overallocated time (tasks that did not need 6 days but took 2 days) was reallocated to tasks that needed much more time (10 days instead of 5 days). We were fortunate to usually meet our backlog for the Sprint (sometimes, more complicated tasks carried over) - but in practice, it seems that we had a fixed amount of time and the time estimates merely did a initial slice-up (which was not accurate). We hit the (pushed by 3 months) release deadline - however there was a fair amount of overtime.

So, if I had a lesson - the moral of the story is - time estimates are nice but being all-in and committed to getting a product out the door is more important.
If you really want to do the right thing, change "X is not yet participating" to "Get Satisfaction has no affiliation with X". The second one is the truth. The first one might have truth to it, but makes it sound like X is avoiding the forum - like they have something to hide.

I know that your business plan is based on getting companies to pay you to become their support system, but it would be nice if you didn't try to shape your words to pressure them in that direction. You have no connection to the company. You are unofficial. That's the truth. It's a small change, but a very meaningful one. No one likes the implication that they're avoiding something.

Get Satisfaction is not yet responding to this criticism. ;-) Yeah, it feels pretty crappy. For all I know, you haven't even read this or know it exists! Yet, I'm implying that you're just ignoring it because you don't want to be open. It might not sound like a big deal, but it's a huge change in how people see the companies represented on your site. If you really want to be a good steward, don't be playful with your words - be honest. I'm not saying you're intentionally doing this, just that if you want companies to take you seriously and trust you as a support mechanism, saying that you're unofficial will get them on your side more than saying they aren't participating.
YouTube predicted to lose $470M this year
Could someone shed some light on the "domain authority" piece? Any clue as to how this is determined, speaking qualitatively or quantitatively?

The part about 'links as votes' being less important explains why Stormpulse.com has a higher PageRank than wunderground.com, even though we only have about 35,000 inbound links whereas wunderground has over 12 million.
Is Windoze still ok? Internet Exploder?
iPhone apps are a media sensation for sure, but the real money is more in social network apps. The top Facebook app makes every month what the top iPhone app has made in total.
Coding Horror: Sex, Lies, and Software Development
> "their products are no longer required" is a bold statement to say about a company pulling billions in profits.

No, it isn't. Toyota's products are not required, since they have many competitors for each. That doesn't mean that they can't make money, only that they're not a(n effective) monopoly.
In my experience the biggest barrier to dealing with huge data volumes isn't the cost of supercomputer time. - it's the time it takes to

(a) curate and prepare the data

(b) develop a model to analyze it, adapt the model to whatever platform I'm working with e.g. hadoop, MPI

(c) get the results into a presentable form.

Compared to the hours of labor involved in these three activities supercomputer time isn't really that expensive. It can be leased if you know where to look.
"Actually, no; the PRS is authorized to negotiate mechanical rights rates on the artists' behalf"

As far as I was aware, becoming a member of the PRS was not mandatory, nor is the PRS required to license its music to Google. If the PRS is not satisfied with the deal Google is offering, then they have the option to walk away.
> compared this treatment to the "exploitation" of migrant workers in the Middle East.

Oh, how so? Were you at risk of death or physical injury? Were you living in disgusting, slave-like conditions? Were you working 14+ hour days and barely getting enough money to survive?
I don't think anyone would claim that a trust fund is a disadvantage. But if the people you know are really smart, ambitious, and resourceful, then give them time. They're still just in process.
So make a crappy version 1 and then iterate.
My only experience with Clojure is reveiwing Stuart Halloway's books on it, so this is certainly not the most qualified opinion you'll get, but as others have mentioned, tail-call optimization (lack thereof in the JVM, that is) significantly affected the language. It's not possible on the JVM, so Clojure relies heavily on the 'recur' keyword, so that recursive code can be translated into non-recursive bytecode.

Another language feature that could be ignored is the trampoline, which is made easy with the #(foo 'bar %1) notation, but can be ignored if you're not worrying about the JVM.

Aside from that, I would be very interested in seeing a Parrot Scheme based on ideas from Arc and Clojure both.
it sounds like what you are saying is the first estimate is the optimist in us, and until it seems 'funny' that it should take so long, you are giving it a test against the pessimist in you. as entrepreneurs, and creators we probably always 'believe' that something is doable, hence the optimism.
it "should score 0 for gutter game" do
20.times { @bowling.hit(0) }
@bowling.score.should == 0
end

Wow, Ruby/RSpec really sucks.

And by sucks I mean "reads like a natural language and rules".
> If you put an app in the app store, you've got a contract with Apple explicitly stating how you share revenue.

The PRS and YouTube have an agreement that explicitly states how revenue is shared. So no difference there, your contention notwithstanding. The real difference arises in that a) YouTube gets its money from advertisers rather from the consumers directly (which, IMHO, won't work, in general, in the long run) and b) the amount that the PRS receives is paltry.

> I can't complain about revenues from the app store if the game I wrote is being pirated outside of Apple's control.

Where did I mention the game being pirated? You say that I'm comparing apples to oranges, and as proof, you just made up what I said -- excellent work!
The ability to tell how you are logging in and request lost login information.

For example, I think I used OpenID to log in, but I might have used Google instead. I don't know which. I tried to log in from home, and I got the cryptic "Bad OpenID error". I don't know if this meant OpenID was down at the time, or that I was using the wrong provider. There was no way to request an email with my login credentials, not even to my already entered email address.

Even from my work machine, where it remembers I am logged in, I cannot tell if I have a real account or if I have used one of the many OpenID providers. So I still don't know if I'll be able to log in when I get home.
Go get

http://www.microsoft.com/learning/en/us/books/2425.aspx

I would even call this book a survival guide.
Maybe "de-clawed"? They're not quite DEAD yet. I think I'll go for a walk...
Scalability lessons learned from YouTube, Flickr, Google
Not All Banks Are Failing
Microsoft has a pretty solid monopoly in the institutional space through sheer inertia. It would take monumental will power to switch away from MS Office, let alone Windows. Startups: "Yeah fuck Microsoft, who needs em." 10,000+ employee gov't agency: "Microsoft = Computer."
1) make an estimate

2) triple it
People misunderstood PG's essay because he misstated his thesis. "Dead", put simply, was the wrong word to use.

Microsoft is not "dead" any more than Apple was dead in the mid to late nineties (and boy, was that a popular statement at the time).

Microsoft still has cash, people, and a position in the industry that, with the right leadership, can be turned around to be competitive with Google, Amazon and Apple.

Please back up all prognostications with evidence, or submit yourself to wrongtomorrow.com :)
I've never agreed with this PG essay. Granted its a couple of years old, but I think its totally off-base.

Specifically:

"Gmail also showed how much you could do with web-based software, if you took advantage of what later came to be called "Ajax." And that was the second cause of Microsoft's death: everyone can see the desktop is over. It now seems inevitable that applications will live on the web - not just email, but everything, right up to Photoshop. Even Microsoft sees that now."

I couldn't possibly disagree with this more. The idea of being forced to use all software through a browser sounds bloody awful to me. Photoshop through a browser? DO NOT WANT.

What we're more likely to see is cloud-based apps, which deliver the portability and connectivity we've come to expect from web apps. I can absolutely see myself using a cloud based version of Photoshop, but it would still be "desktop" software. Not surprisingly MS is heavily invested in the virtualization and server markets.

Surprisingly, I think PG forgot this basic point: products succeed because people want them, not because of their underlying technology. Gmail became popular not because it employed AJAX or was based online, but because it solved a hair-on-fire problem: tiny inbox sizes.

"The third cause of Microsoft's death was broadband Internet. Anyone who cares can have fast Internet access now. And the bigger the pipe to the server, the less you need the desktop."

This statement I also find ridiculous. If anything, increased broadband availability has made computers even more of a must-have product. And I've seen absolutely nothing to back up a claim that of these new computers less of them are running Windows.

"The last nail in the coffin came, of all places, from Apple. Thanks to OS X, Apple has come back from the dead in a way that is extremely rare in technology. [2] Their victory is so complete that I'm now surprised when I come across a computer running Windows."

Dude, come on. Yes, Apple made an amazing comeback. No, they haven't had anything close to a "complete victory."

Now, I say this as someone who makes custom web apps for small businesses, and someone whose father had an app completely ripped off and suffocated by MS circa 2000. A big part of me wants this to be true, but I know it isn't.

In conclusion:

The revolution in web apps was making them behave more like desktop apps. So why is it surprising to see desktop apps enjoy a renaissance by acting more like web apps?
XNA + Farseer Physics + MT = WIN [video]
> if you know where to look.

Wasn't that the point of the article? Supercomputing is now accessible to "the people" so part of the problem is close to being solved.
I've noticed in myself and other programmers an unconscious assumption that serious errors have serious symptoms. E.g. we must have fixed all the serious defects by now, because there's nothing obviously wrong with the code.

I've seen this proved wrong time and time again. Have you ever been maintaining some shipped code, and found a crash bug, where you're like: "I can't believe this shipped and we haven't heard about it."

So, I'm probably treating this out-of-context comment more seriously than it deserves, but I like to emphasize the point. Even though there is a set of errors that are detectable from the shape of the source code, there is a much larger set of serious errors that are not.
While it could have been better phrased, he is correct that the "Effective Emacs" post is old and well-known. It's been mentioned dozens of times on HN -- so it's a little surprising that no one had yet submitted the link.

http://www.google.com/search?hl=en&q=yegge+emacs+site%3A...
Effectively this means that there is no such thing as right and wrong and what we are left with is shallow consensus (as opposed to a reasoned consensus) at best, and application of force at worst.

I think that society defines morality - society defines what is wrong and what is right, and its criteria is fuzzy and shallow and unreasoned, and fluctuates over time. Since society is an aggregation of individuals, a society's definition of right and wrong is an aggregation of it's members definition of right and wrong (sometimes enforced by law.)

Slavery becomes right, because I'm a sociopath with a gun.

That's effectively what happened in the 18th century in Europe - it wasn't considered a problem then, but it is now because people's (and therefore society's) outlook on slavery has changed.

I don't think that the fact that society decides what is right and wrong is right (as in, it doesn't square with my own personal definition of what is morally right), but I can't think of more accurate definition that is also practical (and practicable.)
8. Realize that your estimate is ridiculously huge and anyone who sees it will think you're screwing with them.

9. Rationalize cutting it down.

10. Kick yourself as you struggle to meet impossible deadlines.
I second the idea that the RSS needs a way to be more filtered to the quality articles.

Also, having something more than just a title and link in the RSS feed would be nice, but I suppose that you don't really have summaries anywhere yet anyway.

Perhaps you could include the points in the title of the RSS feed entry? Google Reader seems to allow RSS feeds to update already sent articles, I dunno if other RSS readers support that well though.
>> "Photoshop through a browser? DO NOT WANT."

What you seem to fail to see is that you're an outlier.

Most people want photoshop through a browser. Most people already do most of their stuff through a browser. It's funny to even debate, because it's happening/happened for large amounts of people out there already. Ask your parents what they do on the computer, and it's likely to be 90%+ web, with perhaps a couple of desktop apps. If that.

Ironically, it's the techie usually early adopters that are lagging here, preferring to stick with desktop software. The people leading the webapp charge are people who don't want the fuss of downloading desktop software, with potential spyware etc, and just go to google and find a webapp instead.

The same phenomenon exists when some people discuss advertising. "No one clicks on ads anymore" - it's easy to say, if you install adblock, or just don't click on ads, but this is a total minority. The majority do click on ads. Just like the majority want, and use webapps over desktop apps.

>> "Gmail became popular not because it employed AJAX or was based online, but because it solved a hair-on-fire problem: tiny inbox sizes."

I think actually the reason it succeeded was because it had ridiculously fast searching, and unlike a desktop app, you don't have to worry about your storage. I don't think the majority of people really cared about inbox size. The fact you could easily search for things in a simple and blazingly fast webapp was key. For most people, it is better than a desktop app.

>> "This statement I also find ridiculous. If anything, increased broadband availability has made computers even more of a must-have product."

The fact that broadband access has increased etc means there's less need to have a thick client. Where previously you needed to download a video, click on it, watch it, we all now just watch videos streamed to us by a webapp.
When we all have 1Gbps connections, why would we need a full powerful computer each? Why would it not be in most persons better interest to just have a very thin power conserving client that connects up to the big servers doing the grunt work.

The fact is, it's happening, and will continue to happen. You can't stop it. It's inevitable. You might prefer to stick with your computer and desktop apps, but you'll be a small minority, like the people who still buy records on vinyl.

>> "The revolution in web apps was making them behave more like desktop apps."

I disagree with that. The revolution in webapps is making them work BETTER than desktop apps. Gmail can search my mail much faster than my computer can. Mibbit can do things impossible with desktop IRC clients. etc etc

The reason Microsoft are 'dead' is that they don't get it. They're dead in a similar sense to the music industry IMHO - the market changed around them and they completely failed to adapt.
This kind of specification and scenario-planning sounds like a job for a pro-legalization think-tank.

Be like the lobbyists. Write the legislation you want, with options and choices, then present law-makers with a menu. Basically, do their work for them, then get them to rubber-stamp it.
Aren't services like Sharepoint fundamentally inferior to "cloud computing" (for lack of a less buzzy phrase)? I've heard this for almost a decade, but isn't it about time people see local e-mail hosting like running your own generators instead of "trusting" an electric company for your electricity?
On the credit card question, these already exist - they're called Corporate Purchasing Cards. The reason credit card companies don't do buckets is, as Steve alluded, the merchant data isn't granular enough and in order to place restrictions on what cardholders can buy you have to know the bucket type of every item that merchants sell. That's a huge problem which even the best Corporate Card companies have trouble solving. American Express is #1 in terms of data but the cardholder often still needs to explain which bucket the purchase goes into. (One reason you need a special POS cardreader for Amex is to inform the Purchasing Card transactions which bucket to use.)
Checking disk space
Here's a script for quickly checking on how much disk space you have on a system and how much of it is in use. It certainly beats using a calculator to tally up the columns in "df -k" output.
Funny how people who write articles are what makes a good on their programming blogs often include "writes a programming blog" as one of the attributes a good candidate should have...

Hmmm, maybe my comment should read as: "it doesn't perfectly describe me in every way, hence it's a terrible list" ;) I'm getting too many 2's damnit!
You aren't alone. If I had access to the book for my Project Management class, then I could give you exact stats for how terrible most estimates prove to be. The numbers are astounding (the studies are dated, but still adequately horrifying).

Even doubling your estimates is unlikely to have any real reflection on reality.

One standard methodology is called three-point estimation:
http://en.wikipedia.org/wiki/Three-point_estimation

How far do you want to go though? You could look up COCOMO-II, I saw someone mention function-point analysis, then you could do monte carlo simulation...

The best way is to compare the task to previous similar tasks, but the trick is making sure that tasks are really similar enough to make an accurate comparison.