It's Time for Server-Side Browsers - <AUTHOR> http://camendesign.com/writing/headless_foxes

<comment><USER2> Could someone translate what this is actually trying to talk about into something clear? This blog post reminds me of someone on weed trying to relate to you this profound idea to you and rambles on stream of consciousness style. He wants there to be no 'centralization' (that is, servers) and have things run on a cloud of people's web browsers, yet at the same time it still talks to mysql somewhere? We won't need any one site to hold data and things just magically work by sending things out into the ether?

<comment><USER3> Presumably he/she envisions a Facebook/BitTorrent hybrid with content replicated across the social graph.

You'd get drafted into storing images for some subset of the intersection of your social graph and several others, and the rest of your images would be served by someone(s) with whom your social graph intersects.

Presumably invitations would be via e-mail, or, if you wanted to be even more decentralized, QR code.

<comment><USER4> ... Which assumes people keep their machines running 24/7 on unlimited data connections. It's a nice idea from a tech point of view, but for the life of me I cannot see how it's superior to what we already have.

<comment><USER3> Well, except some degree of redundancy would be built in to the storage scheme á la BitTorrent.

As far as data volume, I've got to imagine the data usage per user would be significantly less than BitTorrent.

The desirable aspect of this system is obvious - the only people who see your data are people who've seen a QR code from _someone_ in your social graph - your FaceTorrent profile will never, ever be indexed by Google.

<comment><USER5> > The desirable aspect of this system is obvious - the only people who see > your data are people who've seen a QR code from someone in your social graph > - your FaceTorrent profile will never, ever be indexed by Google.

What if Google started offering, say, free Google Coupons (assuming they roll their own groupon) in exchange for befriending them on FaceTorrent? Not all of my friends and relatives value privacy as much as I do.

</comment></comment></comment></comment></comment><comment><USER4> I'm left wondering wether the idea is server-side browsers or browser-side servers. Plus, what's the problem with having to deal with JS client-side and something else server-side? And as for this...

"I therefore cannot redistribute and decentralise the server-side parts without expecting the end user to understand how to configure and run a server"

You can. It's called a desktop app.

</comment><comment><USER6> This is not a layer 7 problem, its a layer 1 problem. Get your ISP to provide unfiltered nearly-synchronous connectivity with pervasive ipv6 (no-nat) and _then_ we can start getting rid of the client server model.

<comment><USER7> That's at least layer 2 (in the IP model) or layer 3 (in the OSI model). /nitpick

</comment></comment><comment><USER8> Time for "server-side browsers" came long time ago - check out headless web application testing frameworks (htmlunit, for example).

<comment><USER9> Another one is "Envjs": <http://www.envjs.com/>

Quote: "Envjs is a simulated browser environment written in javascript"

<comment><USER10> This discussion handles headless browsers: <http://news.ycombinator.com/item?id=2142104>

</comment></comment></comment><comment><USER11> I built a proof of concept that sort of does this:

<https://github.com/shazow/relay.js>

Someone hosts a hub which just acts as a dumb message-passing relay between browsers via websockets. When a server connects, it sets a code payload. Then when a client connects to the same hub and requests the server, it receives the code payload and a streaming 2-way connection to the server.

There's a few live examples like a collaborative whiteboard in about ~40 lines of js.

</comment><comment><USER12> Isn't it how mobile Opera works already?

<comment><USER13> It's how Opera Mini works (sort of) but not how Opera Mobile works.

<comment><USER14> Going by the title, yes, that's (sort of) how Opera Mini works, but going by what he wrote, no, not really. He seems to be talking about browsers as servers on the client side, not turning browsers into glorified image viewers.

</comment></comment></comment><comment><USER15> PhantomJS is quite nice -- headless javascript which leverages webkit for rendering.

<http://code.google.com/p/phantomjs/>

</comment><comment><USER16> Making browsers servers as well makes much more sense. At least allowing communication that is peer to peer. This would dramatically reduce network costs for the application owner.

