|
I think is a bit nuanced than that and there is a clear reason why a manager might go for a contractor instead of in house. A good manager will have a clear understanding of his slice of the company, what work needs done, what are the hoops, what problems can arise, how the work needs done. Same manager most likely has no understanding what it means to build, deploy and maintain a hardware + software thing. And since we are talking about a good manager, they are aware of that. Hence they call for a contractor that will build, deploy and maintain said thing. And lets face it, will these tinkering workers actually able to deliver a robust system? You already mentioned the lack of integration or architecture concepts. The red tape might be there to prevent data corruption. What user interface are they going to use? Fragile touchscreen or a big button to mark the end of the step (eg, after the worker finished mounting the mud guards). Will that button/touch screen survive the number of mud guards that need to be mounted every year? Or that prosaic issue: where do you store the spares? etc etc There is a reason why this kind of innovation, like automatic testing, deploying etc, happen in software companies, building, deploying and maintaining software is the core competency. I don't doubt there are happy cases where the tinkerer is more than a tinkerer, the video we are commenting on proves that. On the other hand, this sort of thing should be encouraged. Have the workers come up with POCs, then pass that to the expert contractor to help with the extra bits. When the startup I work for decided to pivot, I suggested to build a framework to help with automation: have a server that boots remote thin clients and have a basic client that you can plop all kinds of peripherals in. I had to use cases in mind: automation for small factories and bar/restaurant management. We decided to count trees instead. |