akeefer

The idea that there won't be any money left is a common misperception, but it's pretty inaccurate. Since it's a pay-as-you-go system, it can't run out of money like a bank account. Instead, it will simply be taking in less than it should be paying out. The current best estimates are that Social Security will be paying out around 75% of what it should be paying out by the time that people in their 20's now retire. That's still a massive, gigantic problem, but it's a world different from there simply being no payout at all.

http://www.getrichslowly.org/blog/2010/09/01/yes-you-will-ge...

It's a little different than DLL hell: most applications provide their own libraries precisely to avoid DLL hell. Rather than relying on (or trying to install) some globally-shared DLL, they include their own versions of libraries, and it doesn't matter if those versions match the versions used by other applications. (As a developer you have to worry about dependency differences between libraries, but as an application installer/user you don't have to worry about it once the developer's got everything working and bundled up). The Linux distro guys are in some ways asking Java applications to go back to a world where DLL Hell is possible, which might be good for distro packagers but would be a disaster for developers.

Patents only cover certain types of creative behavior for which patent protection makes sense as a way to encourage innovation. For example, it's never been possible to patent the plot of a novel, and up until recently it wasn't possible to patent an abstract business process or method.

The argument, then, is that patents on software are A) unnecessary to encourage innovation and B) actively discourage innovation. The argument for A) is that plenty of software development happened prior to it being patentable, few software developers or startups consider patentability when creating new products, software itself is well covered by trade secret and copyright protection, and the patents themselves contribute basically nothing to the world's store of knowledge about software. The argument for B) is that most software patent suits are complete BS and are launched either by trolls or in an anti-competitive manner rather than as a result of any sort of actual "theft," any piece of software could potentially infringe on hundreds of patents, patents themselves tend to cover "inventions" that anyone else solving a similar problem would come up with, and that patents themselves thus tend to either discourage people from even trying new ventures, out of fear of being sued, or serve to drain resources from companies that actually produce products, tying up resources that could actually be used for innovation. It's also worth noting that the 17/20 year term of a software patent is completely out of whack with the pace of innovation in software.

So you can try to split hairs around saying that some software patents (say those around non-obvious compression schemes) are legitimate, but I'd guess that something close to 99.95% of software patents are trivial/silly/should never have been granted, so in this case I'd argue that's totally worth throwing out that 0.05% of "good" patents in order to ensure that we get rid of the other 99.95% of them. I'd rather see that happen than try to defend that 0.05% and end up keeping even 5% of the current amount of BS patents.

The point was less the absolute number and more the historical comparison; taxes on upper income brackets are nearer the lower end of post WW2 historical norms than the higher end, but from hearing people complain about it you'd think that taxes right now were close to historical highs.

I think the article's original point (and mine as well) was that considering the size of the code (i.e. the DNA) as a measure of the complexity of the task is totally disingenuous when you don't have (to use your analogy) the web server, the libraries you're calling, the parser/compiler/linker for the language, the operating system for the server along with its drivers/TCP stack/etc., the processor it runs on, the mother board, or the storage. In order to turn 10,000 lines of code into a web application, you need millions of lines of code (and Verilog or whathaveyou) in terms of infrastructure.

The problem for AI is not just encoding the DNA, as it were, it's in building all those other pieces around it. Estimating the complexity of building a software brain based on the amount of information in DNA is like estimating the complexity of building a web application using 1950's hardware. "It's only 10,000 lines of code! How hard can that be? All we have to do is write the code, plus the frameworks, programming language, and operating system, plus do all the hardware design."

The argument Myers is making is that while the DNA might be the input to the system, the total amount of data in the system is that input plus the rules around how that input is interpreted/works. Those rules (for example around protein folding) are currently encoded in biological systems as the laws of physics, more or less, but they're insanely complicated and currently unknown.

So the point is that perhaps if you had a system that simulated all of the laws of physics exactly correctly such that proteins folded and interacted exactly right, only then could you get away with an amount of input equivalent to the amount of information encoded in the part of our DNA related to the brain.

Actually encoding those rules is probably the harder part of the problem, and could easily take several orders of magnitude more work. (10x? 1,000,000x? Who even knows).

Keep in mind that taxes and such scale non-linearly with income: if you make $100k a year, you'll take home less than 2x what you'd take home making $50k a year. It doesn't invalidate your argument by any means, but it's something worth mentioning.

Very interesting study, if small.