There is a Proposal for peer to peer browser communication. See: [http://www.whatwg.org/specs/web-apps/current- work/multipage/...](http://www.whatwg.org/specs/web-apps/current- work/multipage/commands.html#peer-to-peer-connections)

</comment><comment><USER17> An interesting tangent to this discussion is OTOY (<http://www.otoy.com/>), where your browser simply functions as a display and input device; all the heavy lifting of 3D rendering and game logic is processed server-side.

</comment><comment><USER18> I believe this is what Aptana's Jaxer (<http://jaxer.org/>) tried to do. It didn't exactly take the world by storm...but perhaps it was too early...

</comment><comment><USER19> aka Browser as a Service -- This is something I tought about a few years ago. It's becoming a reality with Opera Mini & Skyfire. <http://virteal.com/UltraLightBrowser>

</comment><comment><USER20> It's much more powerful and smarter to make the clients into servers. Aka P2P.

</comment><comment><USER21> sorry, I believe this was done ages ago - the remote desktop, such as VNC.

<comment><USER22> Way before that — the X window system.

<comment><USER23> It's not seamless though, and that makes it a very different idea.

He's talking about it working at the same level as a browser where it sees if you have HTML5, and if not falls back to flash, dynamically.

I can't imagine it being a high priority - fiddly, low return, creates huge performance issues. Lots of basic problems - you don't want someone supplying input to a game over a (latent) network. You don't want to be running instances of performance-intensive games on your webserver.

Still - the proposed idea is distinct from VNC or X.

<comment><USER24> You can implement this (somewhat wastefully) using VirtualBox and VNC.

<comment><USER23> My point above is that there's a vast difference between (1) something being possible by a tech-savvy user spending time to jury-rig a solution, and doing it on a case-by-case basis and (2) the same kind of thing being done as a commodity - something that runs commonly on the platform with no effort on the part of end-users.

<comment><USER24> Maybe there's not as much difference as you might think. Look up Paul Farnell and Litmus. You can listen to his Mixergy interview from January.

</comment></comment></comment></comment></comment></comment><comment><USER25> high lvl nap talk

</comment><comment><USER26> Or we could stop treating the HTTP/browser combination as an application delivery platform.

It's unpopular here, but it's becoming exceptionally obvious as the correct choice.

<comment><USER27> The term "exceptionally obvious" might be over-stating the case a bit. Please could you expand on why you think that

<comment><USER26> _Please could you expand on why you think that_

In 1993, I was the only person I knew with a web browser. 18 years later, we have applied hack after hack to make it into an "application platform." And it's still the same old thing.. a way to deliver hypertext pages to people.

If you want to allow people to sync their files, share large popular binaries or listen to the perfect mix of music, you don't do it over HTTP. Not because you don't understand HTTP, but because you do.

<comment><USER27> It's possible that the reason the web's still "the same old thing" is because it has been proven an effective platform for distributing services and is, _in practice_, a system that's extremely scalable and evolvable. Infact, it's so successful there's nothing to compare it to - which means no value judgement or comparison is at all "obvious".

HTTP is also extensible (by design), which has lead to stuff like WebDAV and the like. Stuff that is used large scale, over the web. So the web is not 'just' HTTP.

There's deliberate trade-offs in the web's architecture which means, unfortunately, you can keep coming up with edge-case applications which are challenging (although often not impossible) to implement using web technology. The reality is that a large majority of applications are information-centric, are distributed in nature, need to evolve over extended periods of time, and therefore benefit _greatly_ from the trade-offs that the web has made.

The web's not perfect but it's evolving and - importantly - it doesn't have the benefit of being completely fictitious and living inside the mind of a jilted, chippy geek. No offense. ;)

</comment></comment></comment></comment><comment><USER28> Server side browsers are good for making screen snapshots.</comment>


A Disappointing New Problem with Geo-Engineering - <AUTHOR> https://www.theatlantic.com/science/archive/2018/08/solar-geo-engineering-cant-save-the-worlds-crops/567017/?single_page=true <comment><USER2> _What they found was sobering. In the geo-engineered world, maize yields did increase by 6.3 percent due to cooler temperatures (compared with the climate- changed world). But they decreased by 5.3 percent due to the reduction in light. When accounting for a few other side effects of geo engineering, there was essentially zero benefit._

I never thought of sulfate albedo enhancement as specifically about increasing agricultural yields. I always thought of it as a band-aid measure to jam a dangerous feedback loop of thawing tundra, ice cap loss, loss of stored carbon from soils => even lower albedo, even more GHGs in the atmosphere, even higher temperatures. Meanwhile humanity pokily gets its act together about cutting emissions and deploying slower-acting CO2 countermeasures like accelerated silicate weathering. I hope.

Knowing that crop yields don't get _any worse_ with sulfate albedo enhancement is better news than I expected. (If you were expecting to lose a whole leg, hearing that the doctors just have to amputate the foot is good news. My bar for good news about climate change is set pretty low nowadays.)

<comment> collective-intl Agree that this isn't that bad of a result. I find that nearly every article on geo-engineering is unnecessarily negative, always stressing the downsides and trumping up the 'unknown' side-effects.

Is there anyone left who can do a neutral cost-benefit analysis?

From what I've read, it should be welcomed as a miracle that there happens to be a simple, cheap technique that will decrease global temperatures, which has already been tested naturally with volcanoes, has minimal effects other than reflecting sunlight, fades out on its own over time, and can be precisely regulated by the amount of particles injected.

I agree we need to be careful of other effects of deflecting the sunlight, but, come on! The results so far are quite amazing.

It's this human bias against modifying our world (similar to the bias against GMO's or improving IQ by tweaking genes) that has delayed geo-engineering science by decades already. It's finally turning into a real field, and the only mainstream articles are ones that report mostly negative results.

</comment></comment><comment><USER3> Well, maybe it would take reducing CO2 production and geo-engineering to stop run away climate change.

But if Earth's various nation's can't collectively organize reduced CO2 production, and evidence so-far indicates they can't, trying to do geo- engineering by itself looks ridiculous and criminal on multiple levels (among the multiple methods of reducing CO2 and other greenhouse gases in the atmosphere, of course reduced production looks cheapest among them). And humanity's future appears similar if these trends continue. Note to the rich and other decision makers - no, you won't survive if the earth itself is dying, there is no escape for anyone in this scenario.

<comment><USER4> > Note to the rich and other decision makers - no, you won't survive if the > earth itself is dying, there is no escape for anyone in this scenario.

Hey, I agree with the sentiment. And still, there is virtually no chance of the Earth dying from GCC. Sure, if it flips to full Venus mode. But it's my understanding that experts consider that to be unlikely. I mean, the biosphere goes down kilometers beneath the surface. Worst case, there'd be a few hundred million years of ecological simplicity.

<comment><USER5> Yep. I've always thought we should try to reframe it as "save humanity" rather than "save the Earth". The Earth doesn't give a hoot, and it appeals more directly in our self interest. "Save the Earth" makes people think we're talking about things they only sort of care about, like saving the whales.

<comment><USER4> > like saving the whales.

Some people consider whales tasty ;)

</comment></comment></comment></comment><comment><USER6> All the geoengineering proposals I have encountered ignore ocean acidification. A less-overheated planet with a dead ocean is hardly any better than an overheated planet with a dead ocean.

That said, half of global climate disruption is from refrigerants. To prevent ultimate disaster, existing refrigeration systems must be destroyed without gas release, and replaced with systems that don't rely on (and leak) CFCs or HFCs.

</comment><comment><USER7> This is not a problem with geo-engineering as a whole, but only with one of the methods.

Other methods like sea fertilization, or building large number of solar updraft towers are much more promising.</comment>


Landing Page Generator - <AUTHOR> https://owwly.com/product/Landernow-150/post/Landernow-170 <comment><USER2> Your landing page takes 18 seconds to load.</comment>


New Twitter Feature: To swear or not to swear - <AUTHOR> https://twitter.com/bentossell/status/1264960725170208768 <comment><USER2> I wonder will this get triggered with a Cyrillic "с", which looks just the Latin "c."</comment>


Parsing JSON in iOS the right way - <AUTHOR> http://remarkablepixels.squarespace.com/blog/2010/12/20/parsing-json-in-ios-the-right-way.html

<comment><USER2> The author is using a library that parses an entire JSON document in one go. In order to use this library, the author points out that the application must collect the entire document from the network before parsing the document. It does not work if the application passes chunks of the document to the parser.

An alternative approach is to use an incremental parser like YAJL. The application can feed chunks of the JSON document to the parser as the chunks arrive over the network. A clever application can update the UI before the entire document is received by examining the partially constructed object tree.

<comment><AUTHOR> Right but for people new to iOS dev is this really the best way? Instead of giving a caveat why not give a solution that will work in all situations?

<comment><USER2> There's no caveat for using YAJL. An application can feed data to YAJL from connection:didReceiveData: and know that the document is complete in connectionDidFinish:. This works if there are one or many calls to connection:didReceiveData:.

Anybody new to iOS needs to learn that connection:didReceiveData: is called as data is received. There's no way around that. There are two ways to deal with this. The first is to buffer the data as the author suggests. The other approach is to use an incremental parser.

