skip to main |
skip to sidebar
The following two articles of mine appear in the April 2006 issue of CM Crossroads Journal (the month's theme is "Agile Development Practices"):
If parts of them look familiar it's because these articles evolved out of multiple entries from this blog over the past year :-)
The more I look at FDD, the more I really like it as an agile method suitable for a large projects and companies, especially those striving for CMM/CMMI. I also really like the work David Anderson has done tying FDD together with Lean, TOC, and SixSigma.
I'd be real interested in any work on melding FDD together with many of the project management practices of Scrum, and some of the programming practices of XP (e.g., continuous integration, TDD, collective ownership, and refactoring).
As a follow-up to my previous blog-entry about Agility, MDE, and how perhaps FDD and Color Modeling could be the missing link (with the latter being the equivalent of Refactoring to Patterns, only for models instead of code), here are some more resources on Color Modeling: - Wikipedia page on UML Colors
- A History of Color Modeling
- Peter Coad's descriptions of feature-sets and color modeling patterns including a color modeling overview, and Archetypes, Color, and the Domain-neutral Component
- Color Modeling and The Law of Demeter, by David J. Anderson
- Whole Part Relationships in Color Models, by David J. Anderson
- Arguments about Color, by Daniel J. Vacanti
- The Coad Letter: Modeling and Design Edition, Issue 68, a New Beginning
- The Coad Letter: Modeling and Design Edition, Issue 44, Strategies -- Boundary; Colors; Time Line; Status
- Other "Coad Letter" articles related to Color Modeling
- An excerpt from "Object Modeling in Color with UML"
- UML Color Modeling with Archetypes
- UML in Color to UI Design : White Paper : uidesign.net
- the recently created colormodeling YahooGroup
Also see the EpoWiki "Agile" Page for a great page of resources on "Agile" in general.
The February 2006 issue of IEEE Computer is devoted to Model-Driven Engineering (MDE). MDE is actually a bit broader than MDA/MDD, because MDE (allegedly) covers more of the lifecycle, and corresponding process and analysis. Doug Schmidt's Guest Editor's Introduction to MDE is a pretty good overview of the current theory and practice and the obstacles to overcome.
A co-worker of mine is very interested in combining Agile methods with Model-Driven Engineering. He feels that the benefits of agility and of model-driven code-generation show tremendous promise as a breakhrough combination in productivity and quality and he is stymied that there aren't a lot more folks out there trying to do it.
He attended UML World in June 2005 and had some discussions with Scott Ambler (AgileModeling), Steve Mellor (co-creator of the Schlaer-Mellor OOAD method, and co-author of "Agile MDA", Executable UML and MDA Distilled), and Jon Kern, Agile MDA Evangelist (who helped Peter Coad launch TogetherSoft). He found most of what they had to say supported the possible synergy between Agility and MDA, but was very surprised to see AMDD folks and XP/Scrum folks throwing away their models once they had the code for it.
Upon hearing the above, I noted that Peter Coad is quite possibly the missing link between MDE and Agility:
The potential mismatch between MDA, with AMDD and XP-like Agile methods, is that:
- Full/pure MDA strives for 100% generation of all code and executables directly from the models.
- Ambler's AMDD, and "domain modeling" espoused by the likes of Robert Martin, Martin Fowler, and others in the XP community strives for "minimal, meaningful models", where they model only as needed, as a means of gaining more understanding, and then embed the knowledge gained into the code and/or tests.
I beleive FDD has the potential to bridge the gap. It strives for a comprehensive domain model, but from that point the code is written by hand (using coding practices that are traditionally non-Agile in nature, including strict-code-ownership, and formal code reviews/inspections). FDD doesn't say anything about using MDA/MDD techniques to auto-generate code, but the method is extremely amenable to doing exactly that.
Furthermore, doing so would remove a lot of the manual parts and practices of FDD that many consider to be the least "Agile". And much of the FDD "Color Modeling" patterns and techniques are very much the equivalent of refactoring and design-patterns that are currently used for code. See the end of this message for some more resources on Color Modeling.
In my own humble opinion, I think the "sweet spot" is somewhere in between 100% code generation and "hand-crafted" code. I realize that 100% is the ideal, but I'm thinking about the 80/20 rule here, and whether trying to eliminate that last 20% is perhaps not always practical.
I think the biggest barrier to doing that today is tools: - The modeling tools are good at handling the structure, but not as much as the behavior.
- High-level programming languages like Java and C# and their IDEs are more convenient for specifying behavior (which is still largely textual in UML 2 and Action-Syntax Languages).
- It is extremely difficult to maintain the non-interface code for a "class" or "package" unless it is either 100% manually coded or else 100% auto-generated. If it is 50-50, or even 80-20, then the "nirvana" of seamless and reversible round-trip design to code and back just isn't quite there yet.
What would get us there and help close that gap? I think the "melding" of the IDE with the modeling tool is what is needed - and it would have to allow specifying code such as Java or C# as opposed to only allowing ASL "code" (most of which looks pretty darn close to Java and C# anyway :) as well as a means indicating if/how a chunk of code was auto-generated or if it was to be hand-crafted, but "navigable" and editable via the Model.
The Eclipse framework shows a lot of promise in helping us get to that point, and has a lot of the groundwork and building blocks already in place, but still has a lot more work to be done.
I hear some of you saying, "Okay Brad, I see what this has to do with Agility. But what does this have to do with CM?" Well, in my January 2005 Agile SCM column, among other "crystal-ball gazing" predictions, I talked a little about "Model-Driven CM" and how it would resurrect the once popular SCM research-area of Software/System Configuration Modeling:
- MDE/MDA would readily lend itself to allowing the developer to focus on the logical structure of the code, letting the physical structure (files and directories) be dictated by the code-generation tool with some configuration scripting+profiles.
- This in turn would allow models and modeling to be easily used to analyze and design the physical structure of the code, including build & configuration dependencies.
Of course, we have a ways to go until we get there, but I do believe the trend is on the rise and it's only a matter of time.
Some other resources related to Agility and MDE:
- Anyone going to EclipseCon2006 to see Agile Application Development with Eclipse and Pragmatic MDA
- Hans Wegener's Agility in Model-Driven Software Development? Implications for Organization, Process & Architecture
- Andreas Voelter's Patterns for Incremental/Iterative MDD
- Martin Fowler's Language Workbenches and MDA
- IEEE Software Oct 2003 Point/Counterpoint" on MDA -vs- MDD
- Jorn Bettin, on the Practicalities of Implementing CBD and MDA and where Agile fits in the picture
- Dion Hinchcliffe's Domain-Driven Design: MDD Done Right?
- Alan Cameron Wills' Agile Components - Scaling XP
- A 2004 Workshop on Graph rewriting for Model refactoring in MDE/MDA, sponsored in part by:
- The Program-Transformation.org Wiki-Web and Homepage
- And lastly, Jeff Sutherland writes of Charles Simonyi's latest effort, Intentional Software:
"Simonyi’s vision, and the reason he started his company, is to take the idea of models and go one step further: to link the model and the programming so tightly that they eventually become the same. Programmers and users will be able to switch between many contrasting views of the model they are creating, and revise programs at will simply by tweaking the models (see “Just-in-Time Programming,” below). It’s something like an architect being able to draw a blueprint that has the magical property of building the structure it depicts—and even, should the blueprint be amended, rebuilding the structure anew."
I think there are a lot of folks out there who judge all of "Agile" by what they know of Extreme Programming (XP), quite possibly because that is all or most of what they've heard about agile development.
I think folks (especially agile skeptics) should take a close look at Feature-Driven Development (FDD) if for no other reason than because it is an example of an agile method that is very different from XP. FDD is quite agile while still employing of many of the traditional practices that agile skeptics are probably more accustomed to seeing.
For example, FDD has the more traditional progression of waterfall-ish phases in its iterations (while still being highly iterative and collaborative). FDD does conduct up-front planning, design and documentation and relies very heavily upon domain modeling. FDD also uses feature-teams with chief architects/programmers and traditional code-ownership and code-review (as opposed to pair-programming and refactoring).
To that end, here are some more resources about FDD so folks can learn more about it and become more aware of the fact that XP isnt the only agile "game" in town when it comes to development practices (SCRUM and DSDM are focused primairly on planning rather than development practices):
I had some interesting feedback on my previous blog-entry about Code Stewardship. Most apparent was that I utterly failed to successfully convey what it was. Despite repeated statements that stewardship was not about code access, it seems everyone who read it thought the code steward, as described, was basically a "gatekeeper" from whom others must acquire some "write-token" for permission to edit a class/module.
I am at a loss for what to say other than that is not at all how it works. The code-steward serves as a mentor and trail-guide to the knowledge in the code. Consulting the code-steward is not about getting permission, it is about receiving knowledge and guidance:
- The purpose of the protocol for consulting the code-steward is to ensure two-way communication and learning (and foster collaboration). That communication is a dialogue rather than a mere "token" transaction. It's not a one-way transfer of "control", but a two-way transfer of knowledge!
Perhaps I would have been better off saying more about how Peter Block defines stewardship in his book of the same name (Stewardship: Choosing Service over Self-Interest, see an interesting review here and another one over here):
- Stewardship is being accountable to the larger team or organization by "operating in service, rather than in control, of those around us."
- "We choose service over self-interest most powerfully when we build the capacity of the next generation to govern themselves"
- Stewardship offers a model of partnership that distributes the power of choice and resources to each individual.
- Stewardship is personal - everyone is responsible for outcomes; mutual trust is the basic building block, and the willingness to risk and be vulnerable is a given.
- Total honesty is critical. End secrecy. Give knowledge away because it is a form of power
When practiced properly, collective code ownership is in fact an ideal form of stewardship (but not the only form). Stewardship may ultimately end-up as collective-ownership if given a sufficient period of time with the same group of people.
However, early on I would expect stewards to have a more direct role. And I believe the form of code-ownership that Feature-Driven Development (FDD) practices may seem fairly strict at first, but is really intended to be the initial stages of code-stewardship in the first two quadrants of the situational leadership model.
I beleive the form in which stewardship should manifest itself is situational, depending on the skill and motivation of the team and its members. In Ken Blanchard's model of situational leadership, there are four quadrants of leadership-style, each of which should be used on the corresponding combination of hi-lo motivation and hi-lo skill for a given task:
- Directing (hi directive + lo supportive, for "enthusiastic beginners")
- Supporting (hi directive + hi supportive, for "disillusioned learners")
- Coaching (lo directive + hi supportive, for "reluctant contributors")
- Delegating (lo directive + lo supportive, for "peak performers")
If we apply the concepts and principles of "stewardship" using the appropiate situational leadership-style, the outwardly visible result may appear to transition from individual code ownership, to code guardians/gate-keepers, then code coaches/counselors, and finally to truly collective ownership.
So I would say it is the presence of stewardship which is the key to succeeding with either individual code ownership or collective code ownership. If stewardship is present, then both can succeed; If it is absent, it's likely that neither will succeed. And the collective and individual "styles" are the extreme ends of the spectrum, with "code counselors" as the style in between those two extremes.
I heard another argument today claiming that collective code ownership often results in "no ownership" of the code, and that individual code ownership is better for managing attempts at concurrent changes.Then I heard someone try to counter by saying individual ownership inhibits refactoring and goes against the team ethic of XP and other Agile methods.The problem I have with both of these is that they are each extreme positions. I know from experience there is a successful middle ground, one that is sometimes referred to as code stewardship.Individual Code Ownership, in its purist form, means exclusive access control: no one but the "owner" is allowed to edit the particular module or class. When code ownership is interpreted so rigidly as to exlude allowing others to to make updates, I have definitely seen it lead to the following problems on a regularly recurring basis:
- Causes lots of wait-time and productivity-blocks
- Used as a parallel-development block to avoid merging concurrent changes
- Holds changes/code "too close to the vest" and leads to defensiveness and/or local optimization at the expense of the "whole" team/system
- Increasing the project team's "truck factor" by limiting the number of people with intimate knowledge of that module/class within the overall system
At the same time, I have seen cases where "Collective Code Ownership" degrades into "no ownership" when there is no collective sense of team ownership or accountability.So what is the balance? I think it is Code Stewardship, where the code-steward is both guardian and mentor for the body of knowledge embodied by the module/class. The Code Steward's job is not to safeguard against concurrent-access, but to instead safeguard the integrity+consistency of that code (both conceptually and structurally) and to widely disseminate knowledge and expertise about it to others. - When a portion of a module or class needs to change, the task-owner needs the agreement of the code-steward.
- The task-owner explains what they are trying to accomplish, the code-steward helps them arrive at the best way to accomplish it, and provides any insights about other activities that might be related to it.
- The task-owner makes their changes, seeking advice/counsel from the code-steward if needed (possibly thru pairing or dialogue or other means)
- Before commiting changes to the codebase, the code-steward is involved in review or desk-checking (and possible coordination of concurrent activities)
This can be accomplished by pairing with the code-steward, or simply by seeking them out as an FDD programmer would a Chief programmer/architect. The code-steward is like the "editor-in-chief" of the module or class. They do not make all the changes, but their knowledge and expertise is still applied throughout. The benefits are: - Concurrent changes can still be made and wait-times avoided while still permitting notifications and coordination.
- Knowledge is still disseminated (rather than hoarded) and spread-around the team
- Collective ownership and its practices, such as refactoring, are still enabled
- Pair programming can still be done, where pairing assignments can be based in part on who the "steward" is for a piece of code. (At some point stewards can even hand-off-the baton to another)
I guess the bottom-line for me is that collaborative ownership and authorship is still essential, and code ownership isnt supposed to be about controlling concurrent access (and is very suboptimal as a concurrency-strategy, even though some merge-a-phobic shops will swear by it). If we take "ownership" to either extreme - the result is impractical and imbalanced.
