Metaphysics of Software Development
Some insights on the software development craft, from a philosophical viewpoint.Wednesday, February 17, 2010
Intertwined concerns
As I have been writing about the ontological nature of software development, it is becoming more and more clear that there is central thesis in this blog: that the division of software development in activities is methodological, and not ontological. All other themes seem to gravitate around this one. So, I would like to go a little deeper into that discussion, by presenting a few examples.
Let's start with requirements. Several authors and processes advise their readers to gather requirements from the customer at the initial stages of a project, register them in requirements documents, then declare that phase completed, handing all the resulting artifacts to other developers to continue the work from that point. Note that in this advise there are some hidden premises: first, that this is a time-framed activity, precisely scheduled by some project manager. Second, the duration of that work is supposed to be relatively short, compared to the whole project schedule. After all — goes the advice — once the requirements have been collected, there is no longer a need for customer feedback. And third, there is the idea of avoiding the overlapping of activities. "Don't move on to the next phase until the customer has approved the final version of the requirements documents."
This advice is based on the assumption that there is an independent entity in the real world called "software requirements". Being an entity in and of itself, it could be tackled separately from all the other activities. Since every other activity depends on requirements, the latter should be done first and completed as soon as possible.
But it is important to recognize that the requirements aren't just wishlists dictated by the customer. The requirements are behavioral and structural expectations for a software application. The whole purpose of any application is to solve a particular problem set for some particular domain. So, some kind of conceptual domain model — albeit a rough one — must be constructed while the requirements are collected. In addition, as Eric Evans points out, "new systems almost always have to be integrated with legacy or other systems", so it is inevitable to think of some form of high level architecture. But these requirements, when implemented, will have to be tested. So test is another concern the requirements analysts should not overlook. In fact, automated tests are an excellent tool to register requirements.
Because of all this, it's easy to see that requirements don't exist in a vacuum. They can only be separated by abstraction, a mental process that is necessarily done a posteriori. A similar analysis could be done for all the other activities. For instance, software design, as discussed above, is intertwined with requirements. Likewise, professional developers write unit tests for every piece of production code (preferably written before the production code itself). So, one more time, tests come into play. Since the best tool to represent a domain model for software applications is the source code itself, software design and implementation are indistinguishable. And don't forget that the application will eventually be deployed (another software activity), which will spark a torrent of ideas from the end users, resulting in more requirements, starting it all over. The interconnections are virtually endless and have only been superficially addressed here.
It doesn't take much effort to realize that all concerns involved in a software project are intertwined. It doesn't make sense to set them apart and expect to get better results from such a strategy. Using an OO-inspired terminology, one could say that these concerns are highly coupled. High coupling is usually solved with encapsulation. But, as Martin Fowler puts it, "encapsulation is for objects, not for people".
Let's start with requirements. Several authors and processes advise their readers to gather requirements from the customer at the initial stages of a project, register them in requirements documents, then declare that phase completed, handing all the resulting artifacts to other developers to continue the work from that point. Note that in this advise there are some hidden premises: first, that this is a time-framed activity, precisely scheduled by some project manager. Second, the duration of that work is supposed to be relatively short, compared to the whole project schedule. After all — goes the advice — once the requirements have been collected, there is no longer a need for customer feedback. And third, there is the idea of avoiding the overlapping of activities. "Don't move on to the next phase until the customer has approved the final version of the requirements documents."
This advice is based on the assumption that there is an independent entity in the real world called "software requirements". Being an entity in and of itself, it could be tackled separately from all the other activities. Since every other activity depends on requirements, the latter should be done first and completed as soon as possible.
But it is important to recognize that the requirements aren't just wishlists dictated by the customer. The requirements are behavioral and structural expectations for a software application. The whole purpose of any application is to solve a particular problem set for some particular domain. So, some kind of conceptual domain model — albeit a rough one — must be constructed while the requirements are collected. In addition, as Eric Evans points out, "new systems almost always have to be integrated with legacy or other systems", so it is inevitable to think of some form of high level architecture. But these requirements, when implemented, will have to be tested. So test is another concern the requirements analysts should not overlook. In fact, automated tests are an excellent tool to register requirements.
Because of all this, it's easy to see that requirements don't exist in a vacuum. They can only be separated by abstraction, a mental process that is necessarily done a posteriori. A similar analysis could be done for all the other activities. For instance, software design, as discussed above, is intertwined with requirements. Likewise, professional developers write unit tests for every piece of production code (preferably written before the production code itself). So, one more time, tests come into play. Since the best tool to represent a domain model for software applications is the source code itself, software design and implementation are indistinguishable. And don't forget that the application will eventually be deployed (another software activity), which will spark a torrent of ideas from the end users, resulting in more requirements, starting it all over. The interconnections are virtually endless and have only been superficially addressed here.
It doesn't take much effort to realize that all concerns involved in a software project are intertwined. It doesn't make sense to set them apart and expect to get better results from such a strategy. Using an OO-inspired terminology, one could say that these concerns are highly coupled. High coupling is usually solved with encapsulation. But, as Martin Fowler puts it, "encapsulation is for objects, not for people".
Labels: functional silos, software activities
posted by Otavio Macedo # 9:32 AM 
Archives
January 2010 February 2010 March 2010 August 2011 November 2011
Subscribe to Posts [Atom]
Post a Comment