Question: Can we as developers learn from the processes of the
manufacturing industry? Can adopting their processes increase the
success rate of software development?
Answer: Yes, of course. There are many lessons that software developers can learn from manufacturing despite the fact that software development is a creative process. Software development is itself a process, and it includes many other processes. The better you can define and control those processes, the better you can control the process of software development overall. That doesn't mean that you should prescribe every keystroke a developer makes; it just means that as a developer, you naturally perform tasks in a certain order, and those tasks can often be managed. Here are some examples:
defect tracking: When a bug is observed or reported, what happens to it? Do you write it down on a scrap of paper and stick it on an 'investigate' spike? Do you later remove those scraps one at a time, investigate them, and eventually move them to the 'resolved' spike? If you do that without fail every time you get a bug report, you've got a well-defined, measurable process, and you're probably much better off than someone who has a fancy, high-tech defect tracking system that's so onerous that some team members track bugs other ways, or not at all.
version control: There's a good chance that you use version control where you work, and version control is obviously a lot more useful when everyone uses it the same way.
product design: Do you decide which features to implement by throwing darts at a wall covered with post-it notes? If so, you've got a process. I don't think anyone would argue that it's a great process, but at least it's a starting point. If you change the process how can you know for certain that your change was actually an improvement unless you measure before and after? You can't.
code reviews: Would a code review be useful if the review process and coding criteria changed for each review? Of course not.
software development life cycle: The whole analysis -> design -> implementation -> test -> maintenance cycle is a process that should be defined clearly.
In each of these cases, having a process in place lets you measure inputs and outputs and determine whether changes you make have the intended effect. Not having processes in place means that you're just guessing when you try to improve the way you work. This is really what manufacturing is all about, and it only makes sense to borrow the successive refinement tools of manufacturing when they're appropriate.
There's an entire field devoted to defining and improving processes used to create and maintain software; it's called software engineering. It's no surprise that you have questions about the development process while reading about CMMI -- CMMI is a product of the Software Engineering Institute.
Software development has already adopted many manufacturing concepts:
It's hard not to see the influence of Eli Whitney's interchangeable parts on both OOP and component-based development.
Project management techniques used in software development aren't very different from those developed for manufacturing. As just two examples, the software world has only recently adopted the Kanban concept that was developed decades ago at Toyota, and Gantt charts were used in manufacturing long before the first electronic computer was built.
Quality management methodologies like Six Sigma that were developed for manufacturing have been adapted to software development.
Despite the heavy process driven environment, the developer must engage in
creating things "on the fly".
Are you telling me that someone is going to decide on their own to add a patch to the facial recognition package, and they're going to add it into the production build without first creating an issue in the tracking system, having the design reviewed, checking the code into version control, or having the testing folks look at it first? Our process requires those things for some very good reasons. If by "on the fly" you mean "outside the process," that's unacceptable.
Doing things on the fly is against the spirit of manufacturing.
Again, if "on the fly" means "outside the process," you're right. But if you think that manufacturing doesn't require quick thinking and developing creative solutions to problems, you're wrong. All kinds of problems come up in the manufacturing process -- the cupcakes don't have enough cream filling, painted surfaces suddenly stop passing QA's scratch test, 20% of finished parts are missing an important retaining ring, the dough mixing system has broken a critical part...