My big problem with this study is that the project sizes and teams are too small. Static typing really starts to get it's power as the team and project get bigger. This is especially true as the skill levels from larger teams start to spread from amazing all the way down to terrible. In smaller teams you can often work with higher quality developers, but with larger corporate systems, you don't have that luxury. You have to deal with all kinds of experience levels, etc. You need to be able to modulize the project, etc.
From my personal experience, dynamic typing usually works well with 1-2 developers and continues to be useful until about 4-5 developers (static typing too for that matter). After that, static typing usually wins pretty consistently.
My personal preference is static typing. I find it makes the code more readable and catches a lot of oopses early, at compile time. Otherwise you just end up writing a ton of test cases and hope to catch the same issues at runtime. So you have less protection (you have to catch it with a test), and you just end up spending more time writing tests anyways.
I do understand the benefits of both, I just prefer static typing because of the way I work. Both work and have their places. Like everything else, you need to use the right tool for the right job AND the right people.
I don't think the size (or the revenue) of the company matters as much as the size of the projects that you're working on within those companies.
Someone mentioned maintenance, so I will also ask how old the codebases that you're working on are? For dynamic typed languages, as the code grows older (with more bug fixes and add-ons and one-offs) then it gets harder and harder to maintain as 100% error free (let alone debug).
I will also throw in the fact that doing software library version upgrades on dynamically typed systems is a pain in the ass. Some code branches have system level calls changed, and unless you have very good unit test coverages (which may or may not need to be re-written on a library version upgrade) then you may or may not catch the problem during the upgrade. With a statically typed language, a static analysis tool can tell you exactly where and how the library or interface upgrade affects your codebase.
"I will also throw in the fact that doing software library version upgrades on dynamically typed systems is a pain in the ass."
This is very true, but you gain a lot with dynamic languages in other areas. The last company I worked for had about 300 programmers in the office I was in. Roughly half did Java and the other half did Ruby. I was one of the few that moved between both ruby and java projects. I did not see these great benefits of static typing that people always insist exist for large teams at large companies.
Have you also used dynamic languages extensively as part of large teams at your employer? Dealing with lots of people over long periods of time is messy, no matter what language/tool you use. I think the claim is just that static typing gives you better results than dynamic typing. All relative..
From my personal experience, dynamic typing usually works well with 1-2 developers and continues to be useful until about 4-5 developers (static typing too for that matter). After that, static typing usually wins pretty consistently.
My personal preference is static typing. I find it makes the code more readable and catches a lot of oopses early, at compile time. Otherwise you just end up writing a ton of test cases and hope to catch the same issues at runtime. So you have less protection (you have to catch it with a test), and you just end up spending more time writing tests anyways.
I do understand the benefits of both, I just prefer static typing because of the way I work. Both work and have their places. Like everything else, you need to use the right tool for the right job AND the right people.