5 ms·

> The limit to automation in this industry and others is, quite frankly, how bad these companies are at making software. Your statement contradicts the rest of

by fizixer 10y ago

> The limit to automation in this industry and others is, quite frankly, how bad these companies are at making software. Your statement contradicts the rest of your paragraph (that the article is naive and far fetched). Because if this is really true, then it's only a matter of assembling a good software team, with one or two domain experts (who know the domain and are good s/w engineers), pair it up with the team of engineers and line workers, and a successful automated system can be built, i.e., exactly what the original post is talking about.

leereeves 10y ago
Automation as defined by that comment is a really low bar. It probably is possible. > That means an engineer can design an oil well at his desk. With the press of a button, an automated system would identify the equipment needed from a supplier, create a 3D model and send instructions for building it out into the field, Hashmi says. “That is automation.” I'd be very surprised if that doesn't already exist: printing a 3D model, submitting an order for the parts, and sending the documentation to the field. That's assuming the engineer has identified the parts and written the instructions. Automatically doing that might be more of a challenge.
- XorNot 10y ago
  It's not hard to imagine a search engine which matches mechanical descriptions of parts to a proposed design automatically. Just draw roughly what you need, punch in the specs, and let the expert-system provide a least-cost bill-of-materials which comes nearest the ratings + a list of custom parts.
  - ArkyBeagle 10y ago
    Who is going to do provenance on the parts list? You know that all organizations that buy parts have an entire fleet of people to do this, right? It goes all the way from vendor accounting to physical inventory to finance to shipping to engineering to production to...
  - ryanmarsh 10y ago
    OMFG the hubris. I don't know where to start. Oil and Gas exploration and production are a Hard Problem. Visit the Offshore Technology Conference sometime.
- semi-extrinsic 10y ago
  > printing a 3D model, submitting an order for the parts, and sending the documentation to the field. Hahaha. No, let me talk you through it (assuming we are talking new technology, as opposed to a small refinement of existing stuff): Engineer sits at his desk/wherever and has an idea for some equipment. We're at TRL 0 (following API 17N). Engineer spends some time demonstrating and documenting how it's likely that this solution will work, possibly involving CFD and/or FEM work. We're at TRL 1. Engineer gets a simple scale model built, and the scale model is laboratory tested to prove that the concept is likely to work. We're at TRL 2. Engineer gets a (downscaled and/or simplified) prototype built and tested over a limited range of operating conditions. We're at TRL 3. Engineer (but really, now we're talking the company) gets a first full scale version built, and this is tested at realistic operating conditions. TRL 4. The full scale version is integrated with the actual system which it will be running in. TRL 5. This is basically "first deployment", and you've probably spent a few hundred thousand dollars at this point, if not much more. Your first deployment case has run for an extended period of time under a range of real conditions. TRL 6. The solution is now proven, and can be promoted to other facilities that don't want to be the first adopter. Your technology has run for a significant amount of time at several installations under a wide range of conditions. The technology is now proven. TRL 7.
  - leereeves 10y ago
    According to the article, what I quoted is what Hashmi described when he said “That is automation.” If that's what he's talking about, I think it's possible if not already in place. But I agree, replacing all the testing and the skills of an entire company is another matter entirely, and there is certainly a lot more to be done than was described in the comment I was talking about.
ArkyBeagle 10y ago
It is not a matter of assembling a team. It is a matter of corporate culture. You can't bolt software on to an organization like that. They simply do not understand, deeply and utterly. It might be willfully. Just identifying defects clearly can be quite a bit beyond some people. But I heartily recommend that you try it. You will learn a lot about humanity.
- ryanmarsh 10y ago
  This. It's SO HARD to recruit good teams and even when you do projects fail because of the impedance mismatch between software development and bureaucracy.
  - ArkyBeagle 10y ago
    Bureaucracy has to do Real Work(tm). Gor bless 'em :) Leadership of tech, especially disruptive tech, is SFAIK mostly half black art and half blackmail.