</comment></comment></comment><comment><USER3> Good post. I think the same holds true for the NSXMLParser delegate (and probably many others, I'm still new to iOS).

The "foundCharacters" method is sometimes called multiple times before reaching the end of an element so it's best to assume you're receiving only part of the data.</comment>


Elon Musk: Starlink latency will be good enough for competitive gaming - <AUTHOR> https://arstechnica.com/information-technology/2020/03/musk-says-starlink-isnt-for-big-cities-wont-be-huge-threat-to-telcos/ <comment><USER2> Satellite constellations like Elon Musk's SpaceX Starlink could hamper astronomers' ability to spot dangerous asteroids and supernovae, study warns

[https://www.dailymail.co.uk/sciencetech/article-8078159/Spac...](https://www.dailymail.co.uk/sciencetech/article-8078159/SpaceX- Starlink-hamper-astronomers-ability-spot-dangerous-asteroids.html)</comment>


Medical researcher discovers integration, gets 75 citations - <AUTHOR> https://fliptomato.wordpress.com/2007/03/19/medical-researcher-discovers-integration-gets-75-citations/ <comment><USER2> Sure, but did you hear the one about the physicist modelling a spherical cow?

<comment><AUTHOR> Yes, but that was deliberately a joke.

<comment><USER2> clearly you didn't attend my PhD program (biophysics). It was spherical cows all the way down. Until you got to the spherical elephant.</comment></comment></comment>


Paul Buchheit at Startup School 08. This talk continues to inspire me - <AUTHOR> http://www.youtube.com/watch?v=EZxP0i9ah8E <comment><USER2> This is a good talk, though I enjoyed watching him talk about Friendfeed knowing now that it has been bought by Facebook. At around 17 minutes:

"Everyone says 'We`re building something different' and whatever, but then they go and flip for 20 million dollars or something, and your like, well then you weren't really doing something different, were you?"

"So, but we really are doing things differently."

<comment><USER3> Paul has a brilliant sense of humour.

</comment></comment><comment><USER4> Is this the one where he talks about how his experience at intel was analogous to steve wozniak's experience at hp? The idea that there were people just as smart and determined as them but weren't able to do anything interesting because of the environment really amazes me. reminds me of the talk richard feynman gave about the myth of some special talent or miracle that allows scientists to understand quantum mechanics. fuck, i need to get back to work

</comment><comment><USER5> Anyone know what the slides were?

<comment><USER6> We did before Google bought Omnisio and killed it. Acquisitions sure seem swell for the founders; not so much for the users.

</comment></comment><comment><USER7> Where are the slides?

</comment><comment><USER8> Why what does he say? Can you summarize?</comment>


Ask HN: Why don't startups outsource/offshore development if salaries are low? - <AUTHOR> This is a follow up for "What up with these startup salaries?"(https://news.ycombinator.com/item?id=9052727) If salaries are much low in startups comparing to Big Co.s why don't startup owners outsource  the development in cheaper labor countries and work on marketing, selling of their startups.
I am from Central Asia, here you can easily hire really good developers for 2K$, avg 1K$ and beginners are ready to work for <500$.
Most of the companies are already outsorcing their development here and selling in Europe, US.
Most of us may think developers aren't good enough. To some extent you maybe right, but in general thats not true. Avg. developers maybe haven'n worked with AWS so far, because mostly no demand for AWS in local IT companies, catching up is no problem. Instagram owners also haven't worked with highload before gaining success.
Update:  Please consider offshoring also, not only outsourcing.
Update: Reasons so far(ordered by priority, opinionated):
0. Mindset, (founders love vs contractors need) to make product
1. Not comfortable with remote workers or difficult to manage
2. High gaps in skillset
3. Time/Cultural/Language barriers
4. Low quality implementation (docs, tests, code)
5. Retained value <comment><USER3> A combination of reasons:

1) Most companies are not institutionally comfortable with remote working, to say nothing of remote working internationally.

2) There exist pervasive skill gaps between talented engineers available to work at $150k per year and talented engineers available to work for $12k per year. I respect that many people wished this was not the case.

3) Many investors in the Valley, whose opinions are quite relevant given that one cannot self-fund employee salaries, are of the opinion that outsourcing development work suggests a tech company which will never achieve the path to $100 million in revenue followed by a $N billion valuation, which is what their business model counsels them to search for. They would point out "I cannot think of a single company whose product was not produced in-house in history which achieved that" and they would not be far from wrong.

4) Managing outsourced development is a skill, and its a skill that most companies and individuals suck at, and do not particularly wish to become great at.

5) It is the widespread perception in the American tech industry that BPO companies produce software whose quality is abominable and that the process of dealing with them is pathological, as evidenced by the fact that only companies which institutionally hate software and software people are willing to work with BPO companies. Many in the American tech industry do not hate software or software people, and thus would have a very high bar to be convinced to use a BPO company.

<comment><AUTHOR> Yes, remote working maybe not an option, but founders can visit and open their development office. I have worked for 3 companies so far and all of them are selling product in overseas and doing development here, by putting someone experienced as a CTO in development office.

Ratio between salary ($150K vs $12K ) are too high comparing to ratio of skillset, 10x low salary doesnt mean 10x low skillset, thats just financial state in countries. A lot of guys are working at Amazon, Google, Microsoft and other big corps who took experience here, developers are not bad, they might not have enough experience.

~$300K is avg. spending for 10 developers with office and perks included annually. Compare it to $750K spending for 5developers where each of them has 2x skillset of outsorced developer just for salary and other spendings annually, which I guess will be around $1M/annually.

<comment><USER4> It's tricky. Being 2x better means 1/2 time to delivery, 1/2 maintenance burden, 2x more flexible software, and 1/2 the management burden, and very often all at the same time. It's also much harder to find cream of the crop workers in cultures you are less familiar with, so the average case (where some people are quite bad at it) is, from what I've seen, a little larger than 2x. Maybe 3-4x, sometimes more? And compounding across all those disadvantages (2x more work to make a change due to worse design, 2x times slower because of lower skill, with every week needing 2x as much management, slowed down by the extra daily operations and keeping-things-going, can be... a lot), it can actually work out to be a worse deal unless you're pretty careful. Personal experience shows that this involves both careful hiring and on the job training.

</comment></comment></comment><comment><USER5> My experience working at a startup that started out outsourced and slowly started adding inhouse developers:

It was mostly a mess.

1) Time/Cultural/Language barriers are inevitably the biggest problem. Want an answer to something critical _right now_? Too bad, it's 2 AM there and no one's around.

You're going to end up scheduling meetings at insane hours, and someone's going to get burned out on that.

I also had the fortune of watching an email thread where someone used a colloquialism ("Move it over just a smidge") and it took three days to resolve (because of the time differences) what that meant.

2) This is going to sound super snotty, but I'll just say it: There was a definite feeling of "you're still over there because you're not good enough for anyone to sponsor you for an H1B".

In general the really talented developers I met left quickly because they found someone willing to sponsor them. What was left was... well, what was left.

The salary gap is so severe that it becomes a lot harder to say "I want to stay near my family and friends." If someone offered me 100x my current salary to move to, well, anywhere, I'd be packed in 5 minutes.

<comment><AUTHOR> Can not agree with "you're still over there because you're not good enough for anyone to sponsor you for an H1B".

There are 2 reasons I see now:

1\. Living cost ratio. Well, you might get 10x salary comparing to Asian developer, but living cost is not at the same rate. 100x is different story, but again related to living cost, you might jump in there, when you get there you might end up with 101x living cost.

