-
-
-
-
-
November 23, 2005
Is The Agile Development Community Barking At The Wrong "Big Dog On Campus"?
-
[UPDATE: OK, this graphic speaks VOLUMES:
So does this entry(where this graphic was pointed out... click the image to view the article that it came from) where you can also find the following two comments:
Scott Bellware(contains lots of references to other bloggers and what they had to say): "Rather than shape up Visual Studio to be amenable to Test-Driven Development, and in its ignorance of the nature of Test-Driven Development, Microsoft’s marketing people have simply tried to snow job the developer community into swallowing a wholly different definition of Test-Driven Development. And the very text outlining Microsoft’s understanding of Test-Driven Development betrays its almost complete ignorance of why Test-Driven Development is effective and why it is practiced in the way that it is. So, this is for the folks at MSDN. Listen up… you’ve already embarrassed yourself once, and you’ve embarrassed your insider and MVP communities by association this time as well..
Larkware: "Microsoft really needs to do a couple of things here. First, they need to yank the offending content from MSDN before any more people notice how stupid they look. Second, some of the more prominent Microsoft agile bloggers need to step up to the plate to explain what they're doing to evangelize within the company so that this sort of thing is less likely to happen again in the future. "
Hey Microsoft, forget what I said in this post... you need to fix this NOW! or your going to start losing more than just your most valuable employees, but also your Most Valuable Professionals as well. Don't fix this and, like this graphic, it will speak volumes as to just how valuable you regard the feedback of both your MVP's as well as without a doubt the most valuable resource you still have left: Your development community. Clock's a tickin']
Scott Bellware [MVP] : Microsoft Takes it on the Chin Over Test-Driven Development
On Test-Driven Development and Agile, Microsoft seems to have has lost its way, lost its courage, and lost its ability to innovate. The exodus of Microsoft’s brain trust is just one facet of the current sorry state of affairs of the occupation of its once fertile territories by an army of self-perpetuating, mindless, marketing zombies who are completely cut off from contemporary software tool requirements and are feeding product development with regurgitated goals from product usability tests of days gone by.
This is an interesting post, and I'm not going to contend the points that Scott has brought to the surface. Getting the entire definition, focus, and point of Test Driven Development this far off and out of focus is ridiculous. Microsoft needs to fix this and fix this fast!
But this brings up an opportunity to point out what to me as well as many others in whom I have the pleasure to work with seems so blatantly obvious:
What does Agile Development and OOP have to do with each other?
Answer:
NOTHING!
Agility and OOP are polar opposites. Why are we spending our time worrying about teaching newcomers to OOP how to properly build applications using Object-Oriented coding methodologies when, if we are doing what we SHOULD be doing, should instead focus our time on promoting programming paradigms that at there very core are agile.
First off, just to be sure we are all on the same page, according to Merriam-Webster agile means:
---
Main Entry: ag·ile
Pronunciation: 'a-j&l, -"jIl
Function: adjective
Etymology: Middle French, from Latin agilis, from agere to drive, act -- more at AGENT
1 : marked by ready ability to move with quick easy grace
2 : having a quick resourceful and adaptable character
- ag·ile·ly /-j&(l)-lE, -"jI(l)-lE/ adverb
---With this in mind, again I ask:
What does Agile Development and OOP have to do with each other?
Answer: See same question and answer from above.
OOP is, for the most part, a great way to make your code base extensible, while at the same time inheriting all of the capabilities of the underlying objectified hierarchy. This is both good and appealing.
But doesnt the very foundation in which OOP is built upon, often refered to as "The Three Pillar's of OOP" suggest everything BUT agility?
When I think of the ability to adapt, I don't think of of a Pillar, I think of something much smaller, much more basic, but ultimately the most important particle that in turn gives substance for a Pillar to be formed in the first place.
What is it that I think of:
An Atom. (can anybody see where I am going with this? :)
In both nature and in computing, Atom's are the foundation of true and pure agility. An Atom can be used to build anything and everything, which in my book is EXACTLY what agility is all about:
The ability to adapt.
Just and idea, but instead of focusing our time on pushing OOP in directions it has no ability to ADAPT to, why not instead focus on functional and dynamic programming languages that by their very nature are adaptive. Functional and dynamic languages can easily be used to teach Adaptive Development methodologies without making the students we are teaching desirous to rip out the very foundation of the hair follicles from the frustrations of attempting to build agile software with non-agile development methodologies and languages.
Now with this in mind lets now focus on what Microsoft it doing right in the field of Agile Development.
To do this lets quickly look at three individuals (there's quite a few more than this, my apologies to those of you who I didn't include, but for sake of brevity I am focusing on the core individuals behind the development and drive towards a more agile development platform):
Erik Meijer
Anders Hejlsberg
Don BoxWhat are these three folks working on in an attempt to bring a more agile development world to the CLI(.NET Platform)?
COmegaTo be fair, Linq, XLinq, and DLinq incorporate a lot of what COmega is all about, and to be honest I have no idea if COmega has now been swallowed up in these three technologies, or if it will continue on as the primary "research language", testing out new ideas and development methodologies as the years continue (anybody know the answer to this?)
But how does Scheme play into this? Read this post to gain a greater understanding, which ultimate leads to Don Box's recent post, "Scheme is Love" which was later followed up by "More on Scheme."
So whats my point?
Last year at Chris Sell's Applied XML Dev-Con after a brief "audience participation" poll regarding XQuery and XSLT 2.0, Chris Sell's said kind of outloud and kind of under his breath "It really doesn't matter as in ten years we're all going to be programming in Lisp anyway" which, for those who were unfamiliar with Lisp would have taken it as a joke and just as quickly forgot he even said it.
But I didn't forget. Nor did I take it as a joke. Chris Sell's (for those of you who don't know(BTW... If you don't know who Chris is you really ought to be ashamed of yourself... REPENT!)) is someone who is VERY close to the development heart of Microsoft. Do you think he might know something that we don't(besides the obvious given his "Legends of Software Development" status)? Yeah, I bet he knows A LOT of things we don't know. Do you think that Don and Chris might be slowly but surely prepping the development community for a time when, as Chris predicted, we will all be developing in Lisp or derivatives like Scheme?
Now, lets take it back a few notches and recognize that as great as Lisp and Scheme are, not everyone is LITERALLY going to be programming in these languages. But I can guarantee you that with the direction that Erik Meijer and Anders Hejlsberg are taking the C# programming language, encapsulating much of what the Haskell (Functional) programming language is all about, there will be very little difference between Lisp, Scheme, Haskell, and C# in or about the same 10 year time frame that Chris predicted.
I've mentioned this before, but I will quickly point it out for those of you who might be unaware. Since its very first release the .NET platform has shipped with 'clisp' as a demo/sample for tool developers. Depending on whether you chose the default installation location for the SDK this can usually be found at:
C:\Program Files\Microsoft.NET\SDK\v1.1\Tool Developers Guide\Samples\clisp
As I stated in the linked post from above, do you think thats an accident?
No, it's not.
Do you think its just possible that Microsoft is preparing for a development future with Agile Development at the core of its focus?
Yeah, I think they are.
Like I state in the title:
Is The Agile Development Community Barking At The Wrong "Big Dog On Campus"?
My own answer to this is a most resounding YES, they are!
What "Big Dog On Campus" should they be barking at?
If they are making OOP the heart of their Agile Development focus, the Big Dog they should be barking at is themselves.
- Posted by m.david : November 23, 2005 03:41 AM GMT
Trackback Pings
TrackBack URL for this entry:
http://www.xsltblog.com/xslt-blog-mt/mt-tb.cgi/1149Listed below are links to weblogs that reference Is The Agile Development Community Barking At The Wrong "Big Dog On Campus"?:
» A conondrum about agile development and Visual Studio from Visual Studio Blog
[Read More]Tracked on November 30, 2005 11:52 PM
» Caribbean Vacation from Caribbean Vacation
Caribbean Vacation [Read More]Tracked on March 29, 2006 07:13 PM
» Memory Foam Mattress from Memory Foam Mattress
Memory Foam Mattress [Read More]Tracked on March 29, 2006 11:14 PM
» Disney World Vacation from Disney World Vacation
Disney World Vacation [Read More]Tracked on March 30, 2006 06:57 PM
» good quotes from good quotes
good quotes [Read More]Tracked on April 2, 2006 10:54 PM
» carinsurancequotes from carinsurancequotes
carinsurancequotes [Read More]Tracked on April 2, 2006 10:54 PM
Comments
Post a comment
-
-
-
-
-
Agility and OOP are polar opposites.
What a lot of nonsense.
Agility and OOP are orthogonal.
I call comment foul.
You can’t just make a statement based on opinion with no substance to back up your point. Come on now… A statement alone proves nothing more than the simple fact that you have an opinion.
Come clean. How are Agility and OOP orthogonal?
Now with this said, I will admit that I have a tendency to over-emphasize one point to drive home another. But whether or not OOP CAN BE agile is not whats important. A lot of things CAN BE other things… but that doesn’t mean the transition is an easy one. OOP can be agile, sure. But by nature? Not in a million fucking years.
The most important focal point is that agile development languages are built upon agile foundations:
Built upon a foundation of mathematics and a focus towards side-effect free programming — now thats agility: Come in, do your job, get out, and don’t mess with anybody else’s things. How can you be more adaptive to any given situation when by the very nature of the language you don’t have to worry about covering up your tracks when you leave? There are no tracks. Internally there are, but externally… side-effect free. Get-in, Get-out, Get-on with it.
Obviously dynamic languages have a tendency to extend from an OOP backbone, or at least contain some characteristics that bring Object-Orientation into play — And thats not a bad thing. OOP is not ALL bad… Its just not easily adaptible to any given situation without extensive testing and reworking of the code-base(In fact code refactoring is an EXTREMELY popular topic at the moment. Why? Because we have this HUGE blob of OOP code that ALL needs to be refactored such that it can be more agile. Do you see a pattern here?
Now obviously OOP is not the death of the world. But traditional OOP languages are not dynamic languages. They are type-heavy and as such extremely error-prone which in and of itself suggests that agility is not, by nature, a piece of what OOP is all about.
I’m willing to listen to your counter point. But it needs to be just a tad stronger than “What a lot of nonsense. Agility and OOP are orthogonal.” as, again, you’ve done nothing more than expressed your opinion and assumed that this alone wins the argument.
I’m man enough to state I’m wrong(or at least leave room for the fact that my point is not as strong as I think it is) if your man enough to actually admit that your point, in its current form, is pointless(and then come up with a reasonable follow-up that causes me to think “Hmmm… He’s got a point, I hadn’t thought of it that way”.)
If OOP isn’t agile, what is — procedural programming? Seat-of-the-pants hacking? Punch cards? Don’t mix speed with agility. Building up something fast and changing it fast doesn’t necessarily mean it’s agile.
Heck, just about any codebase is agile at first based solely on it’s size. But as the codebase grows, OOP and a good IDE will help keep you agile. Have you ever used a good OOP IDE with refactoring tools?
OK, I was trying to needle you a bit. I was also about to go to bed.
In your follow up, you’ve largely made my point for me.
Your opening statement was that agility and OOP were polar opposites - north and south, up and down, hot and cold.
You’ve moderated not to OOP can be agile, which is fine with me. I take your point that some languages are more friendly, can I put it like that, to agile development. However, programming in Scheme, say, doesn’t automatically mean that someone is “doing” agile development. Do I because agile when I put down my C++ compiler and pick up Saxon8? When you move from XQuery to Java does the way you work suddenly change?
Agile development is about process, in the widest sense. It’s about your mindset. As a programmer, every decision you take is a design decision and affects, in some way, the finished piece of work. You’re an agile programmer, not a programmer who uses an agile language. Tools and languages can help you, but they can’t make you.
If the trend you detect toward functional languages in C# plays out as you suspect, then perhaps we will have a big pile of better tools. And that’ll be great, and hopefully we’ll be able to more, more quickly. It won’t automatically makes every programmer an agile programmer, though.
As an aside, I’m not really qualified to comment on traditional OOP languages are not dynamic languages, but I suspect there’s an army of Smalltalkers who’d disagree :)
Jez,
Great follow-up! I plan to bring it to the surface in a new post as you made a couple of important points that I think should be brought to broader attention.
Thanks for taking the time to follow-up!
Joe,
That statement alone suggests that your standard, run-of-the-mill, classic, pick your cliche’ term refering to the base of C++, Java, C#, etc… (which, when I say OOP, I really should be more specific, something I plan to bring out in my follow-up post) are not well suited, by nature, for agile development.
I think you’ll find that more advanced TDD practice achieves the atomic values that you expressed an appreciation for. To wit, TDD in an OO language is all about using OO in a more atomic fashion and driving more atomic and recomposable designs.
Most of TDD design work drives at the heart of the reduction of cyclomatic complexity and the reduction of execution path depth as well as the introduction of a greater degree of loose coupling as supported by interaction testing through mocks and dependency injection.
To refute Agile’s importance to OO, you’d have to refute TDD’s place in Agile, and quite possibly Martin Fowler’s book on refactoring as well as Joshua Kerievsky’s Refactoring to Patterns book as key Agile texts.
I would personally agree with you that Agile isn’t only applicable to OO, but because OO is prevalent right now in the Agile community, much of the tactical Agile implementation practices have been built to support OO.
It will be interesting to see what comes of the forays into functional programming at Microsoft. And yes, LINQ and C# 3.0 subsumes C-Omega.
Hey Scott,
Thanks for taking the time to provide your valuable insite. One of the reasons I took such a hard stance “against” OOP was to try and draw comments from the community that otherwise wouldn’t have commented. It seems that between Jez and yourself some insite was definitely added to the conversation that may not have had I taken a lesser stance against OOP being agile, but I will leave that for you to decide :)
I had wanted to follow-up on Saturday with a new post to help clarify all of this and to bring the comments Jez added to his earlier post to the surface. I got a bit sidetracked but am glad I did as your additonal comments add quite a bit of additional value, something I will definitely bring to the surface in my follow-up post.
Cheers :)