Not that paper again. I have a bite-sized rebuttal, fight me:
The authors’ “ideal world” is one where computation has no cost, but social structures remain unchanged, with “users” having “requirements”. But the users are all mathematical enough to want formal requirements. The authors don’t seem to notice that the arrow in “Informal requirements -> Formal requirements” may indicate that formal requirements are themselves accidental complexity. All this seems to illuminate the biases of the authors more than the problem.
I’d counter the so called “Von Neumann Principle” invoked by the author
There is no point in using exact methods where there is no clarity in the concepts and issues to which they are to be applied.
with Goguen’s dictum:
a precise description that is somewhat wrong is better than a description so vague that no one can tell if it’s wrong. We do not seek to formalize actual living meanings, but rather to express our partial understandings more exactly.
The call to consider the role of software development teams on a more holistic basis is well motivated. However, the post doesn’t succeed as a refutation of “Out of the Tarpit”, ime. If anything, in trying to improve the languages available for specifying and implementing software systems, Mosely and Marks seem to be pursuing exactly the kind of work the author calls for
Software development is largely a communication problem. We should take active part in defining, delineating, describing and exploring the problem domain itself, which goes beyond the software system. We should contribute to better concepts and a richer language to describe the domain. It will help us uncover new and better problem descriptions, which will lead to new and better software systems. This exploration is a never-ending process of discovery, negotiation and reevaluation. We should lead in this effort, not wait for someone else to do it for us.
Part of this process and negotiation and reevaluation is, and should be, scrambling towards more specific and clearer articulations of real needs and problems. There is no reason this shouldn’t involve formal, declarative specifications.
An account of complexity in software that doesn’t account for the continuous tension between a necessarily formal system and an irreducibly informal world is missing something essential about software development. That’s why “Out of the Tar Pit” is wrong.
Making it easier to communicate and reason about our programs doesn’t constrain our ability to grapple with complex and nebulous problem domains, nor does it preclude the possibility of evolving our communications and means of reasoning. The important corrective that the post provides is in pointing out that Mosely and Marks don’t address the sociological dimensions in their paper, and that they don’t address the important issue of synthesizing new understandings of what even counts as a problem. This is a valid additional concern, arguably revealing an important oversight, but in no way does it refute their thesis, imo.
I had bookmarked the article to offer it a fair share of the ample focus it seems to require of me, but a first superficial reading left me with a similar impression: Yes, it seems to be bringing forth interesting points, but what has any of it have to do with Out of the tar pit and how, exactly, does it refute the authors’ thesis?
Not that paper again. I have a bite-sized rebuttal, fight me:
The authors’ “ideal world” is one where computation has no cost, but social structures remain unchanged, with “users” having “requirements”. But the users are all mathematical enough to want formal requirements. The authors don’t seem to notice that the arrow in “Informal requirements -> Formal requirements” may indicate that formal requirements are themselves accidental complexity. All this seems to illuminate the biases of the authors more than the problem.
(So I mostly agree with OP.)
I’d counter the so called “Von Neumann Principle” invoked by the author
with Goguen’s dictum:
The call to consider the role of software development teams on a more holistic basis is well motivated. However, the post doesn’t succeed as a refutation of “Out of the Tarpit”, ime. If anything, in trying to improve the languages available for specifying and implementing software systems, Mosely and Marks seem to be pursuing exactly the kind of work the author calls for
Part of this process and negotiation and reevaluation is, and should be, scrambling towards more specific and clearer articulations of real needs and problems. There is no reason this shouldn’t involve formal, declarative specifications.
Making it easier to communicate and reason about our programs doesn’t constrain our ability to grapple with complex and nebulous problem domains, nor does it preclude the possibility of evolving our communications and means of reasoning. The important corrective that the post provides is in pointing out that Mosely and Marks don’t address the sociological dimensions in their paper, and that they don’t address the important issue of synthesizing new understandings of what even counts as a problem. This is a valid additional concern, arguably revealing an important oversight, but in no way does it refute their thesis, imo.
I had bookmarked the article to offer it a fair share of the ample focus it seems to require of me, but a first superficial reading left me with a similar impression: Yes, it seems to be bringing forth interesting points, but what has any of it have to do with Out of the tar pit and how, exactly, does it refute the authors’ thesis?