My two questions about it. 1) What's the plateau state and the initial fitness level/muscle density? Many weight-lifters have experienced that after a certain point, they start to plateau and don't gain further muscle density. Is the plateau point roughly the same for the two styles? 2) How does that correlate to strength? It's been hypothesized (but I'm not sure if it's been proven) that strength is a combination of muscle density and motor coordination (i.e. neural connections to allow muscle fibers to fire simultaneously), and that lifting heavy actually leads to additional nerve ends that help coordinate those things (or something like that, at least). So I'd be interested to know how the different lifting programs affected both maximum lifts and the number of reps that can be performed at, say, 70% of that max.

Which part don't you buy? Do you think they're lying about their motivations, or do you not agree with their justifications?

They weren't promoting a tiered internet by advocating it as a good thing; they were against regulating things just yet. Those are two very, very different things.

You might disagree with it, but it's not illogical. There's a big, big difference between saying "I don't agree with Google" and "there's no possible logical reason for their position, therefore it must be evil." What you're expressing above is one possible interpretation of how the future could unfold, but different, intelligent people can easily disagree about that.

This is a pretty terrible article: the author basically mis-represents what actually happened, and then dismisses any possible legitimate motive for Google doing what it did with no argument, merely by asserting that such a motive can't possible exist.

Maybe, just maybe, Google thinks that massive government regulation of the still-nascent wireless internet market will do more harm than good at this point, and that we should consider the question later once we have actual empirical data about what works and what doesn't? Is that really such an illogical position to adopt?

Like most things in life, it depends. Just because it didn't work in your case doesn't mean it never works, that it's never a good idea, and that it's always a waste of time. For us, it's turned out to work really well, and we feel like the benefits outweigh the costs. Your mileage will vary.

For some reason, though, this is a subject on which many people feel qualified to make pronouncements about the wisdom of what other people are doing. I have, for example, had a candidate come in for an interview, look at the office layout, lecture me for 15 minutes about how we must be idiots because we're killing our productivity with our open layout, and then leave because he'd refuse to work in a place like that. At least it saved me the other 45 minutes I would have had to spend interviewing the guy.

I don't think it's as simple as saying, essentially, "people who forbid telecommuting are idiots" or "there's no legitimate reason why telecommuting should be difficult." There are legitimate reasons to co-locate a team.

We allow working remotely one or two days a week, but our experiments with full telecommuting have not gone so well (though we'll probably keep trying). The level of success probably depends pretty heavily on the type of product you're trying to build and the resulting level of communication that's required. For enterprise software (or perhaps I should say "domain-specific apps" or something), you really need a customer proxy/subject matter expert on hand that you're talking to on a fairly constant basis, because the developers themselves aren't really experts in the domain; as a result, you want your development setup optimized for high-bandwidth communication. When 10 people are onsite but 1 team member is offsite, that communication just doesn't happen, and that 1 person ends up out of the loop and much less productive (at least that's what's happened with us). For other types of software, that's less of an issue.

I think it's also much less of an issue if the entire company telecommutes, or if at least a large percentage do: in that case, communication channels are optimized for that. If 5% of the staff telecommutes, the communication channels are optimized for face-to-face communication, and the people telecommuting are left out.

And on top of that, there are just different ways to go about developing: they're not necessarily better or worse, but they make different demands on physical presence. A lot of agile/XP practices work best when people are co-located in small cross-functional teams that are in constant dialog, pair-programming, etc. That doesn't mean it's the only way to develop, but it can be an effective way to develop (more so for certain domains than for others), and it doesn't mesh very well with full-time telecommuting. Other development strategies and methodologies make different trade-offs and will be more accommodating of telecommuting.

I don't think we should change how we write code, either: I think we should change the patent system so this stuff doesn't happen. I get tired of hearing the "it's just big companies suing other big companies" argument about why patents aren't a problem. Software patents generally don't stifle innovation because people don't do something because they're worried about patents: they stifle innovation by diverting huge financial and mental resources to patent lawsuits (and patent filing) that could otherwise go to product development or something else useful, and occasionally by crippling companies that aren't large enough to defend themselves. It's just kind of tax on the industry as a whole where the net effect is to siphon money and energy away from important things and towards lawyers. You'd have approximately the same effect if you replaced the patent system with roving bands of feral lawyers that went around randomly destroying property and burning down offices. You wouldn't say, "Hmm, I don't think I'll write software because some lawyer might burn my house down," but dealing with all that destruction would drain resources from other areas, and sometimes it would be too much for a company to overcome.

I can't really get into any specifics of the litigation because it's still ongoing.

Just wait a few years. As you say, it's a waste of money to sue someone who's not a threat. Once one of those companies becomes a threat to someone with deep pockets (and some of them will), there's a fairly high likelihood that someone will sue them.

I agree, but what's the chance that we'll ever get a non-broken implementation? If someone really tries to fix it, that would be great, but what are the odds it'll really be fixed instead of just being broken in different ways? From my perspective, ExpectedChanceOfBrokenness * ExpectedCostOfBrokenness > ExpectedCostOfKillingThem . . . so the probabilistically optimal course is to just kill patents for software (and business methods), even if it's not the absolutely optimal course.

For what it's worth, it's happened to my company (a smaller company sued by a larger competitor), and the litigation has dragged on for almost three years now without going to trial.

I've heard of other similar incidents as well. They're far more likely if you're going into an existing market against well-funded (and shameless) incumbents than it is if you're in a nice market.

You're correct that the rational response is to not worry about it, simply because there's nothing you can do about it as a software startup. If someone wants to sue you, they will, no matter how far you go out of your way to avoid violating patents. So you just kind of hope you don't get unlucky and get sued before the company becomes big enough to file their own patents for defensive purposes.

Just because something happens infrequently doesn't mean it's not a real problem.

One other thing to keep in mind in this debate is that it's expensive to defend yourself from a patent lawsuit. For example, this blog (http://rpxcorp.com/blog/?p=129), whose accuracy I have no idea of, claims that the average total cost of a patent lawsuit where the potential damages are under $25MM is $3.1MM to defend yourself, and $6.2MM if the potential damages are over that number.

So there are several parts to this equation. 1) Creating any bit of software involves thousands of "inventions," any one of which could be patentable. 2) Patents are granted for things which fail the obviousness test, where the chance of someone else independently "inventing" the same thing is essentially 100%. 3) The damages for violating even one patent tend to be astronomical and totally out of line with the contribution of that "invention" to the software in question. Out of 2 million lines of code, if one total BS patent covers 20 lines of that code, why are the damages likely to be basically equivalent to most of the revenue for that product? 4) The cost of defending against a patent lawsuit is enormous.

