|
|
|
|
|
by rexreed
1439 days ago
|
|
How do you get so far into a project before you even realize that you have such a show-stopper problem? Move fast / fail fast works with software because iteration times are quick and penalty per iteration is low. But just building stuff and hoping it works and then realizing major problems doesn't work so well with real-world stuff. Couldn't they have "workshopped" this with non-functional item to see what the real world roadblocks would have been before a deep investment? This is especially the case in high-risk unproven areas such as cleantech where the solution space is vast and potential problem areas significant. Any problem area can kill a project, so why are we progressing so fast to build first? |
|
I worked on a system once upon a time that fed steel balls into a ball mill. We tested it thoroughly in the workshop with the same steel balls used on the customer's site, but when we went to commission it, it jammed non-stop.
Turns out a hundred randomly selected balls won't contain most of the outliers that you'd get in even one tonne of balls, and when you're feeding 5 tonnes per hour, that's a lot of jams. We had balls with big craters in them, half-balls, balls with two halves offset by 50%, and everything in between. Not the kind of thing you could rely on rolling nicely.
Also, of course, when you ask a mill ball manufacturer for a sample, they might be inclined to send you the very nicest examples they can find, because they think you might buy their product...
Anyway, unless you're super careful about sourcing legitimate feed samples it's easy to think you're testing against the real product when you really aren't.