> programming is primarily based on planning and management, most akin to logistical management and orchestration.
That's how I feel as well. Maybe it's a by-product of the software we work on? I work on IT management software and distributed control systems.
When working with control systems, the "science" part typically is in the analysis and testing phases (since we have to come up with models of physical systems). For coding itself, however, it is closer to what you describe.
> I often think of my data model as a physical system, and its behavior in terms of real world systems.
I do this too, especially when programming in Erlang. When building software systems that are modeled as a large number of concurrent, message-passing actors/processes, it readily lends itself to this "physical systems" analogy.
That's how I feel as well. Maybe it's a by-product of the software we work on? I work on IT management software and distributed control systems.
When working with control systems, the "science" part typically is in the analysis and testing phases (since we have to come up with models of physical systems). For coding itself, however, it is closer to what you describe.
> I often think of my data model as a physical system, and its behavior in terms of real world systems.
I do this too, especially when programming in Erlang. When building software systems that are modeled as a large number of concurrent, message-passing actors/processes, it readily lends itself to this "physical systems" analogy.