2\. Assume every knowledgable person will leave their homes for 10x salary, 7x living cost and they are earning 3x of money and country will end up with idiots, slow development, slow financial growth in whole country. It takes some time for developing countries to be in decent place if professionals do not leave, it takes forever to be in good place if everyone will leave just for 3x or maybe 10x.

<comment><USER5> > living cost is not at the same rate

I knew this was going to be brought up, but it's not enough to overcome the monumental salary gap. Your example of developers earning "$2k" just made me think that I _invest $2k a month_ , not even what I save in total each month.

The living cost is obviously much different. There's still really just no comparison, in terms of net compensation.

> Assume every knowledgable person will leave their homes for 10x salary, 7x > living cost and they are earning 3x of money and country will end up with > idiots, slow development, slow financial growth in whole country

That's all well and good, and you're right, but the individual ends up being much better off by leaving. Brain drain, as it's called.

Rhetoric like "do it for your country" is good in theory, but individuals who leave have an opportunity to help themselves and their families out immensely via monetary gain.

It's really, really hard to ignore that.

<comment><USER6> Actually nope.

Cost of living matters. A lot.

It directly affects the kinds of things you can afford. Out here (in India), I can easily afford: house rent + groceries for a 2 bedroom apartment ( ~2000USD per year ), paying a cook to cook twice everyday ( 800USD per year ), paying someone to clean my house once a week. ( 200 USD per year ) and still manage to save up more than 50% of my paycheck - after paying 30% taxes.

Neither the places abroad offering me to move there nor any of my friends living there have these luxuries. That's why most of my friends working abroad want to come back to India "after making enough money". Especially the married folk, who are expecting babies.

Also the pay difference is really not as high as you'd think it is.Most decent companies (Google, Amazon, etc.. ) here pay you around 40k USD per year for a guy with 3-4 years experience. Most of my freelancer friends here seem to be making more than that actually.

</comment></comment></comment></comment><comment><USER7> Retained value.

The reality of a lot of development is that you, as a developer, learn about the domain in which you're working, and also grow your skills with each subsequent project you work on.

As an employer, it's desirable to pay someone to do work, and then to have that person do more work for you, and as they know the subject matter better and better and as they progress as a developer, the value they present to you grows. Additionally, this is good for the employee, as unless you're in a moribund steady-state company (i.e. so long as you're in a startup) you're there for the journey, and you develop in step with the company, and get to witness and learn a lot of stuff "at the ground floor".

Conversely, if you hire a contractor, the moment they're "done", that value walks out of the door, and if you want to do further product development, you need to train someone up, get them familiar with the existing codebase, and so-forth - and this is expensive, and if your contractor hasn't documented stuff thoroughly - you're up the brown creek without a propulsion instrument.

Seeing contractors/outsourced dev as a "cheaper" option is a false economy. Sure, it might be cheap in the short term, but it's a hell of a lot pricier in the long term.

</comment><comment><USER8> Someone who want to take advantage of this income gap would probably be better of starting a company _in_ Asia. Since the web is global you can sell to customers in nearly any country. It might be good to target the domestic market first though, and then expand abroad.

</comment><comment> turk- I work as an Engineer at a VC backed ($20m from two rounds) product company in the US. We used outsourced Engineers for most of our developers. We are located not located in Silicon Valley but some of our VC's are from the valley.

Our founder & CTO has experience with co-founding another successful startup ($25-$50 million in revenue) with an outsourced engineering team, which I also and many of our team members also worked at.

The engineers we have employed in Kiev are very good. However, working with outsourced engineers is still very challenging. One of the things that allows us to be successful is our experience with it and what we've learned from our mistakes at our previous company. I wouldn't recommend it for your average company.

</comment><comment><USER9> Outsourcing works if you're able to define the requirements of new features in extreme detail, covering every nuance and edge case. This is the opposite of what start ups are all about: incremental steps and iterations.

The result of outsourcing in start ups frequently ends up with a most of misunderstanding and back and forth. Code not written with potential business needs in mind, and everything that goes with that.

It would be cheaper if it took the same time as doing locally and provided same level of quality. This usually doesn't happen. So what's saved in developer salaries is spent in founder/product manager time and delay of release.

</comment><comment><USER10> Remote development is the absolute slowest way to get anything done. Startups need speed, a lot of the time.

I've worked with every arrangement of developer mgmt on websites I've built. Inside, outside, agencies, freelancers, directly managed on agile teams, separate departments on semi-waterfall teams. Outsourcing works best when you have a lot of predictable work to do, for example (these are from my direct experience)

1) upgrading a CMS in an environment with lots of custom app dev. (Say what you will about how much it makes sense to write custom apps in a CMS; I agree with you). When we decided to prioritize the upgrade over new work, we got outside devs to work alongside the local agile team, to do the more predictable, less troublesome work.

2) Retrofitting secure forms processing onto an existing CMS where (to reduce attack surface) the secure site did not run inside the CMS, but used HTML exported from the CMS (for design/nav elements etc.). I actually think this would have been better with internal staff, but the one-off nature of the project meant that hiring FT was not possible.

I just don't see running a startup that either of these situations (or their analogues) will come up. For a startup you need fewer staff, doing less management and more work, as quickly as possible (most of the time). You need people who get code, get security, can manage a server, can set up a heroku app, etc. WITHOUT a lot of oversight because you are just not prepared, or too busy to do it.

</comment><comment><USER11> I have had both very positive and very negative experiences with outsourcing development. Regardless of country including within the States.

Yes, we can find cheaper labor in other countries. Yes we can mostly overcome language issues, time differences etc. But one thing that is not insurmountable is the number of times the tech I have paid for would wind up in other peoples hands. The problem is not unique to other countries as it happens within the US too, but at least within our own legal system there are ways to protect clients and ourselves better. When dealing Internationally, the chances for a startup to guard their intellectual property and competitive advantage is far less likely.

And honestly, the companies that have been most successful in outsourcing Internationally, generally have a presence in Country. Microsoft, Oracle, GE among hundreds of others (I did this for/with GE for a time period). For a startup splitting a small team Internationally to try and save on what should be a core skillset and competitive advantage just doesn't make sense. Not to mention, the only thing of value for a startup early on is the team they assemble. If that team is not dedicated, is out sourced and worse yet, outsourced Internationally, the startup will struggle to gain the attention of investors if that is what they desire.

Last point, if you are bootstrapping then the equation (and risk profile) can change. It may be to your benefit to try and have some (IMO non-core) components of your software built offshore. Just takes some management and willingness to spend the extra time on documentation and communication. Additionally, for a well funded startup in later rounds they may choose to offshore parts of their development to help move things along because they have the ability to take some risk on there, and their core IP is already developed.

</comment><comment> wes-exp Two things:

1) You don't outsource your core in business, so outsourcing tech is not appealing for tech startups, period.

2) Typically tech startups are more of a growth optimization problem than a cost optimization problem. Outsourcing to cheaper parts of the US, let alone overseas, usually doesn't increase the startup's growth potential.

