fullwedgewhale

Not being BSD license I would expect it never to get beyond the ports tree.

I think that argument is only correct if you have fairly well understood pieces of work. I'm going to build an another on-line social recipe app. People type in recipes, they share those recipes, make comments on those recipes, maybe review the recipes, etc. I think their metrics break down very quickly when you start doing more interesting things like, taking automatically finding similar recipes based on the descriptions of the steps in the recipes. Or maybe performing a recommendation of recipes based on a user's rating of recipes.

Or, for that matter, correctly internationalizing the recipes and conversion of measurement units. (You don't want to have add 3.43272 cups of flour to 0.2347 gallons of water, when translating metric to imperial - you'll need logic to scale up/down quantities and round within a given tolerance - which is often narrow when you start baking pastries). Or there might be a service for this specific example that I'm not aware of, but the point is when you go beyond a very narrow scope, I believe this tool breaks down.

I view it as dangerous because it spits out a definitive answer without clear explanation of the model used to generate the estimate. If you look at other cost estimation tools (even closed source tools) will explain the model and assumptions used to generate the estimate. You can then make the determination if the model and assumptions apply to you.

It also doesn't indicate the kind of application (which is probably a largely stand-alone application). You can't stop some clients from going on to these sites and looking up a cost and not understanding what goes into an estimate. What would be even worse, in my mind, is to have other developers use a tool like this to generate a cost and then fail because they grossly underestimate complexity.

So having done cost estimation before, this is horrible. About all it would be good for is the initial swag at brochure ware. Generally speaking cost estimates should never be a fixed point and should be done in a range, with assumptions (that when violated) would allow the cost numbers to change. In addition, there's no measurement of complexity through requirements. Basically all these estimators are useful for only the simplest software projects with extremely limited requirements and scope. The cost of the software is a function of the known requirements which are carefully enumerated during costing to generate some sort of complexity model. (For example, function point analysis). That's fed into a cost model that translates that complexity model into a dollar range. That interval is then used to generate a final, contractual, number. But notice all the work that went into that estimate. What's more is that the estimate is refined during the work such that new data is incorporated into the complexity model, allowing changes in scope or requirements to be re-priced.

But what if it's 200% bigger? I remember reading an article that looked at the time it takes to load MS office under Windows. Even though computers over the last 15-20 years or so are much, much faster, the wall-clock time to get Word or Excel up and running has pretty much stayed constant. Granted, disks haven't kept pace with CPUs, but when your computer is 100 times faster and it still takes just as long... Is that a good trade off?

That may be true in Node, but as a counter example, in Ruby, I saw dependencies creep into projects where there would be some minor point like "I need to do X" and that's done by library Y. In addition, Gem Y does A, B, C and D. In order to do all that it drags in several dependencies which are not directly needed. When you actually look at X, you realize it's not that difficult to do yourself. So at what point should you just write the functionality yourself and at what point do you rely on external libraries (and any baggage they can bring with them.) You have to maintain that code (even if it is fairly trivial), but you then have to maintain your dependency (keeping the gem up to date, maybe making small code changes to accommodate breaking changes in the gem). It can be a real mess.

One thing that strikes me is the explosion in dependencies in most software. I'm guilty of this, too. I've seen plenty of examples where an entire library or framework is added to a project just for a couple of features. Add a few libraries like that and suddenly you have a few megabytes of additional libraries, where maybe 90% or 95% of the features will never be used. A good article a while back looked at common unix utilities, comparing the size of commands like cp from the 1980's to the present. Most of the bloat had to do with features that almost nobody ever uses. It wouldn't be so bad if everyone used the same set of libraries. For example, almost all applications have a dependency on certain core libraries like libc.

But we often use different libraries that do essentially the same thing or different versions of the same library, so instead of 1 copy of libfoo.jar, I have 2 copies of libbar.jar and 4 copies of libfoo.jar that may all do essentially the same thing. Then I have essentially the same functionality in C++ (some libraries that wrap collections), Python (where maybe one of they python versions wraps one of the C++ libraries, but a different version). And of course I have a version installed in each ruby environment. Add to that their dependencies, and the dependency's dependencies, and you have a perfect storm of craptastic. So libfoo.jar version 1.2.3 depends on libbaz.jar 2.3.4 which depends on libqux 1.5.7. Let's say each one is 250k, and all I ever used was some list sorting utility in libfoo.

But I don't know what we could really do about it. You can't force everyone to program in C++ or limit them to a set of blessed libraries. I think maybe developers could be more judicious about when they could add a few lines of code and when they actually need to bring in a hard dependency an an external library. And it happens with commercial software as well. Maybe this is just the way the world will be.

But not all over the world. In some countries, even in Europe, you can be a physician and do 'okay,' but being a computer programmer would be better.

I think top talent competes globally so it's able to either move to where it makes more money or demand higher rates. It's the anonymous guy in the cube whose skills may range from incompetence to excellent, but you don't know what you're getting at first.

I think one difference that I've seen is that the US has a very different attitude toward computer programming. In the US it's more glamorous? That's not the right word, but it seems like when I talk to a number of foreign developers who emigrated to the US, it's more about being a good job than it is about being a genius hacker, rich by 25, or being a technical tour de force. I see a lot more women overseas who become programmers. Maybe because the culture is different, and becoming a programmer is like becoming an architect or engineer?