In other words: if you're a small software business, then there's pretty much a 100% chance someone else can sue you for patent infringement if they want to, losing the case will kill your company, and trying to defend yourself will severely drain your resources and could kill your company anyway.

There's no part of that that helps or encourages innovation.

Software patents affect small companies when they get sued by big companies or patent trolls. It happens all the time, and when it does there's basically no defense unless you have a huge patent portfolio and can countersue . . . which, if you're a small company or the other side is a patent troll, you can't do.

Yeah, I agree that it's a nightmare in production, but it's absolutely indispensable in development situations where you can tolerate the occasional weirdness or failure. If you're developing a server app (or a thick-client app), avoiding a sever restart every time you change anything is a huge, huge win. And again, it's not like it's not implementable: there's already an implementation, for the JVM, that works.

I tried at the conference to get people to agree that hotswap (i.e. reloading classes in a running system) was something that the JVM needed to add, so that the 99.9% of JVM users programming in Java can have a more dynamic programming experience. It really matters when it's there (especially for people that develop server software, which is a large part of the Java community), and there's a real, ingenious solution already implemented as part of the MLVM project that works well enough for me to use in development all-day every day.

When I brought it up during this discussion, I got nowhere, and people basically looked at me like I was an idiot. It was pretty disappointing to see that a room full of language guys just didn't care about anything that would improve Java itself; the discussion pretty much entirely focused around small-scale stuff that would make it easier to efficiently implement dynamic languages on the JVM.

One thing I think that this analysis misses is the fact that, for most people, you're not going to enjoy the flight no matter what. At that point most people shift from "maximize enjoyment" mode, where paying more for something better is more rational, to "minimize costs mode." If I'm going to spend 5 hours being uncomfortable whether I spend $300 or $500, what's the point in paying more?

I think there's a certain enjoyment threshold below which something becomes "unpleasant," and moving from one state below that threshold to another state also below that threshold isn't as valuable as a similar state shift would be if the initial state happened to be above that threshold.

A website is effectively private property. Suppose my house had a nice lawn, and I said to the neighborhood kids, "You're welcome to play on my lawn, just clean up after yourselves and don't hurt the flowers." Is that reasonable? How about if, instead of communicating that to them, I instead put up a sign to that effect? Is it cool if the kids play on my lawn and mess up my flower bed because they don't like those terms and couldn't negotiate them? Of course not: I've laid out the rules for their usage of my private property, and if they don't like the rules they can do something else with their time.

I'm not saying a website should be able to sue you or file criminal complaints if you violate a TOS; I'm just saying that they do have the right to expect you to abide by them if you choose to use the site. They should be able to behave exactly as a restaurant does: kick you out if you violate them, and file criminal complaints only if you actually do something criminal (cause damage, steal stuff, abuse staff, etc.).