ryanmarsh 10y ago
You do realize that "assembling a good software team, with one or two domain experts ..., pair it up with the team of engineers and line workers)" is like kryptonite for these people right? It's impossible. I've seen them try over and over and fail. The one time I saw a client assemble a great software team with great domain experts we had project managers who wanted to rescue the project from the jaws of success. We fought back, that system went into production and the company laid off scores of high-pay office workers in Houston. So yes the only thing standing between BACK-OFFICE people and their jobs is how bad these companies are at making software and believe me they are bad. Furthermore, out on the drill/job/construction/plant site robots are not going to be taking anyone's job tomorrow.
- fizixer 10y ago
  > You do realize that "assembling a good software team, with one or two domain experts ..., pair it up with the team of engineers and line workers)" is like kryptonite for these people right? I don't care if it's a kryptonite for these people. My point is that if that's the problem, then automation is "technically" a solved problem! only that it has "managerial" challenges (and managerial challenges of white-elephant corporations are solved by small startups. So it may be bad news for big corporations, but it's good news for the progress of the rigging industry).
  - ryanmarsh 10y ago
    It is theoretically a solved problem, and yes, this is good news for more nimble companies. However the "managerial problem" as you call it is immense. It is almost intractable. Source: They hire me to fix the "managerial problem" Let me break this down. You build a company, any company, and it's core business is doing something, anything, OTHER THAN MAKING SOFTWARE. You get good at it, you get big. Internal processes and culture might be totally fucked to the individual observer but as a whole the organism is thriving in its environment. So if the company sucks at making software you can bet (that until this point) being good at software has not been critical for survival in its environment. Hell there are plenty of software companies that are horrible at making software and yet they survive because being good at making software is (for whatever reason) not required for survival in their environment (market). So you have all these companies that are really good at pouring concrete, or not paying insurance policies, or flying airplanes, drilling for oil. They all suck at software but WHO CARES. They buy technology from companies that make it better than they could and the rest they cobble together SOMEHOW. Now imagine you've reached peak: materials science, labor cost reduction, managerial science, globalization, etc... You and your competitors have all outsourced, matrixed, offshored, bought, invested, borrowed, hedged, and most of all deployed the best COTS tech available for your needs. What do you do now? How do you get an edge over your competitors? What space is left where 10x gains can happen seemingly overnight? Software. Companies are slowly arriving at this notion. The problem is they are these very uniquely tailored organisms and everything about their evolution seems almost tailored to suck at software. They throw immense sums of money at software projects. They hire the best firms in the business (they think) and it JUST DOESN'T WORK. Uber and AirBnB quickly gathered more respective capacity than their traditional competitors and it ALL JUST LOOKS SO EASY but these big companies with massive budgets can't make software to save their lives. Even some old software companies can't make software to save their lives. The problem is systemic: * Company wide HR practices are toxic to hiring good developers * Technical ability in leaders isn't respected * Complexity isn't fundamentally understood * The first-principles of software are like Klingon * Bureaucracy has an impedance mismatch with software development I could go on and on. The only clients I've had that have a chance of overcoming this inertia have leaders starting from th CEO on down drink the Kool-aid and decide that they want to become a tech company. These folks aren't perfect but they begin to reassess everything, compare themselves to companies that are great at making software and start cargo culting everything they can find. That begins to bring about the kind of change that might make them good at software. It's ugly, but its better than the status quo. Still, they are the precious few. The rest hire "agile coaches" like me and waste my time and their money and have a "snowball's chance in hell" of ever getting good at making software.

by fizixer 10y ago

leereeves 10y ago

Automation as defined by that comment is a really low bar. It probably is possible. > That means an engineer can design an oil well at his desk. With the press of a button, an automated system would identify the equipment needed from a supplier, create a 3D model and send instructions for building it out into the field, Hashmi says. “That is automation.” I'd be very surprised if that doesn't already exist: printing a 3D model, submitting an order for the parts, and sending the documentation to the field. That's assuming the engineer has identified the parts and written the instructions. Automatically doing that might be more of a challenge.

XorNot 10y ago
It's not hard to imagine a search engine which matches mechanical descriptions of parts to a proposed design automatically. Just draw roughly what you need, punch in the specs, and let the expert-system provide a least-cost bill-of-materials which comes nearest the ratings + a list of custom parts.
- ArkyBeagle 10y ago
  Who is going to do provenance on the parts list? You know that all organizations that buy parts have an entire fleet of people to do this, right? It goes all the way from vendor accounting to physical inventory to finance to shipping to engineering to production to...
- ryanmarsh 10y ago
  OMFG the hubris. I don't know where to start. Oil and Gas exploration and production are a Hard Problem. Visit the Offshore Technology Conference sometime.
semi-extrinsic 10y ago
> printing a 3D model, submitting an order for the parts, and sending the documentation to the field. Hahaha. No, let me talk you through it (assuming we are talking new technology, as opposed to a small refinement of existing stuff): Engineer sits at his desk/wherever and has an idea for some equipment. We're at TRL 0 (following API 17N). Engineer spends some time demonstrating and documenting how it's likely that this solution will work, possibly involving CFD and/or FEM work. We're at TRL 1. Engineer gets a simple scale model built, and the scale model is laboratory tested to prove that the concept is likely to work. We're at TRL 2. Engineer gets a (downscaled and/or simplified) prototype built and tested over a limited range of operating conditions. We're at TRL 3. Engineer (but really, now we're talking the company) gets a first full scale version built, and this is tested at realistic operating conditions. TRL 4. The full scale version is integrated with the actual system which it will be running in. TRL 5. This is basically "first deployment", and you've probably spent a few hundred thousand dollars at this point, if not much more. Your first deployment case has run for an extended period of time under a range of real conditions. TRL 6. The solution is now proven, and can be promoted to other facilities that don't want to be the first adopter. Your technology has run for a significant amount of time at several installations under a wide range of conditions. The technology is now proven. TRL 7.
- leereeves 10y ago
  According to the article, what I quoted is what Hashmi described when he said “That is automation.” If that's what he's talking about, I think it's possible if not already in place. But I agree, replacing all the testing and the skills of an entire company is another matter entirely, and there is certainly a lot more to be done than was described in the comment I was talking about.

