Software DEVELOPMENT is a lot of design and problem solving. It also usually involves changing requirements and discovering limitations of the tools. I agree that there's a lot of uncertainty in the development process.
Software DELIVERY is what management, customers, and users care about. If a software system does not meet requirements, or if it's so late or over budget that it's a net loss to the customer, it matters little how well-designed it is or what problems were solved.
By predictable and repeatable I mean the entire process. Obviously not every aspect of of the development process can be predicted, nor are projects enough alike to be produced by an assembly line. What management and customers want is a reliable prediction that the system will meet requirements and be finished on schedule and within budget. And they want to believe that a process that can deliver a system this year can do it again.
An architect can reliably predict that a house or an office tower can be made from their plans. A chip designer can predict that a working CPU can be designed and built. An automobile designer can predict that a working car can be made. And these processes are repeatable. Any designer/builder will encounter problems to solve and changing requirements. Failures occur in these realms, too, but not nearly as often as with software projects.
I've heard the argument that software development is different: it's a creative process, the people are idiosyncratic, the problems are unpredictable. I think big-budget movies face the same challenges, but even in that domain there are predictable and repeatable processes that are reasonably good at delivering.
I agree that "Looking for something that can perfectly transform any human requirement into code, in a predictable manner, is just silly." I didn't write anything like that, nor is that what I think anyone means by software development methodologies.
"An architect can reliably predict that a house or an office tower can be made from their plans."
Yes, but that's because the plans are nailed down and fixed - the creative design part is _done_.
"A chip designer can predict that a working CPU can be designed and built. An automobile designer can predict that a working car can be made."
Neither of these are true until _after_ the designs are finished. Intel has gone massively over-budget on chip designs before, and automobile designs have been abandoned after spending a fortune trying to get them right.
I think I'm not making my argument clear. Software development methodologies are PROMOTED as ways to improve the predictability and repeatability of software development. They are adopted because management (or customers) are scared by the usual chaos of software development.
I think I clearly communicated my opinion that no development methodology in and of itself guarantees predictability or repeatability. They fail to meet the expectations of management; in other words they don't work.
I also think I clearly expressed my surprise that even without management pressure programmers will adopt methodologies and then force themselves to follow the rituals. Maybe this happens because programmers don't know better. I think it has more to do with creating a firewall of process and so-called best practices to avoid oversight and criticism. Sometimes there's an element of showing off -- look at how Agile/OOP/TDD/whatever I am, and no one told me to do it!
Software DELIVERY is what management, customers, and users care about. If a software system does not meet requirements, or if it's so late or over budget that it's a net loss to the customer, it matters little how well-designed it is or what problems were solved.
By predictable and repeatable I mean the entire process. Obviously not every aspect of of the development process can be predicted, nor are projects enough alike to be produced by an assembly line. What management and customers want is a reliable prediction that the system will meet requirements and be finished on schedule and within budget. And they want to believe that a process that can deliver a system this year can do it again.
An architect can reliably predict that a house or an office tower can be made from their plans. A chip designer can predict that a working CPU can be designed and built. An automobile designer can predict that a working car can be made. And these processes are repeatable. Any designer/builder will encounter problems to solve and changing requirements. Failures occur in these realms, too, but not nearly as often as with software projects.
I've heard the argument that software development is different: it's a creative process, the people are idiosyncratic, the problems are unpredictable. I think big-budget movies face the same challenges, but even in that domain there are predictable and repeatable processes that are reasonably good at delivering.
I agree that "Looking for something that can perfectly transform any human requirement into code, in a predictable manner, is just silly." I didn't write anything like that, nor is that what I think anyone means by software development methodologies.