programming as casting metaphor
There are various metaphors people use for programming; one example is "programming is like writing", another is "programming is like construction", mathematics, analysis, craft. More extreme examples are dreaming or cultivation.
To add to this list, I would like to analogize programming to casting - pouring molten metal into the space between two (or in general several) molds, often made of a sand/clay mixture.
* The metal is analogous to code.
* The heat applied to the metal is analogous to the programmers, who (temporarily) "inhabit" the code, and understand it deeply, making it flexible.
* The sand is analogous to requirements documentation.
* The clay is analogous to customer or business representatives, who "inhabit" the requirements documentation and bind it together into a cohesive whole.
* The two (usually) halves of the mold are analogous to the two (usually) major interfaces from the system to the external world - e.g. a system might interface to the customer (who purchases items from the system) and a warehouse.
* The sprues, gates and runners which are necessary to cast, but also need to be removed from the final product are analogous to the build system and unit tests.
* The machining of the final product is analogous to the deployment.
The analogy extends to typical kinds of defects:
* A misrun occurs when the molten metal does not fill out all of the requirements.
* A cold shut occurs when the frontier of the molten metal pauses or dwells during pouring, and the programmers have to go back to forgotten code.
* Mold mismatch is a requirements error that comes from lack of alignment between the different facets dictating requirements.
* A sand inclusion can occur when requirement documents detach from being owned by the customer, becoming "lost purposes" that are owned and served by the programmers, complicating the system unnecessarily.
* A run out is when requirements are so faulty that the programmers start writing code based on imaginary requirements.
* A pipe is a void that occurs near the sprue feeding new code into the project; these can occur when a feature that needs to be done last is not done at all.
* Mechanical damage can occur during the machining / deployment.
* Bubbles and porosity are the classic bugs and they generally occur at so-called "hot spots", which are portions of the code base that are frequently touched and changed by programmers.
To some extent, even the solutions that foundry workers use to deal with these problems sound pretty reasonable. For example, if you're experiencing porosity defects at hot spots, you might consider using chillers, which would be project management prioritizing getting programmers OUT of the hot spots, so that they solidify sooner. Or if your business requirements people are emitting bubbles of hot air when they interact with your programmers trying to write code, you might bake them (gently expose them to programmers who are not trying to write code) for a while beforehand to dry them out.
To add to this list, I would like to analogize programming to casting - pouring molten metal into the space between two (or in general several) molds, often made of a sand/clay mixture.
* The metal is analogous to code.
* The heat applied to the metal is analogous to the programmers, who (temporarily) "inhabit" the code, and understand it deeply, making it flexible.
* The sand is analogous to requirements documentation.
* The clay is analogous to customer or business representatives, who "inhabit" the requirements documentation and bind it together into a cohesive whole.
* The two (usually) halves of the mold are analogous to the two (usually) major interfaces from the system to the external world - e.g. a system might interface to the customer (who purchases items from the system) and a warehouse.
* The sprues, gates and runners which are necessary to cast, but also need to be removed from the final product are analogous to the build system and unit tests.
* The machining of the final product is analogous to the deployment.
The analogy extends to typical kinds of defects:
* A misrun occurs when the molten metal does not fill out all of the requirements.
* A cold shut occurs when the frontier of the molten metal pauses or dwells during pouring, and the programmers have to go back to forgotten code.
* Mold mismatch is a requirements error that comes from lack of alignment between the different facets dictating requirements.
* A sand inclusion can occur when requirement documents detach from being owned by the customer, becoming "lost purposes" that are owned and served by the programmers, complicating the system unnecessarily.
* A run out is when requirements are so faulty that the programmers start writing code based on imaginary requirements.
* A pipe is a void that occurs near the sprue feeding new code into the project; these can occur when a feature that needs to be done last is not done at all.
* Mechanical damage can occur during the machining / deployment.
* Bubbles and porosity are the classic bugs and they generally occur at so-called "hot spots", which are portions of the code base that are frequently touched and changed by programmers.
To some extent, even the solutions that foundry workers use to deal with these problems sound pretty reasonable. For example, if you're experiencing porosity defects at hot spots, you might consider using chillers, which would be project management prioritizing getting programmers OUT of the hot spots, so that they solidify sooner. Or if your business requirements people are emitting bubbles of hot air when they interact with your programmers trying to write code, you might bake them (gently expose them to programmers who are not trying to write code) for a while beforehand to dry them out.