Jay Kimble

You probably think that GrDD AKA "Git 'R Done" development is a joke. And in some respects it is, but the concepts behind it are not. I have been talking to some friends and I think I have a pretty good idea of what we are talking about. Now mind you I’m not a methodology guy. I want to stress that. I’m just trying to get this out of my system.

Before I proceed, I know there are some "agilists" out there who are subscribed because they can’t wait to pounce on an idea that is counter to their ideas (and since TheRuntime.com seems to be the center for "Alt ALT.NET". Please resist the urge. I know it’s hard to believe that there are a not a few of us who are skeptics, but there are (and some way smarter than me). If anything I’m trying to present an alternative idea that might lead people towards your thinking and maybe make some of it more palatable for other skeptics.

Just to make myself clear to y’all, I typically tolerate all kinds of dialog and even invite it... but if you are planning on flaming all I can say is do it elsewhere... if you have something you think adds to my dialog then please feel free... If you aren’t "agile" then you are really invited to take part... I’ve had some ideas since my CodeBetter days that got shouted down back there, and I think it has merit for those practicing more of a GrDD <smile /> practice.

GrDD refactored = ClDD

ClDD is really a better acronym for what I have been touting. Client Driven Development or simple ClDD (could be pronounced "Cloudy" which is how it often starts). The idea here is focusing in on the client’s needs and working hard toward achieving that goal with minimal additional distractions. That may mean developing a web site with MS Access at the core of the site (I’ve done it/am doing it again)... It doesn’t mean that you don’t try to talk the client out of it... just that you are doing what the client ultimately wants done (and you aren’t building extra stuff beyond what is needed). I know that ruffles the feathers of some agilists, but the idea is simply put that you have to understand what the client needs and you make tradeoffs to meet the deadline. (BTW, this is what makes Billy Hollis an honorary GrDD prophet... see Jacob’s post back here... he gets it IMNHO). FWIW, This is really a re-hash of the RAD methodology from the turn of the millenium (or thereabout).

What about Quality?

[This is one I’m poking around with right now... it’s the idea from way back in the CodeBetter days. I’ll forego using the agile name, but it will be apparent what I’m re-purposing.]  One of the things I really want to do more of is POUT (Plain Old Unit Testing). My problem could be resolved by answering the question "What should I test?" Some would say "Everything!" But I think there is a diminishing set of returns. Testing an empty constructor or testing a simple property seems like waste of time to me.

Enter SpDD

The idea that I have come up with involves recording the specs or rules of a system... call them
"stories" or use cases or simply business rules and build tests around as many of these as is possible (as long as you have the time to do so). Now this doesn’t produce 100% code coverage nor does it always produce 100% testable code (which to some is important)... it might represent Test First written code or it might represent Test Last written code... what I want to be able to do is determine that my code is living up to the spec, and have a set of regression tests to prove this to myself (I’m not sure what I think of the testing tools in this arena at this point... verdict is still out for me).

BTW, SpDD is pronounced "Spee-Dee."

[Alright Rob, Jacob... what do you think? Poke holes in it as it’s just an idea at this point... not something I’m doing, yet]