November 30, 2005
Agile and OOP
I found this rambling, yet thought-provoking post (by David Peterson via Don Box) that starts out as yet another condemnation of the Microsoft TDD article (its been taken down BTW) but quickly morphs into a two pronged article; a prediction that the future of Agile at MS is lisp, and a short observation that the Agile community is wrongly overly focused on OOP.
I think David is right -- but for the wrong reason. I have a lot of thoughts on this topic (namely the future, past and point of the Agile movement) and while I think I agree that there are many who profess Agile as their approach who have elevated OOP to a divine status, focusing on history for a second, I think Agile is inextricably linked to OOP in that the practices and philosophical approaches grouped under that heading are impossible to understand without considering the context of their origin.
Agile as a movement grew out of the confluence of the buzz around "lightweight methodologies" most notably (from my POV) Extreme Programming. This community in turn featured common roots in the patterns community, which in turn stemmed from the OO community (in particular, the SmallTalk community). A quick look at the early book lists of the bigger Agile authors shows a progression from SmallTalk to OOP to Patterns to Agile.
IOW, the early XP/lightweight movement is best understood as a reaction/refinement of the OOP paradigm. David is correct in noting that OOP centers on static concepts (and Don's reference to Alan Kay's lament that SmallTalk should have been message-based not object-based supports this), but Agile methods aren't (or weren't 't before Agile became the Next Big Thing) a celebration of that fact, but rather a recogniztion that the benefits that OO provides to large application structuring, comes with the cost of new pitfalls for changing that structure. Test Driven Development -- as the central XP (and by extension Agile) coding practice -- is a programming strategy *directly* aimed at addressing this OO pitfall.
IOW, the Agile movement arose as a response to the the shortcomings of OO and its attendant methodologies. Its early authors were attempting to publish patterns and ideas that characterize what good OO programmers were/are doing to address its limitations and exploit its strengths.
This leads me to the other part of David's comment: that lisp/functional/dynamic typing paradigms are more "Agile" than OOP. Again, I think David is right, but for the wrong reasons. Those tools are not inherently more (or less) agile than OOP, Structured Programming, the use of gotos or any programming technique. They are however -- in the hands of someone who values it -- potent tools to effect agility. I don't think its a cooincidence that the C2 Wiki (a well-spring of both the Patterns and Agile diasporas) also has a large body of lisp/functional pages, or that Ruby, Python and other dynamic languages are very popular in the Agile community, rather its an indication that Agile is (or at least was) about something other than OO.
I.e. those who "get" what Agile is about, see the benefits of these tools too, and *do* see OO as a means to an end, namely: building software that enables ongoing change at steady cost (again an XP premise that got lost in the "Agilification" of the movement).
So, where does this leave us? Well, I think its clear that I sensed in both David and Don's posts an undertone of "Those Agile guys are too focused on OOP" and that I don't agree with this characterization of Agile (at least as conceived by those who coined the term). Perhaps the Agile of today -- represented by things like the Microsoft TDD article, the attempts by many consulting firms to make Agile a methodology (instead of set of principles like it used to be), and the increasing adoption of "Agile" by big IT -- deserves this criticism, but the Agile movement I remember held their observation as a premise.
*That* agile movement seems to already be dying out, but its echoes might still carry the message (if not recognize the messengers). And hey, if the result is that tools like lisp, TDD, and dynamism become more mainstream, then that ringing of the bell known as "Agile" did more than most such efforts.
As someone who was fortunate to hear that bell ringing fairly early (and spent a good bit of the last 5 years trying to help others hear it), I think I can live with that.
Posted by wcaputo at November 30, 2005 01:18 PMBill,
I just weighed in the other way by saying that a good OO skillset makes for a better TDD experience at http://codebetter.com/blogs/jeremy.miller/archive/2005/11/29/135212.aspx.
I know I was being a bit limited in my thinking because I live strictly in a static typed, OO world now. I can understand the advantages of the dynamic typed languages, but can you talk a bit more about how or where a functional language approach is advantageous?
Posted by: Jeremy Miller at November 30, 2005 02:57 PMHi Jeremy,
I don't necessarily think our two stances are opposing -- i.e. I agree that a good OO skillset makes for a better TDD experience. Rather, I am of the opinion, that OO + TDD is better than OO alone (hence the observation that TDD is best understood as a technique to use OO while avoiding its pitfalls).
>can you talk a bit more about how or where
>a functional language approach is advantageous
Well, perhaps I'll try to put into words what I like about FP someday -- and certainly there are many others who have written about FP's strengths (e.g. http://en.wikipedia.org/wiki/Functional_programmingfor a good overview) -- but I don't think I am the best person to extol its virtues (as I merely experiment with FP languages and constructs from time to time).
So, for now, I'll just say that I have recommended people learn FP techniques because problems can look different from different points of view. I.e. I find some design problems seem much smaller when viewed from an OO perspective, and others from an FP perspective.
Also, I think certain design goals and idioms of FP languages (lack of side-effcts, first-order functions, the blurring of lists and functions leap to mind) lend themselves to refactoring, and simple design -- or then again maybe I just like having multiple tricks up my sleeve. :-)
Posted by: Bill at November 30, 2005 04:09 PMBad Links (January 19, 2006)
Visual Studio Team System Jumpstart (January 18, 2006)
Aligining Value (January 17, 2006)
Lisp Again (January 16, 2006)
Getting It Right (January 13, 2006)
Efficiency vs Productivity (January 12, 2006)
Stubbornness (January 10, 2006)
Writing To Annoy Yourself (January 9, 2006)
Due Process In The Workplace (January 5, 2006)
(All Entries...)