Team. When studying software engineering, one learns of the
many differing formal life-cycle models. This ranges from prototyping and the
evolutionary model to the numerous formal risk assessments of the spiral model.
It includes the standard Waterfall model and its notion of a "phase"
which one should not confuse with the use of the term "phase" in the
Rational Unified Process (RUP). But the crux of the activity is
"building" software. If it does not verify, validate, or work as
expected in production, one must "fix" it. So all the glorious models
in computing envisioned by the greatest minds of this and the past millennium,
are ultimately "build" and "fix" models. Yet, young
engineering students are told that one should not simply "build and
fix" software and that such an approach will only produce the
"kludgy"-est of products.
The primary distinction between the "ad-hoc" build
and fix approach which we are counseled against and the other processes which
we use is the amount of forethought and documentation generated in the
process. Creating software is much like writing a term paper for a college
course. One can simply sit down at a computer with only a topic and without any
research materials, an outline, or thesis statement, and he can start typing. This would
likely be a very frustrating approach that would produce a product of less than
marginal quality. This is the equivalent of software engineering's
"ad-hoc" build and fix model. More formal simple models are the
equivalent of writing a structured essay or theme whereas the most rigorous of
models parallel creating a "research-grade" professional academic
paper.
Also, much like a theme with its thesis statement that must
be the last sentence of the introduction, the equivalent of the topic sentence
for the summary or conclusion, and sub-divisible into three logical parts
which become the topics for its body paragraphs, developing software follows a
formulaic pattern. Besides the research which one does for identifying the
needed library calls for doing the necessary work in a method, coding any
behavioral concern always requires identifying the required inputs, the
necessary outputs, and the transformations which produce the output from the
input. This is the basis for the ideas on formal
"program-correctness" proofs. Using this approach, one can always
start with a "Hello World"-type method that simply echoes its input
and evolve it from there. Remember, the number theory of computing. One starts
with an estimate of the final program, and through the iteration and optimization
of that guess one eventually arrives at the desired product. This approach would be the same as writing the last sentence of the
introduction of your theme plus the topic sentence of each body paragraph and
the conclusion and then filling in the rest.
Ultimately, all we do is build and fix; however, our primary
goal is that we spend more time building and less fixing. Although a
fluctuating feature set can require constant "fixing", quality
change management can limit such fixes.
Always remember the virtues of hunting, pecking, and
thinking. So, build slowly and fix less. Enjoy this day. La-La.
No comments:
Post a Comment