I don’t understand what you mean by this. Software still requires both design and building, and they’re distinct tasks. Design is defining the problem and deciding how to approach it: what classes to write, what libraries to use, what the deliverables will be, etc. Build is writing the code, fixing bugs, deploying it, etc.
You are right. This is much more an administrative concern than a physical one—ad-hoc software deployment is merely bad practice, in manufacturing at scale it is actually impossible—but then again I can’t imagine automation software falling into the ad-hoc category. I am also skeptical of the value of bringing up how software is made at all, when the point is that it is really fast compared to physical products.
That is true, but remember that once the program is released there is close to no time before anyone can access and use it. Neither is there a limit to how many may use it simultaneously.
Compare this to the process which happens after a automated factory robot has been designed, or a tractor: The materials for the hardware has to be ordered, shaped, put together and tested. The unit has to be shipped to the customer who ordered it, in some cases it also has to be installed.
The lead time from first finished product unit to when the customer can use it is in orders of magnitude shorter when we’re talking software. This lowers the cost for implementation significantly which should lead to a greater adoption faster, assuming similar amounts of productivity gain.
I don’t understand what you mean by this. Software still requires both design and building, and they’re distinct tasks. Design is defining the problem and deciding how to approach it: what classes to write, what libraries to use, what the deliverables will be, etc. Build is writing the code, fixing bugs, deploying it, etc.
You are right. This is much more an administrative concern than a physical one—ad-hoc software deployment is merely bad practice, in manufacturing at scale it is actually impossible—but then again I can’t imagine automation software falling into the ad-hoc category. I am also skeptical of the value of bringing up how software is made at all, when the point is that it is really fast compared to physical products.
That is true, but remember that once the program is released there is close to no time before anyone can access and use it. Neither is there a limit to how many may use it simultaneously.
Compare this to the process which happens after a automated factory robot has been designed, or a tractor: The materials for the hardware has to be ordered, shaped, put together and tested. The unit has to be shipped to the customer who ordered it, in some cases it also has to be installed.
The lead time from first finished product unit to when the customer can use it is in orders of magnitude shorter when we’re talking software. This lowers the cost for implementation significantly which should lead to a greater adoption faster, assuming similar amounts of productivity gain.