Recently I’ve been reading a book by Steve McConnell called ‘Code Complete’ while at the same time a parallel process is taking place in my personal life, unconnected but related in some strange way.
A few days ago I wrote this passage in the midst of trying to resolve a personal issue.
If I were at sea in a small
yacht with my family and friends on board, I would have the duty of care for
their safety. Regardless of the weather conditions, whether it’s a calm, clear,
warm day with a steady breeze or a dark, wet, cold night with a storm
raging. There would be but one response to all, stay true to the course. Keep
an eye on the weather and respond only to keep the yacht sailing true.
Looking at this
statement, it suggests that we should be aware of outside influences or conditions
and take corrective action to remain on our chosen path or course. Now to the software development process, take a project of a small to medium size that requires a vision statement, requirements, and a design. In everyday terms; to obtain an objective we need to define the specifications and have a plan that satisfies the specifications and delivers the objective.
Specification
in this context means the reference points that limit or ring fence the
objective, a series of small statements that are measurable, that, when all
have been satisfied, the objective has been achieved.
If you are
not a programmer and you’re reading this then you may be forgiven in thinking
this sounds very much like goal setting, well in a way it is, the principle is
the same, state the objective, define the specifications, draw up a detailed
plan to achieve it. The principle
applies whether you’re building a deck, or house, or a bridge, or a software
application or planning to travel or your financial freedom by 40, or quality
of retirement, or quality of life. We should define the objective, and the specifications
and a plan to achieve the objective.
If the
objective is deterministic, financial, travel, a deck then it is relatively
straight forward. However if it’s going to take months or years, then be
prepared to adjust the plan because things change, conditions change, obstacles
get in the way, may even find a better more attractive objective.
In Software
design the final design can be elusive or non-deterministic, in Steve’s book he
devotes the first 5 chapters to the iterative process, define it, specify it,
design it, then refine it, and refine it again. Using an assortment of tools
and techniques before the design is good enough. Yes, you read that right, good
enough; it is not an airplane or a building, or a bridge. It is a design for a
moveable complicated software application that may and probably will change
before it is finished.
Much like
life objectives, it is pointless to sit down and map out where we want to be in
30 years with a full plan on how to get there, because it is an iterative
process and things change along the way, it’s nondeterministic, besides the world
is changing all the time and us with it.
All we can
do in life is set out with a long term objective, some specifications that we
can use along the way to check progress, and a rough plan that is short term
and in the right direction.
Back to the
yacht, keeping an eye on the conditions means be prepared for things to change,
because they probably will. Stay true to the course means when the conditions change,
we may have to make adjustments but always in reference to the chart.
Here is the
bottom line: regardless of whether you are sailing a yacht or building a yacht,
or building software or building yourself, be prepared for things to change.
Now assume for a moment that in any of these endeavors that the objective does
not change. Which is the most important out of the remaining two; the
specification or the plan? The correct answer is the specification; it contains
the points of reference by which attainment of the objective is measured, and
from which plans are checked. If the objective is to travel from A to B, this
is the navigation chart that contains points A: the starting point, B: the objective
and X: the Current location, from which can be drawn a series of short plans
that shorten the distance between X and B, but always progress is measured and
checked by referring to the chart. If conditions or events force a change of
plan, a detour, then new plans can be drawn up quickly to accommodate the
change. If the objective changes or shifts, the specification/chart may also
have to be changed.
I have to
admit, I have been a software developer for 12 years, and had a cynical
skepticism of the specification or requirements document, but now I have
changed my mind. Writing this post has actually convinced me of how valuable
the requirements document is, and how valuable a good specification is in
software development and life.
No comments:
Post a Comment