Re:Into the Tar Pit
by lioeters on Saturday May 23, 2020 @12:28PM
(#23284252)
I see type systems like database schema, they're about domain modelling. Sometimes it can be a pain while the models are in flux, while the problem is being solved.
But as the solution becomes clearer, having the models "formalized" in strong types provides a solid foundation, and supports long-term development and maintenance.
---
To bring it back to the topic/article at hand, the author emphasizes the translating of business problems into conceptual models in software.
Business and domain-specific problems as described by the user or client, is like the most ambiguous form of "software", communicated in human language. That includes dynamic or implicit typing, unstable and contradictory data schemata, scopes that leak into each other, unclear logic.
That means, software developers ought to become more "multi-lingual" and fluent in the language and thinking process of the users.
When the author says, "Software development is largely a communication problem", I also see it as a cross-cultural communication problem.
The translation - "formalization" - into computer-speak, into hardware/software terms, can never be perferct, since like all translation, there are huge missing areas from one culture or language to another, some concepts don't translate well (or at all), and necessarily, the worldview and biases of the translator will shape the result.
That metaphor also implies, what's important is the shared understanding between cultures, let's say the "business" and the "tech/software" side.
I agree with the author that it's up to the latter experts, to take on the responsibility of cultivating such understanding, to provide the vocabulary and conceptual framework for the business side to express their needs and problems, to collaborate in their solution and formalization to software.
But as the solution becomes clearer, having the models "formalized" in strong types provides a solid foundation, and supports long-term development and maintenance.
---
To bring it back to the topic/article at hand, the author emphasizes the translating of business problems into conceptual models in software.
Business and domain-specific problems as described by the user or client, is like the most ambiguous form of "software", communicated in human language. That includes dynamic or implicit typing, unstable and contradictory data schemata, scopes that leak into each other, unclear logic.
That means, software developers ought to become more "multi-lingual" and fluent in the language and thinking process of the users.
When the author says, "Software development is largely a communication problem", I also see it as a cross-cultural communication problem.
The translation - "formalization" - into computer-speak, into hardware/software terms, can never be perferct, since like all translation, there are huge missing areas from one culture or language to another, some concepts don't translate well (or at all), and necessarily, the worldview and biases of the translator will shape the result.
That metaphor also implies, what's important is the shared understanding between cultures, let's say the "business" and the "tech/software" side.
I agree with the author that it's up to the latter experts, to take on the responsibility of cultivating such understanding, to provide the vocabulary and conceptual framework for the business side to express their needs and problems, to collaborate in their solution and formalization to software.