- We Fail Too Much
- Definitions of Success
- The Standish Group
- Doing the Wrong Things
- Doing the Things Wrong
- Time Goes By, Things Improve
- One Reason: The Civil Engineering Analogy
- Giving Up Hope
- Ignoring Your Mother
- Bridges Are Hard, Software Is Soft
- We Swim in an Ocean of Change
- Accept Change
- Embrace Change
- Capitalize on Change
- A Better Analogy: Evolving Systems
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Capitalize on Change
Agile processes are, among other things, an acknowledgment of the realization that software development is like . . . software development. It is not fundamentally like any other activity.
We are in the midst of defining a process that is uniquely suited to the nature of our particular beast, which should go a long way toward making us more successful.
It is also, I submit, another aspect of software development evolving into a true profession. We do not make software the way anyone makes anything else. We have our own way, because what we do is unique, complex, and requires special knowledge and skills.
Maybe that is part of what makes something a profession. Doctors do not work like carpenters. Lawyers do not work like teachers. Complex, unique activities tend to find their own process, one that suits them uniquely.
That said, it can be tricky to code in an agile process, where change is not only allowed for, but expected (and happens more frequently). If we ask the customer every couple of weeks if we are on track, there will generally be things that are not quite right, and so the answer will rarely be "Yes, that is fine." Since we are asking for validation more frequently, we will be making changes more frequently.
Frankly, even if we do get it perfect, it is human nature for the person being asked to validate the software to find something wrong. After all, he needs to justify his existence.
Earlier, I wrote that "there are ways of designing that allow for change, even unforeseen change, without excessive costs." I wonder how many of you let me get away with that.
"There are ways" is pretty vague, which is an important issue if, again, we are going to allow the customer (and ourselves) to change things more frequently.
Fortunately, this book is also about how patterns promote professionalism, and the value they bring to an evolutionary process. Pick any pattern you like and whatever else it does, I guarantee that it makes your design easier to change. Here are a few examples that should be familiar to you if you have studied design patterns already. (If you have not yet studied them, I have included in Appendix B, "Overview of Patterns Used in the Examples," descriptions of all of the patterns I use in this book.)
-
Strategy. The Strategy pattern enables the programmer to substitute an algorithm or business rule without affecting the code using the rule. This makes it easier to add new implementations of an algorithm after the design is in place.
For example, if you are amortizing the value of fixed assets and the customer says, "Oh, by the way," in the final month of your project, telling you about some other method of amortization he will need, you can plug it in more easily if you used a Strategy to vary it in the first place.
-
Decorator. The Decorator pattern is designed to enable you to add functionality in front of (or after) the main entity being used, without changing the entities that use it. This makes it easier to add new functions, in different combinations and with varying numbers of steps, after the design is in place.
For example, if your customer has reports with headers and footers, and then suddenly remembers a special case where an additional header and two additional footers are needed, you can add the functionality without changing what you already created, if you used a Decorator to encapsulate the structure of the reports, and the number and order of the headers and footers in the first place.
-
Abstract Factory. The Abstract Factory pattern controls the instantiation of sets of related objects used under particular circumstances. If you design your main code so that it can ignore the particular implementations present, it can let the Abstract Factory decide which particular objects to use. This makes it easier to accommodate an entire new case.
For example, if you design the system to run on UNIX and NT, and the customer realizes that, in this one case he forgot about, it needs to be deployed on Solaris, an Abstract Factory would allow you to add an entire new set of device drivers, without changing anything else in the codebase.
Of course, if you are not already up to speed on these patterns, fear not. We will dig into them more fully later in the book.6 Simply know that they are not just cool ideas or clever bits of code; they are part of the fabric of our profession.
Patterns were and are discovered, not invented. Something becomes a pattern because it worked, because it helped someone else achieve a better design at some point in the past, and because that person recorded this success and passed it on to you—just like carpenters, masons, and lawyers have been doing for centuries.
And, just like their patterns helped them create their own unique processes for their fundamental professional activities, so do ours.
- Patterns support agility, even though patterns were originally discovered before agility became a force in our industry. Agility, in turn, helps codify a unique process for software development, and this helps define a professional community.
- Patterns help us to communicate, and to define what we are doing within the unique and specific boundaries of the software development profession. Moreover, the communication that patterns enable is not merely implementation-speak, but captures nuance, wisdom, caveats, and opportunities.
- Patterns provide a clear path to entry for new developers, who are seeking the repository of knowledge from the profession they aspire to engage. Studying patterns is a clear way to strengthen your grasp of good design.
This is why, at Net Objectives, we teach patterns in this way. Not as reusable solutions but instead as professional best-practices. How a pattern is implemented depends on the specifics of the problem domain, the language, and framework being used, and so on but the value of the pattern is always constant. This turns the study of patterns into a much more valuable pursuit.
Once patterns are understood at this level, however, a new and more interesting way to think about them emerges. In Alan Shalloway and James Trott's book, Design Patterns Explained: A New Perspective on Object-Oriented Design, they discuss
- The principles exemplified by patterns
- The practices suggested by patterns
- A way to apply these principles and strategies in software development generally, even when a particular pattern is not present
This new way of thinking about patterns moves us even closer to becoming a profession as we identify universal principles that inform software development. As patterns become more prevalent, a greater sharing of terminology, thought processes, concerns, and approaches becomes more widespread.