In this sense, theory is not the bad
word it is sometimes treated as in our
culture (“Oh, that’s just a theory”).
As noted earlier, having a theoretical foundation is, in fact, the key that
allows for disciplined engineering
analysis. This is true of material science for construction engineering,
electromagnetic theory for electrical
engineering, aerodynamics for aeronautical engineering, and so forth.
Of course, the interplay between
the historical development of an engineering discipline and its associated
theory is generally more complicated
than this simple explanation implies.
Engineering experience is distilled
into theory, which then promotes better engineering, and back again. Nevertheless, the important point to realize here is this: traditional software
engineering did not have such an underlying theory.
One might suggest computer science provides the underlying theory
for software engineering—and this
was, perhaps, the original expectation
when software engineering was first
conceived. In reality, however, computer science has remained a largely
academic discipline, focused on the
science of computing in general but
mostly separated from the creation of
software-engineering methods in industry. While “formal methods” from
computer science provide the promise of doing some useful theoretical
analysis of software, practitioners
have largely shunned such methods
(except in a few specialized areas such
as methods for precise numerical
As a result, there have often been
cycles of dueling methodologies for
software “engineering,” without a true
foundational theory to unite them. In
the end, many of these methods did
not even address the true needs of the
skilled craft practitioners of the industry.
So, how to proceed?
The creation of a complete, new
theory of software engineering will
take some time. Rather than starting
with an academic approach, we can
begin, as already mentioned, by cap-
turing the commonality among the
methods that have proven successful
in the craft of software development.
This, in turn, requires a common way
of describing, understanding, and
combining various software-develop-
ment techniques, instead of setting
them up in competition with each
To see how this might be accomplished, let’s take a closer look at
methods and the teams of practitioners that really use them.
Agility Is for Methods,
Not Just Software
The current movement to promote
agility in software development com-
plements the recognition of software
craftsmanship. As the name suggests,
agile software development is about
promoting flexibility and adaptability
in the face of inevitably changing re-
quirements. This is done by producing
software in small increments, obtain-
ing feedback in rapid iterations, and
continually adjusting as necessary.
Agile software-development teams
take charge of their own way of working. Such a team applies the methods
Figure 1. The kernel alphas.
Scopesand constrains> <produces
< performs and plans
Figure 2. Tracking progress with alphas.
Stakeholders Way of Working
Software System Work