Whether or not a TOS is criminally enforceable is a long ways away from your argument, which I interpreted as essentially saying that breaking/ignoring a TOS isn't any sort of ethical violation because it's not a countersigned negotiated contract.

I don't think your argument holds up. Any service is offered under some terms; it's irrational and unreasonable to assume that when you use someone's website or service that there are no terms whatsoever attached to that service.

So where do those terms come from? Rationally, one might expect the website to spell out what they expect from you and under what conditions their services are provided. If you don't like those terms, don't use the service.

It seems like you're arguing that you should get to determine under what terms the services are offered, or perhaps alternatively that services offered should never have any terms attached whatsoever; both of those positions seem pretty indefensible to me.

Just because you don't get a chance to negotiate terms doesn't make them invalid. It's a take-it-or-leave it offer, and you always have the right to leave it. When a restaurant gives you a bill, do you pay less than the amount just because you didn't get to negotiate the price? Do you walk into a restaurant shirtless that explicitly asks you not to do that? Of course not: your ordering the item indicated your willingness to pay the associated charge, and likewise if you don't want to abide by their rules around appropriate dress, you just don't go in.

You don't get to make up your own rules and then apply them to someone else's services.

It's a different question if the TOS are deliberately obscured such that you don't actually know what you're agreeing to, but the argument that just because you can't negotiate the TOS they're somehow invalid and you're thus justified in still using the service in violation of them is absurd.

I did my undergraduate work in philosophy, and I honestly have found it really useful in CS. The ability to break down a complicated argument into small steps that are independently verifiable is very close to the ability required to break a complicated program or operation down into smaller components that are independently verifiable. In addition, philosophy improved the clarity and rigor of my thinking and writing on complicated subjects, and it made me better at presenting my arguments in an unbiased, rhetoric free way that helps get to the right answer, instead of just trying to convince people I'm right.

So while the actual content of philosophy classes is pretty much irrelevant to anything in real life, the process of philosophical thinking and writing (at least analytic philosophy) turns out to be very good training for CS and probably a fair number of other things.

Sigh . . .

I get that CPS doesn't always do the best job, and plenty of the people that work there are on a power trip and got into social work because they like telling other people what to do. The world would certainly be a better place if they were able to do their job better and if some of their officers were more courteous.

But as you probably know, working for CPS is an incredibly difficult job. It's very demanding on your time, it's immensely stressful emotionally, everyone hates you, and it can put you in physical danger (you often have to be accompanied by a police officer). Unsurprisingly, in many places they have trouble finding enough qualified applications to fill the necessary positions. I know that I sure as hell wouldn't want to do that job.

I guess I just get tired of the vitriol directed their direction as if the world would be a better place if CPS wasn't around, or as if they intentionally make life hard on people just because, or as if they're somehow more lenient on poor people. Your additional comment there is, in my experience, pretty wildly off-base: my wife is a social worker who works with plenty of poor clients who have had children taken away and never managed to get them back because they're unable to support them financially or have ongoing drug or alcohol problems. The kids are put in group or foster homes basically permanently, not sent back to their parents. And it's not like the "poor crackheads," as you so respectfully put it, don't care: they care just as much as anyone else does.

What I'd like to see is some more level-headed analysis of what the "false positive" or "false negative" rates are. For every family innocently harrassed, how many families are quickly cleared of any wrongdoing and how many children are removed from abusive situations? It makes a big difference if 60% of the claims CPS investigates result in putting an innocent family through hell or if 1% of the investigations do.

Again . . . would the world be better if CPS was able to do a better job? Sure. Would the world be a better place if we reverted back to treating children like property with no rights and allowing parents complete free rein over their children? No.

He's pointing out that the order of statements in the source code doesn't necessary correspond to the order of evaluation. In this case even though the function call is the last statement in the source code, it's actually an argument to the multiplication, and the multiplication is the last operation being executed. That's non-obvious when just looking at the code, since the function call looks like it's last.

Yeah, you definitely have a point there. While many problems have a high degree of inherent complexity, there are plenty of others that don't need to and that have features bolted on left and right to appeal to every possible market. And it's definitely true that big companies hate making these sorts of decisions, because it's expensive and time-consuming and difficult to undo.

One reason a lot of enterprise software gets bloated is that, in order for the market to be viable, it's hard to just target a single niche, so you end up with a superset of features so that you can sell the same market to customers with different requirements.

