The rectangle with rounded edges was a design patent (http://en.wikipedia.org/wiki/Design_patent) not a utlitity patent, which the Google patent is.

I'm not saying the Google patent isn't bad, especially given the clear prior art with MS Comic Chat, but just that it's important to distinguish the types of patents when pointing out the inanity of the system. Design patents are a little easier to accept since they're closer to copyright on physical objects.

-Chris

It will be interesting to see if they keep this up when they're spending customer's money rather than investor's. A blank business with a set amount of money to spend is easy to model this way. Once you start to find the real value in your offering and determine how revenue is actually made, things get trickier. One or two stellar salespeople or engineers can be responsible for an outsize portion of the business. They need to be compensated appropriately.

-Chris

This.

Reproducibility (what we strive for in science) is not the same as repeatability (what the poster is actually trying to achieve). Results that are not robust on different platforms aren't really scientific results.

I wish more scientists understood this.

-Chris

Luckily for this discussion, the data actually exists. Indiana recently went from not changing time to chaning time. Turns out energy costs are 1-3% more under daylight saving time than with out it.

Here's the citation:

NBER WORKING PAPER SERIES
DOES DAYLIGHT SAVING TIME SAVE ENERGY? EVIDENCE FROM A NATURAL EXPERIMENT IN INDIANA
Matthew J. Kotchen Laura E. Grant
Working Paper 14429 http://www.nber.org/papers/w14429

-Chris

But the problem with this model is that there's no way for a grad student to publish a negative result if they fail to replicate the results. To compound the problem, if a student starts getting negative results, they will quickly change their course of research to something that may produce results. PhDs are not granted for negative results - there is little incentive to pursue research paths that aren't fruitful.

In the end, the student will know original the result is questionable, but the scientific community will not.

-Chris

Look, I use open source all the time and have contributed to many projects and ran a few. I love open source just as much as the next slashdotter.

BUT, broad statements like "open source will fix healthcare.gov" don't add anything to the conversation. What if it was built on open source and it failed? Would we be making the same claims about commercial software? "If only they had used WebSphere and DB2!! Everything would have been wonderful!".

No. No. And. No.

As many people have already pointed out, the problems with healthcare.gov are mostly the same ones that plague many large scale IT projects. Insufficient testing, complex interactions between many existing complex systems (which are hard to get right), consultants that get paid for code delivered, working or not, and so on.

Now, TFA actually makes the argument that healthcare.gov as an _open platform_ would be a good idea. It goes on to point out that that's one thing that makes some of the bigger web apps successful: they are platforms for building apps rather than apps themselves. How much of that is true is open for debate (is google really a beautiful platform or is it a bunch of hacks held together by duct tape? only google engineering knows for sure...) , but as a goal, healthcare.gov as a platform isn't a bad idea.

However, platforms don't just materialize from thin air. In fact, building a platform before you have apps is a recipe for failure. It's usually only after the third or fourth app that the patterns emerge that make a platform possible. It takes time for good platforms to evolve.

Given that, designing healthcare.gov from the beginning as a platform would probably have failed, too. The developers would have created a wonderful platform for some vague requirements that likely didn't actually meet the needs of an insurance exchange at all.

From a pure software engineering perspective, what's happening right now isn't that bad. Version 1.0 launched, it had problems. Let's get working on Version 2.0 and maybe try out some new ideas. Then for Version 3.0 and 4.0, we can start thinking of a platform. The other important point here is that you have to plan for multiple versions and long term maintenance/evolution for software. The suggestion that healthcare.gov should have been run as a startup in the government rather than outsourced is probably the best idea for fixing the problem.

-Chris

Whoa there... Linux and most open source tools cost large amounts of money to develop. Look at the list of top contributors to Linux:

http://arstechnica.com/information-technology/2013/09/google-and-samsung-soar-into-list-of-top-10-linux-contributors/

Most of those are companies that are paying their employees to work on Linux. The sum of their salaries and the resources they require is a good part of what it costs to develop Linux.

Just for fun, let's estimate what the Linux kernel costs to develop each year. The actual report from the Linux Foundation lists the number of changes each organization made to the kernel. If you sum of the number of changes from commercial entities, you get 55,604 changes committed by paid developers. Assuming each developer contributes one change a day on average and assuming they work hard, that's about 200 changes/year/per developer. Dividing the number of changes by the changes per developer suggests around 278 full time developers are contributing to the Linux kernel. Assuming the average fully burdened cost for a kernel developer to be $250k, the cost for those developers is $69.5M/year.

tl;dr: The Linux kernel costs somewhere in the ballpark for $70M a year to develop. This is just the kernel, not the rest of the Linux ecosystem.

If those companies stop contributing to Linux, Linux goes away.

-Chris

I have to disagree with this.

Bugs in open source software can be fixed by _developers_, not any user. If you use open source software and are not a competent developer, you can't fix it. You can _pay_ someone to fix it, but at that point, there's a good chance your fix will cost more than a commercial alternative. If you do provide a fix, there's no guarantee that your fix will be accepted into the codebase. When this happens, you now have to maintain that fix with every new release, further adding to the cost.

I'd also like to get real data on the claim that lots of people look at bug fixes and vouch for them. I've been involved in a lot of open source projects and have found that this just isn't true. Even heavily curated projects like Boost don't necessarily get the scrutiny they deserve (I dare you to read the source for the Boost Graph Library or Spirit and say with confidence that they're bug free and secure, or even evaluate a patch submitted by one of the hard-core Boosters).

Just last week, I spent a few days going through the source code for Galaxy (a bioinformatics tool) since the documentation was almost non-existent. I'm pretty sure I looked over a number of bugs and security vulnerabilities and didn't catch them. For problems I did see, I don't have the time or resources to propose and execute fixes. And this is a tool that people are using in clinical applications.

It's easy to repeat sweeping claims about open source, but I'd like to see some real data to back up the common claims made to support open source over commercial tools.

-Chris

I don't have mod points today, so I'll reply and add some more supporting material. The parent's point on reliability is dead on.

When it comes to cost, we've done a lot of market research and internal analysis on the actual costs of basing a business on open source. When properly accounted for, open source can be much costlier than closed source alternatives. The basic reason is simple: open source software stacks take time to maintain.

Most organizations that use open source software have full time people dedicated to maintaining the software, just like organizations that use closed source software. However, in open source shops, the internal developers/analysts/etc (the _users_ of the software) also must maintain the software. This is where the hidden costs of open source lie. In many cases, using open source software forces everyone to become a developer, or at least a sys admin, whether they want to or not.

If someone's primary job is to analyze data for a business, they should spend most of their time either performing analysis, sharing results, or furthering their analysis skills. Instead, we've seen analysts (I work in genomics) that use open source software spend up to 80% of their time just maintaining their tools and working around limitations imposed by them. When commercial tools are available that perform the same function but without the hassle, few open source advocates will even consider them, even if the cost is significantly less than the cost of the time they spend messing with open source tools.

Oracle's probably not the best company to be leading this conversation, but it's important enough that the software community should engage in it. There was a time when commercial and open source solutions coexisted peacefully. It'd be nice to see some balance return.

-Chris

"It is why centrally planned economies don't work in competition with market economies. "

Market economies are centrally planned economies, with the rules that define the market being the basic plan for the economy. Without rules, markets would not function. The last 15 years (or 30, if you want to go back to 1980) have shown that market economies don't function any better for the general population than centrally planned economies. In both, wealth accumulates in the hands of the few that make the plan (rules).

-Chris

Follow the thinking for a second. Outbox* collects people's mail, scans it, and delivers it to them in "a beautiful digital format". Outbox is located in Austin. Its founder has spoken at Capital Factory. President Obama has also spoken at Capital Factory. President Obama's government runs the Post Office. Clearly, Outbox, Capital Factory, and the President are going to replace the Post Office with Outbox.

Makes as much sense as the OP. Happy Friday!

*(I have no affiliation with them, I just live in Austin and see their silly cars driving around collecting people's mail and wonder why seemingly sane investors gave them money - I think this post answers the question!)

More important than the actual runtime environment is that fact that in any networked application that processes lots of data, _latency_ is the bottleneck, not the actual performance of a well implemented* algorithm. The latency between servers, between RAM and the CPU, and even between L3 and L1 (hell, even from L1 to the registers) will have a larger impact on the overall performance than the actual language used. Round trips to and from memory (either local or remote) are what kills performance for most code**. Good programmers know this and optimize for these latencies when implementing an algorithm, regardless of the language.

Even in a low latency environment, well implemented algorithms in scripting languages can outperform poorly written C/C++ and Java. In the financial world, those guys are laughing all the way to the bank (true story).

-Chris

*assume for the sake of discussion that both the Java and C++ implementations are done by good programmers who know how to optimize in their target language.
**remember, round trips occur every time you call a function/method and the stack has to be saved... it's not just data access that triggers this.

You can also do it in minutes with common household items: http://learn.genetics.utah.edu/content/labs/extraction/howto/

Extraction's not the problem. Sequencing is not actually a problem, either (~$150k gets you an ION Torrent Proton that will come close to sequencing a person in a few hours). Data analysis is currently the hardest and costliest part of sequencing. Of course, that's getting better, too.

Don't get me wrong, incremental process improvements such as this are important, they're just not groundbreaking anymore.

-Chris

Since this thread is about hiring talented developers for fun projects, I'll throw this out (using the criteria from the parent):

Interesting: genome sequencing (an actual "big data" problem that's not just about selling stuff to people more effectively)
New location: Austin, TX

http://www.lab7.io/jobs/

-Chris

I run a bioinformatics software company, have been in the field for over a decade, and have worked in scientific computing even longer.

I'll start with a quick answer to the bubble question: there are already too many 'bioinformatics' grads but there are not enough bioinformatics professionals (and probably never will be). There are many bioinformatics Masters programs out there that spend two years exposing students to bioinformatics toolsets and give them cursory introductions to biology, computer science, and statistics. These students graduate with trade skills that have a short shelf life and lack the proper foundations to gain new skills. In that respect, there's a bubble, unfortunately.

If you're serious about getting into bioinformatics, there are a few good routes to take, all of which will provide you with a solid foundation to have a productive career.

The first thing to decide is what type of career you want. Three common career paths are Researcher, Analyst, and Engineer. The foundational fields for all are Biology, Computer Science (all inclusive through software engineering), and Statistics. Which career path you follow determines the mix...

Researchers have Ph.D.s and tend to pursue academic or government lab careers. Many research paths do lead to industry jobs, but these tend to morph into the analyst or engineer roles (much to the dismay of the researcher, usually). Bioinformatics researchers tend to have Ph.D.s in Biology, Computer Science, Physics, Math, or Statistics. Pursing a Ph.D. in any of these areas and focusing your research on biologically relavent problems is a good starting point for a research career. However, there are currently more Ph.D.s produced than research jobs available, so after years in school, many bioinformatics-oriented Ph.D.s tend to end up in Analysis or Engineering jobs. Your day job here is mostly grant writing and running a research lab.

Bioinformatics Analysts (not really a standard term, but a useful distinction) focus on analyzing data for scientists or performing their own analyses. A strong background in statistics is essential (and, unfortunately, often missing) for this role along with a good understanding of biology. Lab skills are not essential here, though familiarity with experimental protocols is. A good way to train for this career path is to get an undergraduate degree in Math, Stats, or Physics. This provides the math background required to excel as an analyst along with exposure to 'hard science'. Along the way, look for courses and research opportunities that involve bioinformatics or even double major in Biology. Basic software skills are also needed, as most of tools are Linux-based command line applications. Your day job here is working on teams to answer key questions from experiments.

Bioinformatics engineers/developers (again, not really a standard term, but bear with me) write the software tools used by analysts and researchers and may perform research themselves. A deep understanding of algorithms and data structures, software engineering, and high performance computing is required to really excel in this field, though good programming skills and a desire to learn the science are enough to get started. The best education for this path is a Computer Science degree with a focus on bioinformatics and scientific computing (many problems that are starting to emerge in bioinformatics have good solutions from other scientific disciplines). Again, aligning additional coursework and undergraduate research with biologists is key to building a foundation. A double major in Biology would be useful, too. To fully round this out, a Masters in Statistics would make a great candidate, as long as their side projects were all biology related. Your day job here is building the tools and infrastructure to make bioinformatics function.

All three career paths can be rewarding and appeal to different mindsets.

If you haven't followed the NPR series on gene sequencing over the last few weeks, it's definitely worth listening to. I also did a talk a few years back at TEDxAustin on the topic that makes the connection between big data and sequencing ( http://bit.ly/mueller-tedxaustin ). Affordable sequencing is changing biology dramatically. Going forward, it will be hard to practice some parts biology without sequencing and sequencing needs informatics to function.

Good luck!

-Chris