Time and again I am confronted by a prejudice in favor of the module as the primary object of study in software engineering. Yet the reality is that the module has shrunk over time while the overall size of applications has grown (ok, I don't have any proof of this yet.) So why does the module continue this reign?
There is no doubt that code and programming languages are the bedrock foundation of a software system. But people do no fund building projects for their foundations and architectural criticism is never about the infrastructure. We build software systems for behaviors and artifacts that are enabled by the ensemble of modules. Sure, the individual modules must do their part to support the collective good of the application. But like an individual cell of the body, the part cannot comprehend the good done by the whole.
While the creation of the module and the productivity with which it is created are important subjects of study. But even more to me is the study of how the overarching design that resulted in the specification for the module came to be. The programming languages used for the module do not seem to be the language with which we understand the larger design. Even pseudocode does not seem to capture the essence that must be comprehended before we can deconstruct it to the level of module specification. IMHO, it was the introduction of object oriented design and programming that helped us make a big leap forward. But now we seem to be reaching the limits of what that paradigm shift offered and now must find a new conceptualization of how we methodically go about designing and building these ever growing software demands.
A case in point comes from a Microsoft research paper I saw from Bird talking about the growing importance of predicting the power consumption of software. In the bad old days of programming, it was necessary to be continually mindful of the resource demands of the program under development. If you wanted something to be memory resident, you needed to carefully plan how big that item could be. Now the hardware resources are so inexpensive that it is unusual to need to give it more than a moments thought. Further, the sophistication of systems now provide mechanical assistance in the form of code optimization, caching and other techniques that find optimization where none had been planned. This allows the coder to do what the machine cannot; to creatively interpret the specification and design the algorithms that will implement the desired behavior.
In this Bird paper, he points out that this obliviousness toward resource consumption is never too far away. As the world's platform shifts from the desktop to the palm, battery life is everything. And we are unlikely to see the kind of Moore's law in battery technology. The best we can hope for is a continued improvement in the power consumption for computation.
What I think is even more salient is that we are moving away from homogeneity in the qualities we are looking for in software products. Where once we only needed a functional implementation of some behavior, now we might need an energy efficient one for one proprietary application but one that is easy to extend in another open source. If we can make one application that satisfies both needs, great. But having two versions is entirely acceptable.
SEI seems to be the continued champion of viewing software not as a bundling of functional behavior but as an ensemble that possesses emergent behavior that can sometimes be difficult to coax out of the interconnection of the modules. As the interconnections between and among the modules grows exponentially, we approach a point where deterministic analysis becomes humanly impossible. We are faced with two options; the use of machines to do what humans can no longer do or to result in the kind of analysis and measurement done in thermodynamics. As the numbers grow larger we stop caring about the individual elements and instead depend upon the aggregates of their behavior. We don't talk about the kinetic energy of the molecules, we talk about the heat and pressure of the gas. We'll try to kick this can down the road a bit but I will be looking for the first signs that we might more productively discuss the measurements of these qualities rather than the metrics of the modules that comprise the whole.
No comments:
Post a Comment