Even in the best case, though, system specialization can be a knife-edge that cuts both ways. Many of our customers, for example, are in a trouble precisely because they have way, way too many one-off systems. They have this system over here that does just workers comp claims, and another system for handling personal auto claims, and another system for tracking notes, and an entirely different system for first notice of less entry versus for actually handling claims, and then most of their commercial business is in yet another system, except for some specialty lines that are elsehwere. Then they have five different policy administration systems, and a couple of billing systems, and each of those talks to a different document production system . . . it's a total nightmare.

So sometimes the choice is between having 3 complex systems or 25 purpose-built systems and a total integration and user training nightmare, and both options suck.

Basically, as soon as you have a bunch of data that you need to do a ton of different things with, you're left with two bad choices: you can create one really complex application that tries to do everything, or you can create a bunch of smaller applications and end up with a bunch of complicated integrations. Fundamentally, as soon as you have complex data that you have to do a bunch of stuff with, you're going to be in trouble no matter what you do.

He's right that the buyers not being the users is an issue, but there's far more too it than that. There are a lot of good answers already here, but to add a few more (and consolidate some others):

1) The developers often aren't the users either, which instantly makes things far more difficult. My company builds insurance applications; it would be 10x easier (if not more) for me to write an e-mail application with a good user experience than for me to write a policy administration system with a good user experience because I'm not an agent or underwriter. With consumer software, development or collaboration tools, and a lot of small business software, the developer might actually have to/want to use their own stuff. For most enterprise software, that's rarely the case.

2) As has been pointed out already, a lot of enterprise software is complex. It's hard enough to get everything to work, let alone to have a really nice, slick UI. There are often endless numbers of non-optional corner cases to handle. If you're really unlucky, the process in question will be subject to lots of government regulations you have to abide by; if you're even unluckier, those regulations will vary by state (not to mention by country). It's hard to make something that complex user-friendly.

3) In addition to complication, there's the issue of surface area, which is somewhat orthogonal. It's much easier to polish a web application with 20 different screens that to polish one with 2000, no matter how simple those 2000 are; you often don't have the resources to devote huge amounts of attention to detail on an application with that kind of surface area.

4) Enterprises themselves are difficult to sell to. Extremely difficult. It's largely a self-inflicted wound, but it results in an increased barrier to entry in that market, which increases the cost of actually selling into that market, which leaves fewer resources for development (relatively speaking).

5) Enterprise systems often need to integrate to a bunch of other enterprise systems. Any way you spin that, it's difficult and time consuming to do that, which sucks up more resources.

6) Most enterprise solutions involve a lot of vendor lock-in. That's partially due to the storage of large amounts of highly critical data, partially due to general risk-aversion at most companies (since such changes, if they're botched, can be disastrous), and partially due to the integration work mentioned above. The cost of switching tends to be very, very high.

7) Everyone wants to be a unique snowflake. For core business processes many companies consider their process to be a competitive advantage; at the very least, it's a core part of their business. As a result, enterprise software often has to be customizable so it fits with what data the customer captures and how they do business. That dramatically ups the complexity factor and makes polishing things much harder.

8) Because of all those factors, enterprise markets have a high barrier to entry. The complexity of the products means that you need a decent amount of funding to even begin to enter the market, and the sales difficulties suck up more money and make it difficult to establish a consistent revenue stream. The relatively small market sizes combine with that to turn many of the markets into winner-takes-all sorts of games. As a result, you end up with two classes of companies: new entrants and incumbents. The new entrants don't have the resources to really polish their stuff; they're struggling to build stuff that's functionally complete, actually works, and to sell it without running out of money. They can't afford to chop their footprint in half in order to make sure it's really slick, or to spend twice as much on development. The incumbents, on the other hand, often have no incentive to not suck. They tend to have high levels of lock-in and they know their competitors have huge barriers to entry, so the competitive pressure to be good isn't there.

9) The most talented developers and designers often simply won't work on enterprise software. You're working on something you wouldn't use and have no personal connection to, and no one you know can use or see your work. At least in the valley, if you tell people you build enterprise software, people often react like they feel sorry for you, or like you're some sort of idiot-leper who simply isn't good enough to get a job building cool consumer stuff. Ask awesome developers if they want to work on a database, a social networking site, or a claims processing system, and I think we all know which option will come in third place.

10) Those are all reasons why commercial enterprise software written by software companies sucks. A lot of enterprise software, however, is written in-house. If a company that can amortize their costs across dozens or hundreds of customers has a hard time doing it, you can imagine what happens when one company attempts to build things themselves. They really don't have the resources or expertise to product anything thoroughly polished most of the time. And the hiring problem there is even worse: most good developers would rather work at a software shop than in the IT department of some massive company.