|
|
SIGDOC Newsletter
March/June 2004
:: Volume 5, Numbers 1 and 2
Features
Affinity and the Application of Best Practices
By Rob Pierce
In reading an article related to software development in general and
one company’s tools offerings to customers in particular, I recently
came across a phrase that caught my interest and stopped me for more
than a pause - Technology Affinity. The description written by a developer
stated that:
”Technology affinity addresses the degree to which both parties
have to agree to a common technology base, to enable integration between
them. Tightly-coupled systems have a higher dependence on a broad technology
stack. Conversely, loosely-coupled systems make relatively few assumptions
about the underlying technology needed to enable integration.”
He then went on to provide an excellent example:
“
Our national road systems represent a very good example of a loosely-coupled
system – imposing few temporal or organizational constraints or
technology requirements. Transactions of very different duration can
travel over roads – from riding your bike next door to visit a
neighbor, to driving across town to pick up dinner, to transporting your
products to new markets across the country. On-ramps come in a variety
of shapes, and can be changed significantly without preventing you from
getting onto the highway. While the country may impose some basic regulatory
guidelines, states and municipalities can have a great deal of latitude
to impose their own regulations and to provide their administrative goals
on the part of the system they control. The technology requirements are
relatively low – enabling a huge variety of vehicle shapes, sizes,
capacities, and utility. Many of these same characteristics can be attributed
to the Internet as well.
back to top But there are some drawbacks to loose coupling:
“
However, loose coupling also introduces a degree of inefficiency – sub-optimization,
based on the desire to maintain the freedom and flexibility inherent
in loosely-coupled systems. To maintain the analogy, railroads and airplanes
represent more tightly-coupled systems, but exist because of the additional
efficiencies they can provide. They are optimized to a set of specific
objectives – either to achieve optimal fuel efficiency, or time
efficiency, respectively.”
From the above information, I waxed philosophical and thought that,
a loosely-coupled life may provide a freer and less restrictive lifestyle
but is also likely to produce a less-efficient and less-optimized life.
If the goal is to be happy or successful, you will likely be more apt
to reach your objective by having some form of list or requirements
or
guidelines to live by.
Certainly Benjamin Franklin concurs, in his Autobiography, with his
Rules to Live By, which I happened to be reading at the time. So, too,
did
the ancient Greek and Roman writers such as Plutarch and Cicero, who
wrote about the “Good Life.”
The concept of affinity is timeless and thus a classic concept, I decided,
since it relates to the mind. And it is relevant in describing design,
implementation, and configuration concepts in any walk of life, be
it living the good life or using logic to create technological solutions.
I see the ability to postulate philosophical logic as not unlike using
logic to determine an algorithm that solves a problem and then programming
or implementing that solution. With philosophy, you use logic and reason
to analyze the problem, postulate a solution and then try implementing
the solution by acting on your philosophy or helping others to act
on it (or at least think about it). In software development, the postulated
solution is called the algorithm.
With that said, one middle-ground figure between the classicists and
the technologists was Benjamin Franklin. He was mostly focused on taking
concepts and making practical use of them. The elements of nature were
interesting to study but only to the extent that something useful could
be made of the studies, which in the high technology world sounds a
lot like Research and Development to me. To take the conceptual and
then
try to make it tangible is what successful people, cultures, and enterprises
do.
In software development, there are development tools to help people
take complex concepts and ideas and turn them into actual working applications
that enable others to accomplish tasks. There is a growing awareness
and increased competition in the business of selling software development
tools. The average person has a hard time conceptualizing the concept
of software development tools. Telling them that “it’s software
to help engineers develop software,” doesn’t quite register
for people not familiar with software development concepts. The explanation
how developers are the people who write code that is the “stuff
on a cd” that makes something actually happen, (such as the game
or the word processing application running on their computer) registers
dull nods. Many if not most people use their software with little awareness
that it is code that was written by developers. But ultimately it is
not necessary or important for them to know these details, just as
we in software development do not need to know all of the details of
our
home heating systems or electrical systems in our homes or of our appliances.
On the other hand, if you are somewhat like an enlightened Ben Franklin,
you are interested in learning the details, at least to some degree,
in these systems, and know they are logical and understandable by a
rational mind.
back to top Technological affinity
If technology affinity is a term to describe the compatibility between
different subsystems or components or portions of hardware and software,
then can we also have a term to describe the human aspect of compatibility,
say, “technological affinity”?
For example, the degree to which one person, one team, one organization,
can comprehend, learn, and utilize a collection of technology - hardware
and software - to accomplish whatever activity, task or project they
are working on, could be viewed as technological affinity.
A loosely coupled technological affinity would be one where a team
of individuals had a varying degree of expertise in different areas,
and
who were all experienced in different aspects of tooling and technology,
that is, they had different areas of expertise.
There are some obvious benefits to this type of system. Everyone has
some unique talents to offer the team. There are also some obvious
potential issues if everyone, for instance cannot share files and work
with consistency
(and the same tools).
On the other hand, a tightly coupled technological affinity might describe
a team that includes individuals all closely related as far as knowledge
and experience. They all might have similar knowledge of certain software
applications or operating systems. They all might have to follow standard
protocols defined by the company or program or project manager that
ensure consistency both in the finished product as well as development
cycles
to get a project through to completion.
It is likely self-evident that some degree of middle ground is the
most realistic scenario for most organizations, and for all but the
most obsessive
individuals!
Without a certain degree of process and consistency, the coupling could
be so loose that the links break, so to speak. For a system to work,
be it software, hardware, or interpersonal, the pieces need to work
together. That requires a certain amount of "glue." The glue
is likely a combination of consistency in the tools the team uses,
the collaboration
or communication mechanisms agreed upon, the roles of each team member
and their responsibilities, and the development plan as a whole.
Too much process might strangle a project but too little will likely
allow chaos and failure. Finding a balance that will ensure success
is always the goal. And there will never be just one standard solution.
But there are certain variables you can work with from which you can
develop a set of standards to follow.
back to top One method of addressing the issues of affinity is to use tooling that
is standardized across the team or organization. Another method is
to follow a protocol on how work is done. This would be called a process.
Tooling and process are two primary variables. Following guidelines
or
standards that encompass these two variables can chart the course of
a project.
In software development, there is a set of what are called, "best
practices." The six best practices of software development are:
- Iterative development, which means, do things in cycles, chunk
by chunk, not all at once.
- Manage requirements, which means, plan
before you start developing a solution and specify the objectives
and what needs to be included
in the solution before you start actually working on the solution.
- Use
component based architectures, which means, a solution should be
able to be developed and viewed as a collection of
independent
and inter-independent
objects.
- Model visually, which means create diagrams to help
modeling (that is, design) the components and their details that
will comprise the
overall solution.
- Test each iteration, which means, do not
do all of your testing at the end of the development cycle but throughout
it, through
each iteration
(if you have the resources). And, develop a testing plan.
- Control
changes, which means, manage change in a structured, organized way,
including managing and storing your content.
back to top
Defining the best practices to apply to a particular project,
following them, and learning from the experience for
future projects can help
provide solutions to the dilemma of determining the
appropriate degree of affinity
for hardware, software, or the project to develop hardware
or software, or any product for that matter. There happen to be tools that are designed to provide
solutions for managing and automating each of the
six best practices.
While the
tools are designed
and marketed to be software development tools, they
can all be used to develop other products and complete
other
kinds
of projects
as
well. For instance, each of these best practices
can be applied to designing
and developing documentation or other forms of technical
information.
In many software organizations the documentation
teams use the same content management systems or
change management
systems or collaboration
software
that the development teams use. Writers that have
a working knowledge
of the tools and technology that the developers
in their organization use, makes for a more collaborative
environment.
Making it
a requirement for writers to use the software development
tools and process that
the developers use is an example of tighter coupling,
in the affinity spectrum.
In future articles, I will present each of the
six best practices and examples of the tools
that enable
these
best practices.
In particular, we will explore how the tools
and practices can be
applied to the
profession
of technical communication or information development.
In last year's SIGDOC conference, in San Francisco,
one of the key messages delivered was that technical
communication
as a
profession
must be followed
and viewed as an engineering discipline, which
in this case
is an example of a tighter coupling of technological
affinity.
back to top |