<comment><USER12> Your [1] is flawed because what is core is continuously shifting as the advantages of the knowledge you can get somewhere else exceed the costs.

An example from banking:

"Morgan Stanley has about 500 people employed in India doing research and statistical analysis. About 100 of Goldman Sachs' 3,000 employees in Bangalore are working on investment research."

[http://www.nytimes.com/2008/08/12/business/worldbusiness/12i...](http://www.nytimes.com/2008/08/12/business/worldbusiness/12indiawall.html?pagewanted=all&_r=0)

<comment> wes-exp Be careful not to conflate offshoring with outsourcing, which the article does. Some startups will have their own employees overseas, but my point is specifically about outsourcing to other companies.

<comment><AUTHOR> > Be careful not to conflate offshoring with outsourcing

Ups, thats my fault, lets add offshoring to the title.

</comment></comment></comment></comment><comment><USER13> Every hire is so crucial early on and one bad hire can really set you back. I know from my experience that early hires are typically done through connections rather than recruitment. I am sure there are very qualified candidates overseas but finding the right guy would be seemingly much more difficult without any prior knowledge or experience with the candidate.

I am sure this is very dependent on the company and technology. But generally every startup I have worked at has depended on a core group of developers early and they usually had some prior history or at least connection.

I can imagine this might be different for founders without a tech background... and anecdotally that appears to be true (non tech founders appear to be more open to outsourced development). That's pure speculation.

</comment><comment><USER14> Finding talent is one of the biggest challenges facing my startup and most at the moment (and most/ all other start ups I know).

I would rather hire someone who I can meet face to face most days as you just don't get the same dialogue working remotely as you do when you're sitting on the same table. This is coming from someone who as worked as a consultant working mostly remotely for the last 6-8 years, and I did a degree remotely.

If I can't find a quality JS dev in London (it's not as easy as you would assume, but then I've only just raised money), then I'm willing to outsource portions. Still have a number of options!

</comment><comment><USER15> Here's a question that will help:

Many of the major outsourcing-providing countries have far more developers than even the US, so why aren't those outsourcing countries at least creating a ton of early stage startups?

My answer, as someone currently living in a major outsourcing providing country -- doing developer consulting is EXTREMELY opposite from making a startup, in many of the small but most important ways. Having a ton of raw developer resources, as many of these outsourcing countries have, is not the bottleneck.

Only working strictly as an outsourced developer will teach you to optimize all the wrong things.

</comment><comment><USER16> In my experience, there are two schools of thought in this area: 1) You want developers in-house because they're creating your product. This generates your revenue, so you want to be intimately involved (not outsourced). 2) You want very, very low overhead and/or aren't in a time crunch to deliver the product or new features. Which gives you more flexibility to handle somewhat lower quality (and more difficult* to manage) outsourced developers.

* Not as easy because they are not in-house.

<comment><AUTHOR> Totally agree with "intimately involved", this makes development more productive, than calling by skype and saying "Hey we have bug, clients are waiting, just fix it somehow" ;)

</comment></comment><comment><USER17> Management of remote staff increases management overhead, which distracts from finding product/market fit, growing the business, and other critical tasks. It's about focus.

Management of subcontractors is another form of management that increases overhead. As with management of remote staff, this too increases overhead.

Rapid change is the norm in the early days of a business. Rapid change when the developer is sitting next to you is difficult enough. Doing this with with time differences and across long distances makes it extremely difficult.

Specification is important when working with remote developers. Most startups don't want to invest in detailed spec writing as it adds overhead, slows progress, and may be a total waste if the feature being spec'd ends up not resonating with customers.

Cost. Yes, outsourcing to remote locations is not a savings of 80% during the startup phase. Once you factor in increases in management costs, increases in spec writing costs, increases in integration costs, increases in quality control costs, etc. the cost difference largely fades or even turns negative.

Of course, all of the factors above flip in the other direction once a company has a repeatable business model. Once repeatable, a business' operations can be standardized and process driven. At this point, outsourcing to low cost destinations becomes very attractive.

</comment><comment><USER18> I've seen international teams succeed and fail. Language barriers are a problem especially when trying to grasp domain knowledge. Most outsourced teams require specs and don't work well without them. Most startups prefer to have some time overlap where they can talk directly and classify problems. And of course there's also the idea in silicon valley that good engineers are a must if you want your company to be aquired by a Google or Yahoo

</comment><comment><USER19> There are several factors but the biggest one was India, I never understood why software quality from India was so poor. Honestly, it made no logical sense, here is a population that has a group of individuals that are for whatever reasons fairly strong in STEM. It seemed inconsistent, until one day I met a developer named Karthick, Karthick could code and was a passionate developer, he was everything that India software quality was not. So I asked Karthick about my observations and why software coming back from India was so poor. What I found out amazed me What I thought was a complex problem, was actually a problem of incentives. See Karthick told me that in India, a man is measured by how many people he manages. It is a throw back to the cast systems and it is a source of pride. The fastest way to management, in India, is STEM and specifically computer programming. So what you get is a bunch of would be MBA's, getting engineering degrees, that they do not want, to take a job that they do not want, to get a job they are not educated for and are not qualified for. So it creates a fail up environment.

This was the first wave of problems and honestly after the failures of BoA and several other US companies who lost billions trying to save a buck in that market, US companies are hesitant to enter that market again whole hog. They will pick up a developer or two to augment a team, but not many people are sending whole projects over anymore. Everyone has a horror story and it's enough to make most would be bargain shoppers think twice about trying to save a dollar, by trading it for risk.

The second issue is one of tribal knowledge as I call it. People conduct their lives in very different ways from Central Asia to the US. What we take for granted as common knowledge over here may be a uncommon or not even done in your culture and vice versa. When we document systems, we take for granted "common" knowledge and it does not get documented. For example I worked on a system one time for a large hotel reservation engine that had work done in India. 2/3 of the development staff had never personally booked a hotel room online. It ended up costing more to have BA's and Architects document the system, than it would have to have thrown the BA's and Architects in a room with a bunch of developers. In the end what did we do, well we sent our CTO, our BA's and our Architects to India to sit in a room for 2 months at a time until the project was a success. Basically enough from the VP's to declare victory and get the hell out.

