In the conclusion to my previous column (see Resources), I promised that this column would be dedicated to the various methods of requirements gathering in an agile development process. As I began work on that column, however, I realized it might be worthwhile to begin with the larger discussion of agile software development. But as I began work on that topic, I found myself itching to discuss the related topic of holonic software development.
This isn't surprising, because I believe holonic software development is the next step toward agile software development. I'm sufficiently excited about it that I have chosen to shift my itinerary and introduce my very own Holonic Software Development Manifesto. We'll return to the topic of requirements gathering next time.
The agile software development movement has made a significant impact on the theory and practice of software engineering. Its adherents have successfully challenged and refuted some of the tried-and-true principles of good system development, replacing them with their own. Fundamental to the movement are four core values, first outlined in the Manifesto for Agile Software Development (see Resources):
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
In practice, these values mark a departure from those espoused by traditional software development methods. The overriding goal is to create an environment more conducive to successful software development. To be sure, the agile movement has made its mark on the history of software development. But, revolutionary as it is, the agile movement is only the first step into a more complex and rewarding development practice. Holonic software development is the next step.
During the industrial revolution, Mr. Frederick Winslow Taylor studied the way that people worked. He conducted time and motion studies to optimize the use of physical skill to efficiently create products. Taylor was known for his dogmatic adherence to the principles of efficiency. His famous quote summed up his feelings toward the workers of the industrial age: "In the past the man has been first; in the future the system must be first."
Adherence to efficiency and the system-first, or process-first, principle are two of the building blocks of what we now know as quality management. Quality management is the study and implementation of those activities that, when done correctly, lead to improved quality. The key words are done correctly. These words form the safe-harbor statement of any quality management initiative. It can be safely said that if your business, manufacture, or engineering practices do not improve quality, you have not correctly implemented them.
While I don't believe that there is a quality-management crisis in software development, I do see ongoing failures in our industry. These failures are often attributed to process and technology, the excuse being that the processes have been implemented incorrectly or that the technology is immature. But I think blaming processes and technology for failure is often a cop-out. Especially when you consider Alistair Cockburn's assertion that processes and technology are second-order elements in successful software development (see Resources).
People are the first-order elements of any software development project. Any good first-line manager knows his or her team members are the project's first and best asset. One software-development principle that will never be overturned is that good people build good software. But if this is so, should we blame people when our development projects fail? The answer is no!
I believe that the best place to look for the behavior that reflects good software development skills is perhaps the most unlikely. It is the battlefield. Two of the best practices that lead individual soldiers to achieve great things are training and initiative. The best armies allow individual soldiers to make decisions about how they will achieve their objectives during combat. Many battles have been won by the actions of a few soldiers thinking and acting as individuals while also working together as a team.
An entity that maintains its individuality while functioning as part of a whole is called a holon. This term was invented by Arthur Koestler by combining the words holos, or "the whole," and on, "the part." Holons have been used to describe the behavior of society, cells, organizations, and most recently, manufacturing. I believe that holonic behavior is how software developers actually -- and, perhaps, ideally -- work.
The fact is, we continue to follow the ideas of Frederick Winslow Taylor when developing software. Time and motion studies spring up with astonishing regularity in the academic circles of software engineering. Yet software development, like many other elements of the information age, is not about time and motion. It is about creativity, innovation, and people.
In adhering to ideas born of the industrial age, we perpetuate a manufacture-based assembly-line-production mentality and environment for software development. In this environment, the individual cannot thrive. He is not empowered to create change, and so cannot be blamed when a life cycle that calls for change -- the software development cycle -- fails. Perhaps it is time to stop treating process and technology as first-order elements and let the real first-order elements -- people -- take center stage.
Software engineering is a craft. It requires the use of intellect. Its practices are sophisticated and require knowledge. Best practices are still being developed. Because software engineering is so broad, no single person can "know" it all. Because the field continues to evolve, constant effort and learning are required to keep up.
If you are a good developer, modeler, or manager, you know what I mean. You have had exposure to a variety of techniques and you routinely choose the best one for the job. You adapt in crisis and manage to come through with a solution. You embody holonics. Do you need a software development process that specifies what you should do next at any given moment? Not at all.
Truly holonic software development organizations recognize that different people think in different manners. Some people are abstract, others concrete; some are strategic planners, others action oriented. Holonic organizations use technology that allows people to work together while choosing the best way of getting their work done. These organizations allow people to work the way that they find the best. In short, holonic software development requires constant learning and individual adaptation. It encourages diversity.
I make these assertions with the caveat that our training isn't as mature as it ought to be. In contrast, the training of soldiers dates back thousands of years (at the very least). It has evolved and matured over centuries. New technology changes some of the ways that we conduct warfare. But many of the basic patterns of war -- and so the training of soldiers -- remains the same regardless of changes in technology. We adapt timeless lessons as we embrace technological change.
Half of effective combat training is providing soldiers with an arsenal of battle tactics to choose from. The other half involves teaching them to make up their own tactics as they go along. Likewise, I would attest that half of the effective education of a software developer lies in the acquisition of knowledge and skills. The other half lies in learning to work with change, to move quickly across a constantly shifting terrain. In short, to innovate.
Software development without a safety net
Many of our software development processes provide very little of a safety net. Some suggest iterating over the process itself, as if constantly revisiting the same state diagram will eventually yield more information. Iteration over our artifacts can improve them, but only when there is a method of feedback involved. When there is a need to know where we might have gone astray, simple iteration is not enough.
A growing trend is toward activities that can be combined to correct expected mistakes. This is called complementing. For example, we balance use case modeling with domain analysis to ensure that our ensuing object models are object-oriented, not functional. These complementary activities keep us from making common mistakes.
Without complementary activities, second-order elements such as process and technology become our only safety net; we can blame them if we run into trouble. Because most software development processes have at most two dimensions, perhaps they deserve this blame. Certainly processes serve no other purpose than to give us the feeling of control: a false safety net.
Does this mean that you can throw out your software development process and develop, truly, without a safety net? Only if you're ready to accept responsibility for project failure.
On the other hand, if you aren't adapting, you aren't trying new ways of doing things. If you aren't trying new things, you aren't learning, evolving, becoming optimal. This is a constant search, one that none of us is likely to conclude anytime soon.
Even if you choose the safety net of an established process, it is unlikely you're following it completely. Not unless everyone on your team thinks alike. If you do find the ultimate process that everyone on the teams finds optimal, and that suits all the projects you undertake, please send it to me. I'm not expecting many entries, however, because Jacobson's law states that there can be no such process. I believe that even within a highly cohesive team no process will suit everyone's way of thinking. There are too many differences between us.
Holonic software development is a logical extension to the agile movement. It requires an advanced understanding of the techniques used to create software, and it requires developers to take responsibility for delivering systems. The holonic software development team uses process as a guide, not as a crutch. The team goes "out of band," or ignores the process when common sense dictates.
This article is not a definition but a manifesto. It offers a vision of a better way to deliver software systems, one that takes advantage of the activities defined by many of the agile processes. As such, I have considered best practices in software development and stressed complementary activities as a method of correcting mistakes during development.
We'll stay on this topic in the next column, where we'll return to the promised discussion of use cases, features, and user stories. I'll show you how to make these elements part of your holonic software development toolbox, and also describe how these elements support a front-loaded, balanced, or back-loaded approach to building software. Stay tuned.
- For an outline of some of the principles of holonics, see the research paper
"Holonic
Manufacturing Systems" (Peter B. Luh and Ling Gou, Department of Electrical and
Systems Engineering, University of Connecticut).
- Read all of Granville Miller's Java Modeling articles.
- Find more Java resources on the developerWorks Java technology zone.
Granville has over a decade of experience in the object-oriented community. He is coauthor of the Advanced Use Case Modeling series and has presented tutorials at various object-oriented technology conferences worldwide. His hands-on approach to object-oriented development has been the result of his work with companies that range from startups in the very early stages to some of the most established software giants. He is currently teaching seminars, tutorials, and classes in agile processes, methodology, and Java technology, as well as mentoring and helping to deliver aggressive projects. Contact Granville at rmiller@togethersoft.com.
Table of contents
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags