skip to main |
skip to sidebar
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):
Wouldn't ya know it! On the very same day that I blogged about Customer-Oriented Requirements Architecture (CORA) as The Next Big Thing, it turns out Martin Fowler wrote an article about Language Workbenches which seems to be getting at exactly the same core idea:
- Language Workbenches utilize things like Meta-Programming Systems and Domain-Specific Languages (DSLs) to let the developer work more closely in the conceptual domain of the various subject-matter "spaces" of the requirements and the design.
- They provide all sorts of IDE and refactoring support for the language domain they are created to support.
- It seems a bit more focused on the design-end, whereas my CORA idea is a bit more focused on applying architectural principles and design patterns to the expression and maintenance of the requirements. I believe the end-result is the same however.
The more enabled we become at formally expressing the requirements in a language and framework more closely bound to the problem domain, the more important it will be to apply principles, patterns, and practices of refactoring, encapsulation, modularity, etc. to the groupings of requirements we develop and the relationships within and between them. And Language Workbenches become part of the environment that supports, maintains, and automates requirements dependency management and traceability
Feature-Driven Development (FDD) has an interesting way of trying to do some of this with its feature-sets and color modeling patterns. See recent discussions on the agilemanagement YahooGroup and the newly created colormodeling YahooGroup for more details.
I may blog in the future about the relationship between FDD, Color-modeling, "grammar rules" for domain-modeling, DSLs, and the Law of Demeter.
Robert Martin writes about what is "The 'Next Big Thing." From structured programming, to modular programming, object-oriented, extreme, aspect-oriented and service-oriented .... All have been heavily hyped in their "hey day."
Bob notes almost all of those started off as just "programming" and then each "trifurcated", having "design" and later "analysis" come afterward - completing the waterfall "triplet." Robert (Uncle Bob) Martin writes:
“I hope the next big thing is the big thing that we’ve needed for the last thirty years and haven’t had the guts to actually say. I hope the next big thing is professionalism. Perhaps a better word would be Craftsmanship.”
I notice that, within the past year, Aspect-Oriented Programming (AOP) and Aspect-Orientation has now "trifurcated", completing the waterfall triplet: the last few years have seen books and articles on Aspect-Oriented "Design", and within the last 6-8 months we have a book on "Aspect-Oriented Analysis and Design" and another on Aspect-Oriented Use-Cases.
Aspects and analysis/requirements (use-cases) interests me because I wonder if the trend we're seeing isnt so much aspects, but the same trend indicated by Charles Simonyi's emphasis on Intentional Programming (he now calls it "Intentional Software"), and by the emphasis on Domain-Specific Languages (DSLs) in Microsoft's "Software Factories", and to some extent even eXtreme Programming's representation of tests as precise requirements specification, and the way ObjectMentor's own FitNesse framework is almost a DSL-like front-end for that.
I think programming languages and software specifications have evolved beyond the domain of the coder and designer into the domain of the analyst and the customer.
- Assembly language was just some ever so slight mnemonic sugar (it wasnt even syntactic sugar) on "raw" machine code. We used some short, cryptic but mnemonic names, but it was still making the programmer think in terms of the way the computer's "processing" was organized. We had to think in terms of opcodes and registers and addresses in storage. We had to try and think like the machine.
- Then we got structured languages. You know, the kind where all that pseudo-code we used to write with words like "if then else", "while" and "for" could now be written directly in the language. We made the programming language try and represent the way the sequential logic seemed to go down in our heads. But it was still coding.
- Then with abstractions and objects we made programming languages cross the threshhold from mere coding & programming, to design, where we could now express not merely logical processing directly in the language, but design abstractions and encapsulation and various associations and interfaces.
- Then we built on that with patterns and libraries, and have now adorned it not just with inheritance and templates, but now Aspects and Java's "Annotations"
But one of our biggest technical problems in software development is still accurate communication of the customers and users needs and wants to the folks that have to translate that into working software. All those "shall" and "should" statements and "formal methods" like VDM and Z werent as much help as we hoped.
Enter test-driven development, where we let the customers talk to us in their native language, but we try to write the technical requirements not as vague prose, but rather as executable code in the form of tests, so we can get immediate feedback and use short-cycles. Fit and FitNesse attempt some of the goals of intentional-programming by making a little DSL and GUI to let us write something that looks closer to prose but still generates source-code to make our executable tests.
What this also does, along with use-cases, is bring the world of encapsulation and abstraction into the requirements/analysis domain. We can more formally and precisely attempt to package or encapsulate requirements into logical entities more formally manage the dependencies between them.
Use-cases were a start at this, though it was rare to see the various use-case-relationships (extends, specializes, generalizes, uses, etc.) utilized all that much. Rick Lutowski’s little known FREEDOM development methodology also gets very formal about applying encapsulation to requirements – it might become a little more well known now that his book is out as of May 2005 Software Requirements: Encapsulation, Quality and Reuse
With DSLs and Intentional software combined with the ability to encapsulate requirements, we can then start talking about managing their dependencies much the same way we do for code/design today, which means we’ll be able to talk about things like Refactoring of requirements, and “Design Patterns” of Requirements Design/Engineering (and ultimately “requirements reuse”).
And if we ever get even close to that, much of what we call “traceability” today will become a thing of the past. The dependencies in the requirement will be precisely specified and apparent from how we express them in encapsulations and their formal relationships (just like C++/C#/Java code today specifies classes, interfaces, packages, and their interitance, composition, and uses relationships)
So, if it is true that:
- Computers and software are useful, primarily to the extent that they allow us to visualize & virtually manipulate the concepts we can previously only imagine within our minds.
- The evolution of programming languages has gone from trying to make it easier for the programmer to understand the machine’s representational language, to making it easier for the language to represent the thoughts of programmer’s and designer’s
- And with software becoming ever more pervasive and ubiquitous along with the increasing demand for regulatory traceability
Then perhaps Aspects and Sarbanes-Oxley combined with DSLs (and/or Intentional Software) and Test-Driven development will get us from Object-Oriented past Aspect-Oriented or Service-Oriented to arrive at Customer-Oriented Requirements Architecture of encapsulated requirements and the corresponding automated "acceptance" tests.
Then maybe the next big thing for software development may well be Customer-Oriented Requirements Architecture (CORA) and the evolution of expressive environments (I wont call them languages because I don’t think they’ll be strictly textual) that allow the business analyst and customer to express their needs and requirements in terms closer to their own thoughts and vocabulary, and to be able to directly transform that into encapsulated entities from which tests can be automatically generated and executed.
It would basically be creating a simulation environment with rapid feedback for exploring thoughts about what the software might do and analyzing the consequences. And just maybe it would enable the kind of Craftsmanship that Bob Martin's been doing for programming and design, only with the actual requirements!
But will we ever get there? Or will we be too busy chasing the next “Next Big Thing”? Or maybe I just need more sleep! What do you think? Is it too far fetched?
I just received a new O'Reilly&Associates book in the mail: The Art of Project Management, by Scott Berkun.
I didn't ask for it, O'Reilly just sent it to me. I perused it briefly. Judging from the table of contents, it looks promising and seems to focus on the reality of managing software projects. This is not a book about using MS-Project or PERT/GANNT charts or estimation. This book is about pragmatic project management realities rather than project management science or theory.
Looking through some of the text, I saw a few things I had some strong negative feelings about, and some other things that strongly resonated with me. So I'm not sure yet if I'll end up loving it or hating it, but I'll definitely have a lot to ponder and learn from it.
Scott also has a new blog that looks pretty good, and has some excellent essays on leadership and teamwork.
