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.
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.
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.
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.
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.
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.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