So what does it all boil down to, cultural mismatch. As US business homogeny (I don't mean that in an arrogant sense, I mean it in a corporate culture way) and the Internets global village takes it's hold on the globe, that mismatch becomes less of an issue, but someones is going to have to take the risk to prove it out, and unfortunately the generation that smashed on the rocks in India is now in the decision making seats and not many of them have an appetite to try a do over. Especially startups where project failures or delays can kill a promising idea.

<comment><USER20> There's also the issue where it's considered extremely rude to say "No", so an answer of "Yes" to a question doesn't always mean what you think it does.

<comment><USER19> I was going to mention that as a third issue, but that seems to be more focused specifically on India. I have not seen the hesitance to deliver bad news from other Asian cultures.

</comment></comment></comment><comment><USER21> Take the following with a grain of salt, as I've only seen this in action once.

The language barrier is pervasive even if the consultants speak English fluently. At my last company, we hired consultants from Belarus and besides a small accent there were no problems communicating with them. However, when it came to actually coding, the differences in language were more visible.

It was mostly simple stuff. the difference between an "Order" and a "Subscription". The knowledge about western addresses (we had to explain what a postal code was). You could always tell if it was one of our consultants that wrote a given piece of code.

That being said, it was effective. We accumulated quite a bit of technical debt that we later had to pay off, but by any metric, it was successful. They were very competent programmers (one was amazing!) and I wouldn't hesitate to bring them onto another project. But I would try to micromanage more.

</comment><comment><USER22> I have built one startup on "outsourced" labor in India and would highly recommend it. The folks I hired were excellent, and I'd highly recommend them to any western employer. One of them I later attempted to hire at an American company, we just missed the visa window.

I put the word "outsourced" in quotes because I also moved to Pune. So it wasn't really "outsourcing" in the traditional sense of hiring some of "those people" and throwing work over the wall at them - it was really just building a company with people who happened to live in Pune.

It's a great way to get more bang for your buck. Indian devs are just as good as NRI devs and ABCD devs (which most companies already have plenty of) - <USER2> cheaper.

Of course, VC's may not like it.

<comment><USER23> [http://www.urbandictionary.com/define.php?term=NRI](http://www.urbandictionary.com/define.php?term=NRI) [http://www.urbandictionary.com/define.php?term=ABCD](http://www.urbandictionary.com/define.php?term=ABCD)

</comment></comment><comment><USER24> Some startup did that. However I do not recommend it.

I'm from China and my perspective is that: Unequalness and conflicts.

Startups doing this usually pays average in the US. When they hires in China. They could afford to pay higher. This often means that they got better people but in a lower position. This prompts tons of bureaucratic.

This does more harm in the startup side. Because it's easier for the startup to blame their oversea colleagues rather than to face the problem in their own hands.

</comment><comment><USER25> If your site is very well specified, static, and small, you might get away with outsourcing it.

A lot of startups need to be constantly iterating. That's how they make their product. Throw something up, see what the feedback is, change it. You can't do that if the devs are not very close to the feedback. And that generally means living somewhere near the customers, with attendant costs.

</comment><comment><USER26> The factors behind building a successful startup are more than an idea or lucrative salaries. Higher salaries doesn't make startups successful, rather building teams with perfect chemistry, culture, mutual trust and synchronization between members. For that, physical presence of team members under a single roof is very important. Hope that explains it all.

</comment><comment><USER27> My problem is that I actually don't know how to do 'outsourcing'.

How do I look for a dev that speaks my language? How do I pay them? Are there any legal obligations on my behalf? How will my accountant deal with paying an international employee? Am I going to have to pay a consultant to get questions about outsourcing answered?

There are too many unknowns for me, as a startup.

</comment><comment><USER28> As someone with extensive experience of working with offshore development teams in India and China (I'm from the UK myself), these reasons spring to mind:

1) Language barrier. Remarkably, still a major issue even in tier-1 cities in China. Not so much of a problem in India, but it's still there to a degree.

2) Quality. This is a big one. I've worked with some great developers and some really, _really_ terrible developers. The former seem to be a rare breed. I can interview dozens of pre-screened candidates before I find someone who is any good at all. Never assume what is written on CVs/resumes as truthful until you've assessed candidates!

3) Culture. Don't underestimate the impact of this one. I'm a seasoned traveller, but working with people from other cultures can still be challenging at times. In my experience, 'face' is an issue when working with Chinese developers, and lack of directness and pro-activeness is an issue when working with Indian developers (sweeping generalisations, I know; just my experiences). These can have a big impact on your projects if you are not on top of it. Something else to consider in India is that it's very difficult to find people with many years of experience, as most people there don't see software development as a career - it's seen as an on-ramp to management positions, and there is a stigma attached to being a developer for 'too long' without being promoted.

4) Time difference. This can work for or against you, depending on what you want. I'm a firm believer than the best way to work with offshore developers is to work _together_ , so unless one side is willing to change their working times, it's certainly a problem for me.

5) Previous failure. I've found many people have tried doing offshore development 'the wrong way', and it's left then disillusioned. Simply throwing a specification over the wall to a remote team will _not_ work. Ever. Failure guaranteed!

I want to finish by saying it _can_ work, if done properly. Over the past few years I've built up a team of 8 good, dependable developers in India. I've done this by working closely with them, spending time with them in India, conducting training sessions, buying Pluralsight subscriptions for them, encouraging direct dialogue and pro-activeness, mentoring, and generally spending a lot of time communicating. Of course, this all takes a lot of time and effort (and some money too!).

<comment><USER29> Argumentative & too emotional - are Indians tough to work with?

[http://economictimes.indiatimes.com/magazines/corporate- doss...](http://economictimes.indiatimes.com/magazines/corporate- dossier/argumentative-too-emotional-are-indians-tough-to-work- with/articleshow/45638709.cms)

</comment></comment><comment><USER30> How are their English speaking and communications skills compared to developers in the US?

<comment><AUTHOR> Most developers have good knowledge of English, Lets use IELTS for this, I guess scores are in range of 5-9 and arithmetic mean is somewhere at 6.0

</comment></comment><comment><USER31> The biggest reason is that a solid engineeering team, local or remote, needs to work directly for you and not be a subcontractor. Setting up a remote office and hiring staff is a very, very time-consuming and risky process.

<comment><AUTHOR> > Setting up a remote office and hiring staff is a very, very time-consuming > and risky process.

This could be solved with specialized agencies which finds/tests/interviews/guarantees code quality of candidates.

</comment></comment><comment><USER32> There is a lot of arrogance in this thread. Thanks to better exposure through HN,Github etc , Indians devs are levelling up fast and I predict that in 4-5 years the quality gap will become almost non existent.

<comment><USER33> It's not so much as arrogance as it is just being honest about the quality of outsourced work. If you were worried about offending people, you would come up with all sorts of excuses for not outsourcing work. But honesty is not always the nicest thing to hear. I've been working with our outsourced team in Bangladesh and their quality of work is much less rigorous than that of our in-house team.

"Indians devs are levelling [sic] up fast and I predict that in 4-5 years the quality gap will become almost non existent."

You may be correct but the Original Post is talking about now*. Also, you seem to agree that there is a "quality gap".

<comment><USER32> I completely agree about there being a quality gap.

The reason was that Indian IT was dominated by body shopping companies that bid for grunt work and then threw quickly trained engineers at the problem , some of whom never even studied CS.

This is changing now as we have an ecosystem of smaller companies which hire better people and have better processes and incentives. It will take time for the effects to be felt but I am confident that we will improve thanks to the better exposure we have , and learning from HN and Github.

This isn't restricted to India though. Western developers should brace for a lot of competition in the years ahead. Eastern European developers are already almost as good.

</comment></comment></comment><comment><USER34> There are so many anecdotal examples of bad experiences in this thread that I have to chime in with a counterexample.

I used to contract for a startup that was sold to Google a couple years ago for $350 million dollars.

In the beginning, it was just the two co-founders in the Valley and us developers, spread around the world. Later, when the company took VC funding, we helped to expand the engineering team with in-house developers as well (at the time of acquisition the total eng headcount was ~50 IIRC).

The product both took off like wildfire, grew, staid stable, and weathered some serious beatings on AWS just driven by the contractors. Even when there were several in-house teams, the remote ones were by far the most productive and e.g. drove 90 % of all the ops side of the service.

So, a couple of points:

* Retention/ownership: This has nothing to do with whether someone is an employee or a contractor. It's true that most outsourcing companies try to sell you just hired hands, but that's not all that's out there. You can find superb small developer houses that take more ownership in your product and code than any developer you can get in the Valley ever would. They're not 10x cheaper, but they're probably much better than any developer you can reasonably hire in the Valley at the moment, period.

We staid at the startup we contracted for from 2008 to 2013 and only left because Google doesn't do contractors, period. (This is a story of its own but I'm not comfortable telling it until a few more years have passed.) There were not a single employee that staid at the company for longer than us.

