Software Evolution

Discussed the paper Software Evolution by Meir Lehman and Juan C. Fernández-Ramil, as published in chapter 1 of Software Evolution and Feedback: Theory and Practice by N. Madhavji, J. Ramil, and D. Perry (editors).

Interesting notions on display here. The authors reuse a classification of programs into S-type and E-type, where S-type programs hew precisely to a formal specification (and, consequently, appear principally in academic contexts or as subsets of E-type programs) and E-type programs are of the more conventional sort, meant to be used by actual users and, accordingly, are subject to evolutionary forces over its lifetime as its developers attempt to satisfy the users.

"Evolution," they say, specifically refers to the effects of maintenance, or to maintenance itself. "Maintenance," then, would be a misnomer. Driven by user feedback, or by a motivation to retain user satisfaction, programs will increase in functionality and other measures, such as size or some notion of complexity, or so the thesis goes. This can (and, in fact, was) observed in several programs; the article makes reference to a study tracking the size of IBM OS/360 over many releases, demonstrating that the size of the operating system increased steadily for twenty releases, then becomes unstable. An exploration of the instability ensues; a possible explanation is that the "ripple" resembles a feedback loop: tenuous, but plausible. The original study may provide necessary detail.

Thinking of software development as a self-directing process yields a degree of insight. The authors specifically note that evolutionary behavior is evident in software once more than one level of management is involved, as individual groups' activity may be directed, but the interaction between them is more chaotic.

Quantification

An open question in software is the matter of obtaining useful quantitative measures describing programs, both artifacts and their creation. Such measures, applied to large real-world data sets, would, it is hoped, lead the way to a sort of empirically-determined Holy Grail of best practices... for given values of "best," at least. Producing concrete, meaningful, complete, and adequate descriptions of phenomena which can be identified (preferably automatically) in code and the development history behind it would permit the discovery, by way of statistical analysis, of predictive models describing software.

I will give an example.

Suppose you want your software to be as good as possible. This is, of course, a tremendous assumption. Well, what do you mean by "good?" Let's start a bit less subjectively. Suppose you want your software to be, to draw an attribute out of a hat, as maintainable as possible, by which you mean you want it to take less effort to maintain. Fortunately, you've got data about projects which can be generalized to apply to your own. So you analyze the data to find which attributes correlate well to the effort used in maintenance, give or take a few caveats, invariants, and sanity checks. Optimize those attributes in your own process, and you'll know exactly how to carry out your project and just how maintainable you can expect it to be, and even how likely it is that it won't turn out that way.

There are, clearly, a number of steps in that procedure which are filled in by what amounts to wishful thinking. The science is not, as they say, in. That's what this class is for. We can identify more informative composite measures than the raw data. We can develop ways to automatically identify data attributes which are not obvious, perhaps most interestingly locating the use of explicit design patterns, or even hitherto-unidentified patterns used unintentionally. We can try to reverse-engineer the design intentions of developers on projects where there are no process records, and also beg open-source developers to begin keeping such records, in hopes that our successors don't have to bother with this dreary guesswork.

And if we succeed? Another thin layer will be peeled away from the vast onion of misinformation, superstition, and ad-hoc stumbling in software engineering. I think I'm going to cry.

Reboot

I am enrolled in a master's degree program in computer science at Colorado State University. In one of my classes, Advanced Topics in Software Engineering: Measurement, Analysis, & Evaluation, it is a requirement for each student to keep a weblog consisting of comments on the other students' presentations. This seems a convenient excuse for me to throw my hat back in the blogging ring.

So, in addition to the minimal class requirements, I will use this space to comment on related material and concepts, whether within the course's curriculum or without. Topics will generally fall in the realm of computer science, although I make no promises, since digression is half the fun. I will write in a style whose principal aim is to examine and understand the concepts myself, so many posts will be unsuitable for laymen, while others will be unsuitable for experts.