Software development is program transformation
Many people have said that program development should be based on program transformation. OMG 19s Model Driven Architecture says that software should be developed by creating (UML) models and generating code from the models. 1CProgram refinement 1D is the idea that software development should start with an abstract, but possibly inefficient program, and transform that program to its final state (an early paper is http://portal.acm.org/citation.cfm?id=800078.802556).
In contrast, I do not say that program development *should* be program transformation, I claim that it already is. Most work on software is after the first released version. The purpose of work on existing software is to transform it to the new version. Since almost all work on software is converting version N to version N+1, almost all work on software is program transformation.
When people argue in favor of program transformation, they usually have some theory of it, and they are trying to fit software development into their theory. In contrast, I am noticing a fact (software development is program transformation) and trying to let that fact teach me something. I do not claim that program transformations are easy, or that they can be automated, or even that we can always understand them. I am claiming that thinking of software development as program transformation is likely to lead to improvements in how we develop software.
One area in which software development is thought of as a series of changes to software is configuration management. Most version control systems keep a delta from one version of a system to the next. So, the latest version is thought of as the original version plus a sequence of deltas. But a delta tends to be syntactic, usually just listing the lines in the file that changed. A program transformation system should take advantage of the syntax and semantics of the programming language.
A new version is a series of small changes. Some of the small changes are easy to understand, and others are not. For example, a refactoring like 1Cchange the name of a class 1D is easy to automate. It might involve changing many files, but the changes are easy to predict and understand. Another change that is easy to understand is to add a new class without making much change to any of the existing code. But it can be hard to fix a bug or add a feature that requires changing core data structures.
We need to first acknowledge that software development is program transformation. Then we should try to understand the various kinds of program transformations that programmers use. When possible, we should automate them. Even if we can 19t automate a particular program transformation that programmers use, understanding the truth will let us develop software better.