Employer shopping is much less pervasive outside US, so considering an employee a more long-term investment than a contractor is an illusion. Besides, you have the exact same means to keep a remote contractor happy as you have with an employee.

* Quality of code: This is a red herring IMO. You can choose whom you hire, even if they're remote. You have the same opportunities to check their level and productivity, and it's even easier to fire them if things don't work.

* "knowing what to build, not just how to build." Most of this isn't really related to remote vs in-house either. If the product is online, much of its clients are as well. I used to spend a shitload of time in the early days helping clients solve their issues from 10 timezones away. And often the clients were in the EU, when in-house people wouldn't have been available to help them.

* "you're still over there because you're not good enough for anyone to sponsor you for an H1B". Sorry, but I rather stay here with pure nature right off the door, 4 real seasons, and no rush, and produce the same (or probably more) output and value as a remote contractor. I might not make the same salary I would in the Valley, but it's not that far off if I contract for an American company. I also have much more flexibility to choose where I am at any given moment and how I structure my workdays. Plus, not all people hold money in quite as high a regard as people in the US do.

So, long story short: it's much more about who you get to work for you than employee vs. contractor. If you go for the cheapest code farm option, of course you're getting cheap quality. But you can also hire expert-level individual contractors or small teams where you know exactly what you're getting. They are not cheap, of course, but still less expensive than senior level employees in the Valley if you consider you can skip all the benefits and overhead.

And of course, at the moment they're probably better than what you can find in the Valley for any amount of money.

<comment><USER35> Hey Jarkko, been a while, I hope you and the other guys are very well!

A few things from my view, not to take away from anything you said, just to drop in some thoughts from my angle:

* If I was forced to pick favorites, the most productive SWEs we had were actually in-house. This is no reflection on anyone, and also isn't directly related to being in-house. It's down to individuals, and most significantly how they communicate around requirements. It's a bit more tricky to do this remotely, but you guys also did this very well. I completely agree that you guys were among our top performers; you were absolutely essential to many stages of our growth, and I would hire you all again in a heartbeat. I love you guys, and I miss working with you.

* Our eng headcount was actually about 50% larger, the extra gap was more contractors. With so many contracting teams, I gained quite a bit of experience with a wide spread. You guys were great, Wyeworks were also absolutely fantastic. I won't mention the others, as they were not so strong, and one contractor in particular did a fair bit of damage as a result of isolated work that was largely overengineered (work that subsequently landed in a book, that's still popularized to this day, and is a total anti-pattern that I had to rip out of our code base myself in a mad hurry to fix the critical outages it's piss poor performance resulted in). The point is, overall, we had a couple of great contracting teams, you guys included, and a couple of not so good. I don't really see much direct correlation with "contractor or not" here, it's more about work ethics and processes. The contractors that did worse worked in isolation, the contractors that did better worked in collaboration. The best contractors always kept their cool as they retained the concept of "you're a customer". This advice extends to satellite teams too, where we had one that could have benefited from a more consulting approach to their integration. We all live and learn.

* Retention and ownership take a lot of work on all sides. We had a very different relationship with you guys to what we had with Wyeworks. Neither was bad, but Wyeworks was more like a company, and you guys were more like individuals. Of course this is a big product of history, you actually were individuals until after the close, and Wyeworks was obviously bigger than you guys by then too. Both great, both would be hired again in a second. You all demonstrated ownership and stuck with us through good and harder times. Thanks for being awesome! As far as the big G and contractors goes, well, we can't open this wound for all to see here, but Wyeworks got through the paperwork and continued with us for a while longer than you guys were able to. This isn't a comment about you guys, and as you say, we shouldn't bare all here right now, but it's just to say that large organizations have complex legal requirements that can be difficult to overcome - this is something that contractors need to understand, and companies relying on them that might be acquired should also take into account - it could affect your valuation in extreme cases. As far as "not a single employee", you're mostly right, maybe you are right, but did you forget our Kiwi friend, our first FTE? he's still here, rocking it. I agree with you that the typical churn rate in the valley is all manner of crazy. I have friends who've moved upwards of 4 times in a year. I'm glad to say that we had far better retention than that.

* Code quality. Well, I told a story about this above, so I won't repeat it all here, or risk damaging the guilty with more details, but it's really important to remember the core point: the gap was in work approach. We got crap code from people who worked in isolation. They were slower, their code was overengineered, underspecified, buggy, and unsustainable - but most critically - largely unnecessary - most of it could be elided with a quick conversation with the PO. It was replaced, and in the case I described above, it was replaced by me, which, given my position was an expensive call. This doesn't have anything direct to do with contractors though, it's just slightly easier to work in isolation over the wire than it is in person - though we had plenty who did that in person too, with similar but less extreme results. More importantly, it's easier to train this stuff out, to help individuals develop their skills and measure their effectiveness when they're local. That's a long winded way of saying that it is easier to manage your "average" employee in person than it is remotely. Strong employees, like you guys, this is less of an issue. You self manage, give and take feedback, and we all get better together.

* knowing what to build. Yep, as you say, this has nothing to do with location. It does have to do with communication, so a contractor needs to be extra effective at communication to make this excellent. Some can, some can't - same as any FTE's. Again the difference is, as a manager / leader, you can more easily draw people below this line up if they're within earshot. A contractor below this line you often end up needing to drop.

