One in Three Farms Is Using FarmLogs
techcrunch.com
techcrunch.com
I'm sure it seems like an impressive stat to throw out there, but it's a lot like saying they're offering a million shares of options to new employees; without the total number of shares we don't know what that means.
In the US, at least, I believe that particular example would be considered a "ranch" rather than a "farm".
E.g., "good" in what way? That there's less manual labor now? (Not a function of having more land.) "Good" in the sense that ag companies tend to make more money on larger farms? "Good" in the sense that yields are (generally) consistently up? (Also not related to having more land.)
To make "good" meaningful you must strictly define what's "good", realizing that there are almost always other (possibly contradictory) criteria, and that what might be "good" in one sense may be "bad" in another.
In any case, my point was that "improvement" has a solely positive connotation. You could have said "8x improvement in farmed acreage", which sort-of implies an increase in acreage is "good", but why not just be accurate in the first place, and call it precisely what it is, which is an increase in average acreage?
I guess I wanted to combine both an objective and subjective assessment in a single word, which admittedly while not precisely accurate, got across my meaning.
I was actually hoping you were going to give me a traditional marxist response that we should not seek to decrease the amount of labor per unit of production, (that decreasing the amount of work per bushel of wheat is not an improvement) - I had an answer for that!
Tragically for our "argument" I believe doing less work for the same output is a good thing, at least in general. But even that has associated costs that aren't always "good" given current conditions :/
I'm still involved in farming, and the guys I know who are "using" it, just are using the basic functionality.
Unless they have partnerships, FarmLogs is going to have a difficult time competing with Deere, Case/IH, other equipment manufacturers who are developing their own built-in products with similar feature sets and deeper pockets. Not to mention the local cooperative monopolies, seed companies, etc who are also in the game.
Having known many farmers over the years, I can only think of one who would really have a use for this. The rest would probably just dismiss it without much thought.
There's still seems to be to much of a focus on farmers having to manually enter data. Our machinery already records everything that happens in the paddock, there's no reason why we should have to sit down and manually enter everything we do. Farmlogs should connect to whichever machinery provider we use's API, and pull all the data straight from the machine. It's now possible to do that in real time, and it opens up far more interesting opportunities, (for example optimising variable rate maps in real time) as we can also push data back to the machines.
How do I connect and use my local weather station data within FarmLogs? One limitation of our current yield prediction software is that it's weather data feed comes from a BOM station nearly 30km away, that isn't nearly good enough, so we're seeing a transition to on farm weather stations. Ultimately we need to be able to collect weather info on a field by field basis, not only for crop modelling and yield prediction, but to better optimise harvesting/swathing schedules, and make more effective N applications (we can create better application maps based on the yield models + predicted weather).
Can I import my all my soil data? We've had extensive EM38 mapping, radio-metrics and soil testing done over the farm to better calibrate our yield models, and improve nutrient application, how do I put that data into FarmLogs? If I can, how do you use it? Can you generate my VR maps based on soil data + predicted weather information?
I'm also seeing some features that most farmers I know will never use. We don't need "another" calendar. We don't need to keep a record of all the grain we have stored in silos, or upload information about every piece of machinery we have on farm. What benefit does that give us? It seems like your almost trying to gameify farming with all the graphics..
I think tools like FarmLogs need to move away from just data collection/consolidation and much more towards yield prediction/modelling, and giving recommendations/optimising nutrient applications. We spend more than $500'000 a year on fert/chemicals, so if you can help me make a more precise variable rate map and save me 10% of that figure, thats something I'm going to use. Even if your charging me $5000/10'000/x'000 a year for it.
There are lot of challenges in this area. There are no open data standards and probably most farms in our target market do not have access to that type of equipment. Or if they do, they don't have great records of it. For them we offer a sort of progressive enhancement. We've licensed five years worth of satellite imagery to give us reasonable baselines of precision field performance history. And while we also need management decisions for our models, we can make use of manually entered data as well as machine generated precision data.
Over the summer, we piloted some products built from these models with great results, and will be announcing them soon. We're really excited about it.
[0] http://stackshare.io/posts/how-farmlogs-is-building-software...
They're one of the many success stories in the community of startups who have chosen Clojure as their primary weapon. (See also: Climate Corp, now owned by Monsanto.)
Lisp is having its victories, here and there, but notably in meaningful and economically real ways.
Edit: They DO NOT use ClojureScript, sadly. Unlike say, CircleCI or Prismatic, who both have very compelling stories with regard to using Clojure from the front to the backend.
Which is exactly what's so compelling with regard to ClojureScript and say Om or any one of the React wrappers out there: you guys already use Clojure and ClojureScript and its libraries are incredibly pragmatic and designed for "real work". CoffeeScript would seem more like language play than ClojureScript, but of course I'm speaking as an outsider. :)
Also if you haven't already, take a look at David Nolen's recent talk on Om Next[1]. Personally if I were using Clojure on the backend, I'd be pushing hard for it on the frontend too.
We handle iOS push notifications with Ruby, a lot of data and image processing with Python, and even run .NET/Mono in a few areas. Our stack is very diverse and we do a really great job considering what the best technology for a particular problem might be.
Clojurescript is certainly interesting, but I wouldn't consider it a shame that our front-end isn't built with it. I love programming but at the end of the day you gotta remember that code is really just a means to an end.
What possible reasons could there be for giving that up?
(See my other comment below as well.)
So basically, it's JavaScript with a compile step that doesn't do static analysis.
But back in 2012 when the first lines of FarmLogs were written, it was pretty cool. And that's a lesson in itself about why it really doesn't matter what stack you use.
Not everything needs to be in an enterprise grade multi-node C* cluster to be big data!
I did see a job listing that noted "familiarity with stuff like Hadoop" (paraphrasing). So it seemed to cast doubt on them using Hadoop, but it neither served to confirm nor deny.
Also, nice pun.