Level: Introductory Gary PolliceWorcester Polytechnic Institute
14 May 2004 From The Rational Edge: In this month's column, Gary Pollice discusses the often overlooked necessity of tailoring a software development process to match the people, tools, and project type.
As Ward Cunningham reminded us in his keynote address at XP/Agile Universe
2003, in the software development world there is no such thing as an absolute
best practice. Best practices vary according to the project's context.
But how do we define context, and what elements do we need to consider in formulating
our own best practices?
In his book Software Engineering: An Object-Oriented Perspective, Eric
Braude summarizes the elements of context as the four Ps: People, Process, Project,
and Product.
1
I would depart from this slightly
and discuss context as People, Tools, Project, and Process.
People. Software development does not occur in a vacuum. We build software
to satisfy the needs of stakeholders who may be clients, people from other departments
within our organization, our managers, or anyone else who cares about the results
of our development effort. Communication is a large part of the people component.
Some methods, such as Extreme Programming (XP), suggest that a client representative
work directly with the development team throughout the project to foster efficient
communication. If the client cannot or will not make this commitment, then the
project's communication methods and context must be different. The space
that people work in -- private offices, cubicles, or open space -- and
team structure can affect communication and relationships as well.
Tools. The tools and platforms that a team uses represent another component
of context. If a team is developing software that will only be used on Microsoft
Windows platforms, the tools that team uses to develop, test, and deploy its
products will be different from those of an organization that builds software
for multiple computing platforms.
Project. Project type is also a key contextual consideration. Developing
a new software system involves different challenges, freedoms, and constraints
than performing maintenance on, or adding features to, an existing system. The
amount of effort you must spend on different activities and language choices
will vary by project type.
Process. Based on my years of experience, process is by far the
most problematic component of context -- one that managers most often ignore.
That might be because every project team follows some sort of process,
whether it is formal or informal, standard or highly individual to the particular
project, good or bad. However, this is the context element that managers should
treat with the greatest care and thoughtfulness as they seek best practices
for their particular projects. In the remainder of this article, we'll
examine some common problems that arise when managers do not pay enough attention
-- or pay the wrong kind of attention -- to process. I suspect that
most of you will be all too familiar with at least one of these problems.
Problem 1: Using
a process "as is"
One of the most common process violations is adopting a standard process without
modification. This is a recipe for disaster. I've heard some managers say,
"We're working with a proven process, so why change it?" However,
the issue is not about changing a successful standard process; it is
about customizing the process.
The truth is, no standard process is going to work "as is" for your
particular project. Moreover, even if you modify a process for your organization,
it is highly unlikely that you can apply exactly the same process successfully
to one project after another. That is why modern processes encourage you to
modify them -- first to work within the context of your own organization
and then for each project you undertake. This is part of process improvement.
Some organizations make things even worse by trying to follow a standard process
to the letter. While working for Rational Software, I was assigned to help an
organization adopt Rational Unified Process,® or RUP®,
on its first project. When I joined them, the project team was not making much
headway. Although they had completed many process artifacts, they had no software
to show for all their time and effort, and they were pretty unhappy with RUP.
It took me only a few minutes to discover the root of the problem: The managers
in this organization had decided that since they had acquired RUP, then, by
golly, they were going to do RUP -- all of it! Following each instruction
and completing each artifact, they figured, would give them the best chance
for success.
But that's not how a process works. If you don't take time to customize
RUP to fit your project (and RUP is explicit about the need for customization),
you have almost no chance of success. That is because the process becomes
all important, and the project and product become secondary. Fortunately, although
it took me awhile to convince the team to make changes, the client and I were
able to formulate a version of RUP that fit the project. When the team focused
only on the artifacts that would help it reach its business goals, the process
helped them move forward quickly.
Another time I was assigned to help a large company adopt Extreme Programming
(XP)
2
for a project. As Kent Beck explains,
XP works best for small development teams -- approximately ten developers.
But the project under consideration had about seventy developers, many of them
contractors. Work was being done at several locations, and clients were distributed
around the world. The company was concerned about lack of progress on the project
and asked me to analyze the problem. Again, this didn't take too long.
The development manager was determined to use XP, regardless of the project's
size and needs. He had read a lot of success stories about XP and wanted to
be on the leading edge of development practice.
The project characteristics made it impossible to follow most XP practices
effectively, so the team members ignored what their manager told them and did
whatever they thought was right. The problem was, there was no agreement on
what was right. Chaos ensued. In this case, despite my efforts to rescue it,
the project failed.
In both examples, team members and upper-level managers blamed the process
-- wrongly -- for their problems. In reality, the fault lay with the
managers who insisted on imposing an "as is" process without modifying
its practices for the project.
Problem 2: Making
the project fit the process
Another common process violation involves changing the project to make it
fit the process. In such cases the team might have customized the process, but
not necessarily for the project at hand. If team members used a modified process
successfully on prior projects and grew comfortable with it, they become reluctant
to move out of that comfort zone. Sometimes developers who have been successful
using XP feel that if the practices don't work on their current project,
then there must be something wrong with the project. "We know the practices
work," they say. "Therefore, we must change the project."
However, the fact is that every project has a "personality" that
we must understand and cannot easily change. If we succeed in changing it, then
it's no longer the same project. Most often people try to modify part
of the project so they can use their favorite technique rather than attempting
to recast the whole thing. But these efforts rarely work.
For example, there are several excellent ways to specify requirements for a
compiler: formal grammars, algorithms, and so on. Yet I've heard many discussions
about how to specify a compiler with use cases. This happens when people who
understand only one method for specifying systems -- with use cases --
go out of their way to "shoehorn" the compiler's requirements
into use-case form. Typically, they end up either wrapping a use case around
the formal description or producing use cases that omit key specifications for
the compiler. Either way, the requirements will not produce a working compiler.
Another troubling way managers try to alter projects to fit the process is
by removing people who won't go along with it. They value process over
people. This has been true for managers pursuing agile methodologies, even though
those methodologies clearly state that you should value people over process.
As with RUP, managers should apply elements of methodologies such as XP selectively.
People play a major part in determining a project's personality; they are
the most variable characteristic in the project's context, and the process
should be modified to suit them. For example, if pair programming does not feel
comfortable or natural for your team members, forcing them to adhere to that
work style would be counter-productive.
Do all men have three eyes?
Trying to apply the same process for every project is like trying to use a
hammer for every construction job. The hammer doesn't work very well when
you have to put a bicycle together. If you try to turn the bicycle into a doghouse
(i.e., to modify the project), that will not work, either. What underlies both
of these approaches are false assumptions.
If you have ever taken a logic course, you will recognize this syllogism:
All men are mortal.
Socrates is a man.
Socrates is mortal.
To determine whether the conclusion is sound, you must look carefully at the
starting premise. Consider the following:
All men have three eyes.
Socrates is a man.
Socrates has three eyes.
We know that all men do not have three eyes, so we also know that the
conclusion is false.
There are many subtle variations on this basic syllogism, and logicians must
scrupulously analyze each premise to determine whether the conclusion is valid.
We should take the same care in determining whether a practice is appropriate
for a project. If we start by admitting that there are few, if any, universal
truths about software development projects, then we can stop trying to make
universal assumptions and find other ways of doing things.
What's the solution?
If the problem of process-project mismatch is so common, why aren't we
doing more about it? The most obvious reason is that most managers don't
really want to -- until they have felt the full effect of a mismatch. It
usually seems easier to use a process as-is or do things we know how to do,
whether they're appropriate or not, than to analyze what we should do and
make necessary changes.
Software development is a knowledge-based discipline (or set of disciplines).
To succeed you must continually improve your knowledge and apply it. You also
have to apply a healthy dose of common sense. Experienced software developers
-- those who have worked on a broad portfolio of successful applications
-- have much common sense about how to build software. They have
learned how to choose the right process and tools for a project. They have learned
fundamental lessons about how to match techniques to the job at hand. Most important,
really good developers have learned how to blend their common sense with that
of others to build a synergistic project team.
Many organizations realize that they need to find a reasonably standard way
of working that still gives individual teams the freedom to get their job done
in the most efficient manner. Larger organizations need greater consistency
and formality, as well as a wider range of communication methods than smaller
organizations; they have more people with different backgrounds who need to
understand and use the system. It's not practical to ask the people in
accounting to look at the code if they want to see what your system does.
Fake it!
Almost two decades ago, software engineering thought leaders David L. Parnas
and Paul C. Clements published a paper called "A Rational Design Process:
How and Why to Fake It."
3
This paper had
a profound effect on the way I approached software development. By that time
I'd worked in several development environments within different companies.
I knew what wonderful things you could do with the freedom to create great software,
and I also knew how you could get mired in needless process. This paper gave
me the key to unlocking a team's potential in almost any environment.
The premise of the paper is simple. We all want a single process that works
-- a rational design process. However, we also recognize that we
can never follow a process exactly. Things change, people -- not machines
-- are working on the project, and so on. The authors liken the search for
the ideal process to the search for the philosopher's stone. We're
not going to succeed.
So they suggest that, rather than trying to find and follow the ideal process,
why not make it look like you did? At the time this was a pretty radical
approach, but the concept is quite simple and based on common sense. It works
for two primary reasons.
First, it allows you to perfect your artifacts when they are most valuable:
after the project is over. As the project proceeds, depending upon its size
and formality, the requirements, design, and architecture will change. You can
either sink a lot of time into updating, synchronizing, and republishing the
associated artifacts, or you can do just enough to make sure the right people
know about the changes. Then, if you're using an iterative development
approach, at the end of the project you can add a final iteration to update,
organize, and synchronize the artifacts (usually documents) so that maintenance
professionals can easily understand the system's purpose and structure.
Second, it enables you to give process the right degree of emphasis. Most people
who have a negative view of process are reacting to the amount of "useless"
work it entails. The agile movement represents an effort to eliminate such work.
But you must maintain a balance among the important contextual elements in your
project -- People, Tools, Project, and Process -- so that the work can
continue for future releases. Faking it provides a way to achieve that balance.
I urge you to read the Parnas and Clements paper. I have all of my students
read it, and it might have a profound effect on you, too. If you can understand
the singular formula for success that it promotes, then you will be well on
your way to a long, successful career in software engineering.
Notes
1Eric J. Braude, Software Engineering: An Object-Oriented Perspective.
John Wiley & Sons, 2001.
2 See Kent Beck, Extreme Programming Explained (Addison-Wesley,
1999) and the "Manifesto for Agile Software Development" at http://agilemanifesto.org/
3 Published in IEEE Transactions on Software Engineering, February 1986.
About the author  | | | Gary Pollice is a professor of practice at Worcester Polytechnic Institute, in Worcester, Massachusetts. He teaches software engineering, design, testing, and other computer science courses, and also directs student projects. Before entering the academic world, he spent more than thirty-five years developing various kinds of software, from business applications to compilers and tools. His last industry job was with IBM Rational Software, where he was known as "the RUP Curmudgeon" and was also a member of the original Rational Suite team. He is the primary author of Software Development for Small Teams: A RUP-Centric Approach, published by Addison-Wesley in 2004. He holds a B.A. in mathematics and an M.S. in computer science. |
Rate this page
| 
