One should learn from previous experiences and previous mistakes. Even better, one should learn from others experiences and mistakes. In software development, we have been very good at adapting knowledge from other industries. This has been especially the case with the manufacturing industry. From the Taylorism to the more recently influences of Lean thinking, the software development theories and practices have borrowed a lot from the manufacturing industry.
But we need to be very aware of the differences in our industries. Manufacturing typically deals with repeatable processes, while software development is empirical.
In manufacturing, a repeatable process converts consistent inputs into consistent outputs. Repeatable means that the conversion of inputs to outputs can be replicated with little variation. In repeatable process, a small variation on inputs typically translates to a small variation to the outputs. But this is not the case with software development.
Software development is really creation. And creation is not a highly predictable and repeatable thing. There is too much complexity and variability in the software creation process; software creation is an empirical activity.
Dictionary.com Empirical definition:
1. derived from or guided by experience or experiment.
2. depending upon experience or observation alone, without using scientific method or theory, esp. as in medicine.
3. provable or verifiable by experience or experiment.
In manufacturing, a great deal of work is about putting pieces together to build a specific thing. Whereas, in software development, these pieces are often created, re-created, or customized every time. This is not to simplify the kind of work going on a manufacturing assembly line. My point is that the manufacturing discipline and its pieces of work are more mature, stable and well understood than the software discipline, and its pieces of work.
Further, in software development a small variation on inputs can result into a big variation to the outputs. For example, small changes in requirement or the architecture can result in huge differences in the software development and its output.
Like this topic? check out this book: Optimizing the flow; process improvements for high performing agile teams