* H1B and "you're not good enough". I don't think we ever uttered such horrific words, but I'm sure they've been said somewhere. The degree requirements for the H1B can be a sticking point, and that impacted a few of our folks over the years. I think these rules are dangerous for the country, especially with the STEM numbers being what they are. Sure you can pile more people into universities here, but what are you going to do about post academic training (which is extremely important, see all the points above none of which are ever taught in a CS/IT degree). We also opened a satellite team as a tactical move to increase headcount without being stuck in the US/valley hiring market, and it was a good move. The team busted the ceiling on their hiring goals, and even though that rapid growth came with the usual growth pains, it was overall a very successful move and many great additions to our team(s). If we'd have been able to find other strong contractors we may have considered doing that too.

I completely agree with your conclusion that it's all about who you get. I hope that the above also speaks to this fairly clearly. I've had a wide range of strong and weaker FTE's and contractors. I don't divide them in that way. There are genuinely other business reasons to prefer one over the other, but a lot of the commonly stated crap isn't it - given the right people and the right attitude. As far as expense goes, it's all much of a muchness. If a company is that concerned about the cost difference of contractors vs. FTEs they're not hiring at the right level and may very well have some management and/or financial problems. From when I've done contract/consulting/WFH work, I'd avoid such companies.

I have recently recommended a bootstrapping company to use some contractors for some of their work, as they're situated in the valley and don't have the ability to effectively judge incoming talent. They can very effectively get up and running with some contractors, and take their time to find a really strong first local team. I could see them maintaining a mix long term, much like we did, and to great success.

I wish you guys all the best, and miss you.

disclaimer: I was the first Eng Director, and later CTO at said company. Nonetheless, comments are exclusively my own, and not representative of any organization.

<comment><USER34> @raggi Thanks for chiming in with your POW. You certainly went into much more detail than I was comfortable going.

I completely agree with you (although wasn't of course even aware of all the details, the company grew so fast during the last years). It's all about ownership and communication, which are somewhat easier with someone next to you (with obvious caveats as well), but it's far from black and white. Actually, remote in some ways makes it more explicit: you have to write stuff down, and thus, when you hire new people (or people leave) it's more than tacit knowledge.

But yeah, it boils down to individual in the vast majority of cases, much more than whether the individual sits next to you or not.

"did you forget our Kiwi friend, our first FTE? he's still here, rocking it." Of course not, but he was a remote contractor as well through the early years :-)

Maybe that was one of the things that helped us to begin with: since all of the developers were remote originally, you just had to have the communication in place. I would imagine it's trickier if there is an in-house team originally and then remote devs added to that.

Miss you too!

<comment><USER34> And the POW-instead-of-POV-acronym was completely unintentional, I swear :-)

</comment></comment></comment></comment><comment><USER36> In my experience the code delivered by outsourced developers is always of a low quality. It will usually do whatever you asked them to do, but that's it. No other considerations beyond exactly what you've outlined in the requirements will be given any consideration. No thought to future expandability, robustness, etc.

At my job currently we have been working with an outsourced developer as all of our internal developers are always busy but we have other things we want to do. So we thought, hey we haven't tried outsourcing in a while, let's give it a whirl. The results have been on par with every other time I've used outsourcing in the past 20 years.

The end result will probably work for what we wanted it for, but the code is bad. I am not looking forward to having to support it and work with it over the next 10 years. And it's been a ton of back and forth to just try to get the code to do what we said we wanted it to do in the first place.

</comment><comment><USER37> With all the SV talk about $100k+ salaries, the reality is that in the US you can pick up average developers at a pretty reasonable salary. Think closer to $30k-60k. Add on top of that the cultural issues that make it more difficult to have developers handle other issues throughout the day like client support, writing documentation etc, and you can see how it really isn't that huge of a gap. Remember there is no actual developer shortage in the US unless you are talking about the very highly skilled top tier developers.</comment>


Courgette: better binary diffing by understanding x86 - <AUTHOR> http://neugierig.org/software/chromium/notes/2009/05/courgette.html <comment><USER2> This is the approach used by Exediff (B.S. Baker, U. Manber, and R. Muth, Compressing Differences of Executable Code, ACM SIGPLAN Workshop on Compiler Support for System Software, 1999).

I can't say that I'm very surprised that it's making an appearance in Chrome, given that one of the authors (Udi Manber) is a VP Engineering at Google.

<comment><USER3> I believe Udi Manber works in Search or online something or other, and not Apps.

There are 10,000 engineers (in varying capacities) at Google, who have all done lots of disparate and random things. Sometimes, by sheer stroke of luck, people will happen to have already done something, but due to size, it will simply be reinvented.

<comment><USER2> I didn't say that Udi Manber was directly involved in this project -- but that doesn't mean that his presence at Google didn't contribute. Firefox uses bsdiff, and I know Chrome people have looked at it; it wouldn't surprise me in the slightest if they saw the name "Udi Manber" in my thesis, said "hey, we've heard of that guy", and were consequentially encouraged to replicate his approach (well, his student's approach, technically) to the problem.

<comment><USER3> Sure, thats reasonable. I think I'm just a bit frustrated by the "so and so works at Google, therefore they must have chosen technology X or approach Y because of their presence!" when its very hard to know what everyone in (or formerly at) Google has ever worked on and remember to call them up.

</comment></comment></comment></comment><comment><USER4> I did this in the 90's in pascal as shareware. No one bought it.

Cool idea though.

<comment><USER5> _I did this in the 90's in pascal as shareware. No one bought it._ – This may be one of the best lines I heard in weeks. I will use it to dismiss uninteresting ideas until someone threatens bodily injury upon me.

</comment></comment><comment><USER6> Similar idea gets used for compression of code - transform it to a more amenable form.

<http://www.paul.sladen.org/projects/compression/>

Make sure that the transform and its inverse are robust in the face of random data - and it can be completely hidden from the user.

</comment><comment><USER7> Well, it might work with Windows, but it's really a no go on distributions which are using package management and un-privileged user accounts.</comment>


Microsoft tablet OS not coming until fall 2012? - <AUTHOR> http://www.engadget.com/2011/03/03/microsoft-tablet-os-not-coming-until-fall-2012/ <comment><USER2> Microsoft playing the "Look everyone, we're going to do that too - and more! The greatest thing ever is coming out from us real soon now so you should stick with us and not switch to that shiny thing over there" game is hardly surprising...

What's the Windows version right around the corner this time? 8? Oh. /This/ time it's going to be great, honest? Tablets? Yeah... exciting.

Whatever, Microsoft. Fool me once...

<comment><USER3> If you actually think about this for more than 5 seconds, you'd realise that they're releasing an OS that's both a successor to windows 7 and a tablet OS. It's like Apple merging iOS and OSX[1] and releasing it as OSX 10.8!

[1] yes, both have same core, but they have _different_ set of functionalities. And they are gonna merge it somewhere down the road.

</comment></comment><comment><USER4> Great so MS goes back to the drawing back after a huge realisation at the unveiling of the iPad2. Oh Thats right there _wont_ be another iPad in 2012!</comment>