ArkyBeagle 10y ago

It is not a matter of assembling a team. It is a matter of corporate culture. You can't bolt software on to an organization like that. They simply do not understand, deeply and utterly. It might be willfully. Just identifying defects clearly can be quite a bit beyond some people. But I heartily recommend that you try it. You will learn a lot about humanity.

ryanmarsh 10y ago
This. It's SO HARD to recruit good teams and even when you do projects fail because of the impedance mismatch between software development and bureaucracy.
- ArkyBeagle 10y ago
  Bureaucracy has to do Real Work(tm). Gor bless 'em :) Leadership of tech, especially disruptive tech, is SFAIK mostly half black art and half blackmail.

ryanmarsh 10y ago

You do realize that "assembling a good software team, with one or two domain experts ..., pair it up with the team of engineers and line workers)" is like kryptonite for these people right? It's impossible. I've seen them try over and over and fail. The one time I saw a client assemble a great software team with great domain experts we had project managers who wanted to rescue the project from the jaws of success. We fought back, that system went into production and the company laid off scores of high-pay office workers in Houston. So yes the only thing standing between BACK-OFFICE people and their jobs is how bad these companies are at making software and believe me they are bad. Furthermore, out on the drill/job/construction/plant site robots are not going to be taking anyone's job tomorrow.

fizixer 10y ago
> You do realize that "assembling a good software team, with one or two domain experts ..., pair it up with the team of engineers and line workers)" is like kryptonite for these people right? I don't care if it's a kryptonite for these people. My point is that if that's the problem, then automation is "technically" a solved problem! only that it has "managerial" challenges (and managerial challenges of white-elephant corporations are solved by small startups. So it may be bad news for big corporations, but it's good news for the progress of the rigging industry).
- ryanmarsh 10y ago
  It is theoretically a solved problem, and yes, this is good news for more nimble companies. However the "managerial problem" as you call it is immense. It is almost intractable. Source: They hire me to fix the "managerial problem" Let me break this down. You build a company, any company, and it's core business is doing something, anything, OTHER THAN MAKING SOFTWARE. You get good at it, you get big. Internal processes and culture might be totally fucked to the individual observer but as a whole the organism is thriving in its environment. So if the company sucks at making software you can bet (that until this point) being good at software has not been critical for survival in its environment. Hell there are plenty of software companies that are horrible at making software and yet they survive because being good at making software is (for whatever reason) not required for survival in their environment (market). So you have all these companies that are really good at pouring concrete, or not paying insurance policies, or flying airplanes, drilling for oil. They all suck at software but WHO CARES. They buy technology from companies that make it better than they could and the rest they cobble together SOMEHOW. Now imagine you've reached peak: materials science, labor cost reduction, managerial science, globalization, etc... You and your competitors have all outsourced, matrixed, offshored, bought, invested, borrowed, hedged, and most of all deployed the best COTS tech available for your needs. What do you do now? How do you get an edge over your competitors? What space is left where 10x gains can happen seemingly overnight? Software. Companies are slowly arriving at this notion. The problem is they are these very uniquely tailored organisms and everything about their evolution seems almost tailored to suck at software. They throw immense sums of money at software projects. They hire the best firms in the business (they think) and it JUST DOESN'T WORK. Uber and AirBnB quickly gathered more respective capacity than their traditional competitors and it ALL JUST LOOKS SO EASY but these big companies with massive budgets can't make software to save their lives. Even some old software companies can't make software to save their lives. The problem is systemic: * Company wide HR practices are toxic to hiring good developers * Technical ability in leaders isn't respected * Complexity isn't fundamentally understood * The first-principles of software are like Klingon * Bureaucracy has an impedance mismatch with software development I could go on and on. The only clients I've had that have a chance of overcoming this inertia have leaders starting from th CEO on down drink the Kool-aid and decide that they want to become a tech company. These folks aren't perfect but they begin to reassess everything, compare themselves to companies that are great at making software and start cargo culting everything they can find. That begins to bring about the kind of change that might make them good at software. It's ugly, but its better than the status quo. Still, they are the precious few. The rest hire "agile coaches" like me and waste my time and their money and have a "snowball's chance in hell" of ever getting good at making software.