I had worked at Edenworks as a software engineer for a few years, alongside Johnny. I don't pretend to know enough to speak on manufacturing itself, but Johnny's remarks on software development are spot-on.
When I had come onboard, I had naively suspected a typical software startup experience; rampant technophilia with an obsession for integrating the freshest software technologies. If 'Software is King' is true everywhere else, why shouldn't it be true here?
Edenworks is not a software startup, however, and it's important to realize that. Manufacturing is an entirely different beast, which makes steady, deliberate movements (i.e. it doesn't move fast, and it shouldn't break things). When the main product being developed is a tangible system, redos are way more costly. Adding flashy software features does not expedite this; lashing the latest and greatest Javascript library onto the fronted does not add value... not reliable value anyways.
When it comes to developing a manufacturing process, software should be flexible and let the process demands come first. The typical workload is more concerned with running test trials than hacking up something new.
For me, this realization was more emotional than organizational - sometimes you have to curb your hype. To add real value to the product, I had to watch my ego. In a manufacturing company, the Process is King.
Even when primarily doing software, this can come into play.
I know of a customer who had about 5000 card readers in an access control system, where bugs in the card reader firmware required a firmware update. Doing this required walking to a reader, unmounting it from the wall, updating the firmware, re-mounting the reader. Rinse and repeat 5000 times.
A rough estimate is that upgrading all the readers on the site took about a man-year of technicians walking around updating things. Let's just say that when more bugs were discovered, the customer who paid for it all was less than pleased…
Lesson learned: always make secure remote firmware updates possible on your devices.
Lesson apparently not learned: get it right first time.
Software isn't special
The quality of a system is a direct function of the speed of the testing cycle. To argue "slow, methodical, reasoning" is to argue against quality.
Especially after some recently problems with my hardware business that necessitated the return of some units for repair, and the hold-up of manufacturing while we worked out what was wrong, I've come to realise that the easily-updateable nature of modern day software really gives us such power and flexibility, it should never be taken for granted.
This indoor farm, EdenWorks, has a nearby competitor, AeroFarms, in Newark.[1] AeroFarms claims to be much bigger, and claims a new patented technology for growing plants on a cloth substrate made from recycled plastic bottles, with the plant roots in a nutrient-enriched spray mist instead of water or soil. (AeroFarms may be exaggerating how far along they are. See Google StreetView.[2]) Welcome to manufacturing, where it's about volume and price.
[1] http://aerofarms.com/ [2] https://goo.gl/maps/amxpekwPEGr
These indoor farm outfits have nothing to do with lettuce. There's a reason they're building them in/around NYC, aka in the densest concentration of pot smokers the world has ever seen, far from Humboldt county's fields and Colorado's manual hydroponics.
The business model is just to get the automation figured out with some low-value crop, e.g. salad greens, while waiting for the legislature to decriminalize. The day Albany finally comes around to the idea, they'll retool for sticky green weed faster than you can pin up a Bob Marley poster.
It'll take them about fifteen minutes after the governor's signature dries to get the first pot plants started. The economics could not possibly work out for lettuce alone.
It might be that these producers expect higher human-labour costs, making automation more profitable - such as due to rising nationalism reducing the supply of cheap migrant labour.
[1] http://qz.com/295936/toshibas-high-tech-grow-rooms-are-churn... [2] http://www.japantimes.co.jp/news/2014/05/13/national/science...
I'm sure some of the stuff learned doing this would be useful, but why not just start an actual robot ganja farm in Colorado now and get growing?
Tomatoes, specifically determinate tomatoes, expect almost the same nutrient mix as hemp, has the same size root systems and grows to about the same height. Harvesting is also similar.
Hence: If they were planning to retool for weed, why are they building manufacturing capability for a completely different kind of production?
My first thoughts about this article were just as you say - how can that pay off?
Now I get it.
If you're looking for a formalized system designed to help with some of this, take a look at TRIZ[1][2]. I'll just steal one note from the "What Is TRIZ" article - "Somebody someplace has already solved this problem (or one very similar to it.) Creativity is now finding that solution and adapting it to this particular problem."
A big part of the basic tooling for TRIZ is the results of people going through a huge mass of patents looking for patterns of problem categories and how they were solved.
[1] https://en.wikipedia.org/wiki/TRIZ [2] https://triz-journal.com/triz-what-is-triz/
Do you have experience with TRIZ? What "is it" to you?
TRIZ is a way of breaking down an engineering design problem into the thing you want to change, and the thing you can't change (a "contradiction"), then resolving it. A "TRIZ Matrix" is a reference tool that suggests ways of resolving conflicts between common design parameters (strength, weight, durability, manufacturing tolerance, etc.) based on a number of principles that have been validated over the years, like "nesting" or "prior action". Over the years, 40 standard principles (and 39 parameters) have emerged. They all have somewhat cryptic, consultant-handbooky names but make sense when you see some examples[1].
E.g., you have a beam and you want to make it stronger, but can't make it any thicker. You consult your matrix for "strength" vs "area" and get some suggestions such as "use composite materials". Or, applying the principle more generally, you try to extract techniques from the patent library or publications that resolve the problem.
[1]: https://www.triz.co.uk/files/triz_40_inventive_principles_wi...
Probably in part because of the background of the creator and the problem datasets used for the traditional contradiction matrix it always seemed to me to be a better fit for manufacturing and physical goods.
The "Interactive Contradiction Matrix Beta" linked at the top of the TRIZ Journal site may be worth looking at, but it's kind of cryptic. Basically you pick out a few areas of concern - as an example I picked (on both axes) 1: Weight of Moving Object, 9: Speed, 15: Duration of Action of Moving Object, and 27: Reliability. Based on that, the recommended areas that I should be looking at for possible improvement potential would be 35: Parameter Changes (turns up 6 times), 3: Local Quality (5 times), several others at 4 times, etc. Hitting the Analyze button on that tool will give expandable examples for the various areas - for example "Parameter changes" includes a lot of changes to temperature, state (solid/liquid/gas) and consistency. An example might be making liquid-filled chocolates - do you have to fill the chocolates? Can you have frozen chunks of filling that you coat with chocolate instead?
If so, do you think it's because manufacturing is a more well-defined and mature field than software engineering?
Manufacturing is ancient. Software as a field has been around for 45 years (give or take). If you're not working at a pure software company, the software for your particular field is probably in its infancy.
If you're looking to innovate, it is orders of magnitude more fruitful to look to the software improvements which can be made to your technology because orders of magnitude fewer man-hours have been spent by humans so far solving those problems.
"In indoor farming, we see a lot of competition focus on how data will drive yield increases, yet they haven’t figured out how to regulate air temperature in their facility." I have to assume that these competitors are looking for the innovations that will make them 10x more competitive. Startups are dead by default. Innovation is the only way to survive.
A simple example from my personal life is writing down exercises I do at the gym. I was surprised by how many different type of exercises there are. At first it was just "lat pull down, 80 pounds, 3 sets, 10 reps". Then I tracked different manufacturers, to stay on top of machine differences. Then I started tracking number of attempted reps, along with reps at lower weight. Then I made a note for weights per arm, for machines with independent weights on each side. Then I took into account the base weight for the bar. I could add features forever.
To manage the complexity, I started looking at software to help. I decided to scrap the idea of building software in favor of writing exercises on a sticky note I stuck to my wallet, and later migrating the data to a "good enough" spreadsheet.
Software is meant to serve us. If you let it take over, it will. Manufacturing benefits from software in places, but sometimes a pen, sticky, and spreadsheet is all you really need, and if you outgrow it, you'll understand exactly how software can help.
My uncle and 101 year old grandfather make machine parts in a shop with a bunch of old school analog stuff. They have a computer for a milling machine. It all works great.
http://www.joelonsoftware.com/2005/12/13/how-to-ship-anythin...
How many companies hired temps to fill out forms for these types of tasks? Plenty I'm sure!
Belkin WeMo comes to my mind as a prime example as their app is slow and buggy. Philips Hue lightbulbs I've bought my for parents last christmas can be another one - lightbulbs themselves look and work nice but the software is (imho of course) buggy, unintuitive and incomprehensible.
Your software will only be as good as your process. There are mid-market ERPs that are 30 years old or more (specifically, Dynamics NAV comes to mind). These software solutions implement the processes that have been honed by humans for more than a thousand years. It is much easier to innovate elsewhere. I am curious which specific ERP packages you have found to be innovative.
When I read this an instant thought was the software you develop is also a constraint on your process. Really easy to paint yourself into a corner.
But once you've decided you must customize some hardware (or even distribute it), the article is claiming that the software is the last thing on your entire solution that you should work on. You should get everything else right first.
I don't think those contradict each other.
Competitor teardowns is another good one, but what information do you use for that? How do you determine who their suppliers are?
• visit their website
• buying their product and looking it up the parts online
• talk to your vendors
For the last one, this is particularly relevant if you're buying in a market with few suppliers.
"""A good, defensible manufacturing strategy is one where you’re applying and protecting (ideally via patent) a faster, cheaper, more reliable way of doing something in your industry, by borrowing a proven approach from a parallel industry."""
I very strongly disagree with this and find the thought process very unnatural. Patenting something you copied almost feels like it's against human nature to me. Humans essentially learn via copy and improve. Thankfully business practice patents are not valid in some countries.
I also disagree with the thoughts on not focusing on software or at least think the author undervalues the potential role software can play. I think some of the major problems in production management are very ripe for algorithmic innovations. Plant layout planning and job scheduling (basically most operations research) seem very suitable to AI/learning based approaches. Non trivial simulations are also very important for well run production companies (anecdotally, from the ERP development experience).
Strawman. That's not what your OP's quote says.
"""borrowing a proven approach from a parallel industry"""
I've translated that to copy+improve. I mean what if that approach was patent protected? How would you go about borrowing that proven approach?
We are producing a series of vending-machine-like service locations which automatically prepare and retail hot meals from fresh ingredients. We have of course the manufacturing process for these machines to keep in mind, but in addition the machines themselves are essentially miniature factories and so all of the theory, literature and best practices of the manufacturing economy proper apply - albeit scaled down in time, space and (usually!) cost - to our machines.
So far it has been very interesting to read the literature of other engineering disciplines and to translate concepts between them and our experience in software. Thus far I believe there are some great processes that software can teach manufacturing, but also vice versa.
Applies to software just as well :)
You want, in priority order: 1) The least interactions 2) The simplest interactions 3) The simplest components
"Everything shoukd be made to be as simple as possible, but no simpler." -einstein
this shouldn't detract from the complexities of manufacturing vs software
1) Product (will people buy it?)
2) Process (can you scale it?)
3) Software (now scale it)
On the other hand in manufacturing having a big recall for a defective or incomplete product usually means "instant bankruptcy".
Even big companies like Samsung(Galaxy recall) or Volkswagen(Dieselgate) or BP(Deepwater oil spill) have to suffer immense loses from "moving fast and breaking things".
.... and you are going to fuck things up anyways. But hopefully not in a terminal way. Some fuckups are learning opportunities, some fuckups are because you don't learn the right things from previous "learning opportunities".
Unfortunately, some of my kids have a propensity for repeating what they read/hear, without consideration for our rules regarding coarse language. So it wouldn't work well in my case.
As far as it being "just a[n] rhetorical device", I think we probably have difference in values, which I don't think can be fruitfully discussed in this forum.
