5 ms·

Best tidbits from the article: > Software developers should provide expertise [...], but also in the externalization of mental models to facilitate communicati

Best tidbits from the article: > Software developers should provide expertise [...], but also in the externalization of mental models to facilitate communication and enable collaborative modelling. > Software development is largely a communication problem. [...] We should contribute to better concepts and a richer language to describe the domain. A while back I understood my work as a web developer as a translation from "business speak" into the language of some web framework. An activity not so different from translating a novel from it's original language into some other. The key point being that one needs to fully understand the "business speak" side of things before one can write it out as computer code. > We should lead in this effort, not wait for someone else to do it for us. But neither can we, software developers, do this on our own. I guess something I had been missing before is the feedback aspect (i.e. the externalization of mental models). However, in my experience most people in the 'business side' aren't interested in understanding the software side, so they are not receptive of what the software engineers have to say about the problem domain (i.e. the business side of things).

throwaway_pdp09 6y ago
Definitely this. I'd had it hammered into me that I need to understand the business to be a good dev, and it's true. That domain knowledge is essential to do a decent job, or even do the job at all. Rhe reciprocity, though, is mostly missing. An attempt to understand the IT side is essential for managers but most often they can't be bothered (or bothered to understand the principles of user interfaces, for that matter, anything that falls outside their domain). The few bosses I have had that did try were very good to work for indeed, but such are rare.
- thiagocesar 6y ago
  The problem is that a developer doesn’t really understand the business complexities and nuances - he studied computers, not business. I feel there is a gap to be crossed, and settling into a common language and common communication practices are ways to bridge it, but I could never say I understand the business. I get some basics. We have lots of areas, we need workflows, we design parts, then make them, then sell them. But I certainly don’t have enough knowledge to really understand it.
  - lmm 6y ago
    Translation needs to involve at least one person who is native-level in each language, and you're lucky if it's possible for both of those to be the same person. An effective team needs people who understand the computers and people who understand the business. Though it can sometimes end up a little like https://www.youtube.com/watch?v=yfSnaY1Wp_U https://www.youtube.com/watch?v=yfSnaY1Wp_U .
wry_discontent 6y ago
I thought the line The problem of software development is not “how to implement a solution to a given problem without shooting yourself in the foot”. It is to formalize something that in its nature is informal and unformalizable. was particularly good. This, I think, explains some of my dislike for static type systems. It's a formalization that doesn't help me with solving the problem I'm looking at. It's not necessarily formalizable.
- ReactiveJelly 6y ago
  I like static type systems because I don't like the idea of branching on types at runtime. So if every value is going to have one type anyway, I might as well check what it is before runtime. Lua has some functions that will take different types and do different things with them, but I'd rather do that with polymorphism than with dynamic types.
  - lioeters 6y ago
    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.

throwaway_pdp09 6y ago

Definitely this. I'd had it hammered into me that I need to understand the business to be a good dev, and it's true. That domain knowledge is essential to do a decent job, or even do the job at all. Rhe reciprocity, though, is mostly missing. An attempt to understand the IT side is essential for managers but most often they can't be bothered (or bothered to understand the principles of user interfaces, for that matter, anything that falls outside their domain). The few bosses I have had that did try were very good to work for indeed, but such are rare.

thiagocesar 6y ago
The problem is that a developer doesn’t really understand the business complexities and nuances - he studied computers, not business. I feel there is a gap to be crossed, and settling into a common language and common communication practices are ways to bridge it, but I could never say I understand the business. I get some basics. We have lots of areas, we need workflows, we design parts, then make them, then sell them. But I certainly don’t have enough knowledge to really understand it.
- lmm 6y ago
  Translation needs to involve at least one person who is native-level in each language, and you're lucky if it's possible for both of those to be the same person. An effective team needs people who understand the computers and people who understand the business. Though it can sometimes end up a little like https://www.youtube.com/watch?v=yfSnaY1Wp_U https://www.youtube.com/watch?v=yfSnaY1Wp_U .

wry_discontent 6y ago

I thought the line The problem of software development is not “how to implement a solution to a given problem without shooting yourself in the foot”. It is to formalize something that in its nature is informal and unformalizable. was particularly good. This, I think, explains some of my dislike for static type systems. It's a formalization that doesn't help me with solving the problem I'm looking at. It's not necessarily formalizable.

ReactiveJelly 6y ago
I like static type systems because I don't like the idea of branching on types at runtime. So if every value is going to have one type anyway, I might as well check what it is before runtime. Lua has some functions that will take different types and do different things with them, but I'd rather do that with polymorphism than with dynamic types.
- lioeters 6y ago
  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.