I think that different culture might self-select US developers the same way top schools produce highly motivated, successful people because they recruit highly motivated, successful kids. Not to say every US developer wants to climb to the top of some technical or economic mountain, but it seems like maybe there's a smudge more passion among US developers. Also, intelligent, math oriented individuals have other avenues in the US, like finance, (and unlike the rest of the world) dentistry and medicine are lucrative careers. Meaning you choose programming more because you want to program, but in other countries it's because it's a better paying job.

I've also noticed that in some countries, once you've done a few years writing code, you quickly want to join management ranks and develop a coding allergy. More so than in the US, where it seems like 50 year old developers still want to write code. I get the sense that, in some countries, if you don't get into management then you are a failure at some level. So in the US you can find someone with 10+ years experience developing software, but in other countries you just have people who've stagnated and never moved up.

I dunno.

Excellent suggestion. I highly second that. Yes, even though more and more vendors are making that harder. For example, claiming that reinstalling the OS voids your warranty.

Google puts out free or cheap services and devices because they're trying to draw users to their platform, which gathers metrics about usage. These feed into the services, but they also feed in to Google's need to be a better advertising platform. Although we think of Google as the company behind the eponymous search engine and Android phone, it's actually an advertiser. I'm not sure if it's still in the 95% range, but it's still high. I have a 7" Nexus tablet which (for the time) was a great tablet at an insanely good price. But I knew I was essentially giving up information about what I read, what I listen to, and what apps I used in exchange for the free services and discounted device.

In contrast my Apple devices aren't cheap, and there is less collection of data with the intent of selling my attention to third party advertising clients, but they are more expensive and I pay an iCloud subscription fee. For the most part the Mac software doesn't suck and works reasonably well. I don't love everything about it but it's more appealing than Picasa for photos. I do pay for extra storage on Google to back up my pictures (over 100 gigs of family photos). But I am definitely paying more Apple in a direct sense (buying computers and phones + iCloud) than to Google (Google Play and 1 device). Apple's margin on hardware is high, but they make a quality product (for the most part).

What I give Google is information about myself, my work, my family, the music I listen to, the books I read, and anything and everything I ever searched for. They're pretty open and transparent about this, and I pretty much understand what I'm turning over in exchange for their free stuff. See the Google dashboard on you. If there's an application or service hosted by Google, I pretty much understand their intent is to extract data from that service or application.

That works for most people, even though they really don't understand this exchange or think about it. Free is a powerful lure and most consumers have come to expect not to pay anything at all for software and services. That's why they download a free game and keep playing it even when they find out it sends the contents of their address book off to some weird holding company. It's also why they get suckered into free games (because 4.99 is just too expensive on an App store) and then spend multiples of that amount in in-game purchases. It's why they're willing to turn over even extremely intimate details of their life for free e-mail or messaging services.

But the incentive for Google is not to make great software or hardware because that's how they make their money. Their incentive is to roll out services which help them collect information to feed their need for information about your tastes and behaviors. If that photo app you're using doesn't really give them more information, there's no incentive to make it better. Apple has an incentive to make software good enough to support their device/computer sales. Microsoft (arguably) has an incentive to make software good enough for manufacturers to license it. Apple and Microsoft, no matter how much people love to shit on them, actually have more straight forward, simple motives. They have an actual financial incentive to care about the quality of the product they deliver because you are paying them (directly or indirectly).

tl;dr Google only makes software good enough to draw you in to collect data. Other vendors are selling yous something and therefore have an interest in making that thing better.

I have to think one major issue for a German startup (for example) would be that their ideas might not work in France because of French laws which might prohibit some feature of that German service. So, the Market for a French firm is (at least initially) France. That's significantly smaller than the US. Coupled with the fact if feels like most US managers look at a laptop as a basic tool while many European managers seem to regard it as a tool for their subordinates.

The problem I have with the talk is that he's focusing on one narrow part of the economy and then using that as a proxy for the whole economy. It's also obvious he doesn't look at some of the negatives related to income inequality. For example, high levels of income inequality correlate with high levels of political instability and high levels of corruption. Countries with high income inequality are rarely gleaming examples of economic efficiency. They're often not very nice places to live. Countries with low levels of inequality (like much of Northern Europe) are nice places to live.

As Paul understands that we're all connected (you can't pull on one part of the bed-sheet with out pulling on the rest of the bed-sheet), he hasn't made the connection that if one side of the bed is dragged into being a shit-hole, the rest of the bed will eventually be a shit-hole, as it's all connected. In South America, for example, kidnapping is such a huge problem. The effect is to make these places less nice for the wealthy as well as the poor.

A lot of times the policies that reduce inequality aren't kill all the start-ups/crazy take all the money from rich people policies. Often their simple things that don't take a ton of money like head start funding, lower the cost of post-secondary education and training, and providing certain basic services like health care. What the US has done is to look at balancing the budget by reducing taxes on the very wealthy (upward pressure on income inequality) while taking money from programs that reduce equality.

There's a belief that most people who are poor are not working. Actually, many of them work quite hard. But washing machines work hard, too. Simply working hard doesn't get you ahead. In some cases there's a fair amount of luck involved. I sometimes look at the startup economy a little bit like pulling the slot lever. You can do everything right, but a lot of things still have to go well (some of which are outside of your control) before you cash out. Paul rightfully calls this risk, meaning that it's not guaranteed that an investor will get his pay out and it's far from guaranteed a founder will get rich. But it's bizarre to think keeping the US from sliding into an economic hell-hole will somehow destroy that slot-machine economy.