Metaphysics of Software Development
Some insights on the software development craft, from a philosophical viewpoint.Monday, February 8, 2010
The four discourses - part II
Software development is a creative process, in which ingenuity and aesthetic concerns play a major role. Using an OO language, for instance, developers are free to choose how to distribute the behavior among classes, how these classes interact with each other and which layers will be used, just to name a few. But, although the set of possibilities is very large, it is not limitless. There are several technological and theoretical constraints, such as memory consumption, turnaround time, computational complexity, design complexity, coupling, cohesion, computability and formal correctness, among others.
According to the scale of four discourses proposed by prof. Olavo de Carvalho (see part I), we could say that, during the course of a project, developers go through all the levels, starting at the poetical one, when a great number of possible solutions are devised. The next step is to select a subset of those solutions that could possibly work (the rhetorical level). By confronting these apparently suitable solutions to one another, it is possible to identify which of them are inconsistent or incomplete and which ones are satisfactory. Sometimes, this confrontation of ideas can lead to the creation of a whole new set of acceptable solutions to the problem. This is what we could call a dialectical practice. Finally, the most likely solutions the team came up with are further refined and formalized, in order to be implemented them in some programming language. Evidently, this is not a linear process, and developers usually go back and forth, as the circumstances demand it.
Eventually some artifacts are produced as a result of the proceedings above, including use case specifications, UML diagrams, test reports, quality control reports and the like. This is especially true in the most bureaucratic, waterfallish companies. Every one of those artifacts, being instances of human discourse, can also be classified according to the four levels. But note that there is a key difference between a creative process and its resulting artifacts. The process, although it spans throughout all levels, is just a means to an end. What really matters is delivering a valuable product to the end user. It does not matter whether developers underwent a poetical stage early on; at the end, we all wish to deliver an executable and correct source code, amenable to lexical and syntactical analysis, mathematical proofs of correctness, style checking and so on. In other words, the final cause of this process is the logical discourse.
The artifacts, on the other hand, are crystallized forms of discourse, registered during the early stages, that are expected (a naive expectation, of course) to remain valid long after it has been produced. As a consequence, some artifacts stand at the level of high probability, such as the design diagrams and test result reports. Others fall at a lower level, the rhetorical one: examples include the process body of rules (usually a distorted version of RUP) and quality management reports (usually a bunch of finger-pointing paperwork). And there are those artifacts that could be put in the lowest level of the scale: use case documents are an outstanding specimen of the kind. Everything written down in such documents is nothing but poetical formulation. It represents just a possible world, very useful for hypothetical considerations, but with nothing that binds it to the actual world.
Actually, I think this is the ultimate criterion for classifying software artifacts according to the four discourses scale: how much it is bound by reality. In the case of software development, the reality forces come from the technological and theoretical constraints I mentioned above. After all, it is possible to write pretty much everything you want in a use case. But only a small subset of that is actually implementable. Consider this dramatic scenario: a requirements document which states that the application should divide integers by zero. It is even possible to get some client to "approve it", but no well-implemented compiler in the world would accept a tentative implementation of that requirement. This is a rather contrived example, but it is helpful to get the point: software development is a creative process, but it ultimately seeks to produce source code, a reality-bound artifact, which should be treated as the most important asset in the project.
According to the scale of four discourses proposed by prof. Olavo de Carvalho (see part I), we could say that, during the course of a project, developers go through all the levels, starting at the poetical one, when a great number of possible solutions are devised. The next step is to select a subset of those solutions that could possibly work (the rhetorical level). By confronting these apparently suitable solutions to one another, it is possible to identify which of them are inconsistent or incomplete and which ones are satisfactory. Sometimes, this confrontation of ideas can lead to the creation of a whole new set of acceptable solutions to the problem. This is what we could call a dialectical practice. Finally, the most likely solutions the team came up with are further refined and formalized, in order to be implemented them in some programming language. Evidently, this is not a linear process, and developers usually go back and forth, as the circumstances demand it.
Eventually some artifacts are produced as a result of the proceedings above, including use case specifications, UML diagrams, test reports, quality control reports and the like. This is especially true in the most bureaucratic, waterfallish companies. Every one of those artifacts, being instances of human discourse, can also be classified according to the four levels. But note that there is a key difference between a creative process and its resulting artifacts. The process, although it spans throughout all levels, is just a means to an end. What really matters is delivering a valuable product to the end user. It does not matter whether developers underwent a poetical stage early on; at the end, we all wish to deliver an executable and correct source code, amenable to lexical and syntactical analysis, mathematical proofs of correctness, style checking and so on. In other words, the final cause of this process is the logical discourse.
The artifacts, on the other hand, are crystallized forms of discourse, registered during the early stages, that are expected (a naive expectation, of course) to remain valid long after it has been produced. As a consequence, some artifacts stand at the level of high probability, such as the design diagrams and test result reports. Others fall at a lower level, the rhetorical one: examples include the process body of rules (usually a distorted version of RUP) and quality management reports (usually a bunch of finger-pointing paperwork). And there are those artifacts that could be put in the lowest level of the scale: use case documents are an outstanding specimen of the kind. Everything written down in such documents is nothing but poetical formulation. It represents just a possible world, very useful for hypothetical considerations, but with nothing that binds it to the actual world.
Actually, I think this is the ultimate criterion for classifying software artifacts according to the four discourses scale: how much it is bound by reality. In the case of software development, the reality forces come from the technological and theoretical constraints I mentioned above. After all, it is possible to write pretty much everything you want in a use case. But only a small subset of that is actually implementable. Consider this dramatic scenario: a requirements document which states that the application should divide integers by zero. It is even possible to get some client to "approve it", but no well-implemented compiler in the world would accept a tentative implementation of that requirement. This is a rather contrived example, but it is helpful to get the point: software development is a creative process, but it ultimately seeks to produce source code, a reality-bound artifact, which should be treated as the most important asset in the project.
Labels: Dialectic, Logic, Poetics, Rhetoric
posted by Otavio Macedo # 7:03 PM 
Archives
January 2010 February 2010 March 2010 August 2011 November 2011
Subscribe to Posts [Atom]
Post a Comment