Re: [Asunit-users] ASUnit 101: Where do I start?

[Luke B. <lb...@gm...>]

David,

Please keep asking questions. You are definitely not alone with these!

The question of where to start is actually the most important and of course
the most difficult to answer.

I have been sitting here for an hour writing paragraphs of prose and
deleting them over and over again trying to find something meaningful and
yet concise to say. Following is the best I can come up with and
unfortunately still isn't very concise.

Ali and I practice Extreme Programming <http://extremeprogramming.org/>.
This is a kind-of-scary, sort-of-strange, poorly-named, pretty-fad-sounding
development process that embarrasses me every time I hear it's name stated
out loud. I suspect the over-forty crowd responsible for the naming watched
too much TV and didn't realize that this term is considered ridiculous by
the rest of us. We usually prefer to lay claim to "Agile" development, but
the truth is, we work pretty hard at just about all of the details outlined
in XP.

Apologies aside, our experience demonstrated in no uncertain terms that Big
Design Up Front <http://c2.com/cgi/wiki?BigDesignUpFront> (or the waterfall
process) simply did not work for the kinds of projects that we worked on.
Ali and I spent a considerable amount of time looking into alternatives and
the one we settled on was XP. I'm not in much of a position to comment on
other approaches, and I'm not naive enough to think that there is only one
way to do something. I recognize that XP is not a "Silver
Bullet<http://c2.com/cgi/wiki?SilverBullet>",
and not appropriate for every project. For me - it has proven to be the best
way - that I have found - to get through a project from beginning to end and
wind up with something that is launch-worthy and a client that is relatively
excited about the value they received.

We were able to slowly move into XP one step at a time. We started with Unit
Testing <http://c2.com/cgi/wiki?UnitTest> and
NoteCards<http://c2.com/cgi/wiki?ManagingCards>,
moved into Iterative
Releases<http://extremeprogramming.org/rules/releaseoften.html>,
slid toward actual Test-Driven
Development<http://extremeprogramming.org/rules/testfirst.html>,
then began seeing value in Pair
Programming<http://extremeprogramming.org/rules/pair.html>.
Eventually, we had the privilege of working on a project with a firm that
already had XP development implemented, and this experience helped ground us
in the whole picture. I'm not sure how other people do it, but a kinder,
gentler approach worked well for us and helped us avoid becoming overwhelmed
and reactionary. I tend to suffer from a somewhat enlarged ego and probably
wouldn't have done well if someone had forced me to suddenly run a project
under the full range of XP practices<http://extremeprogramming.org/rules.html>
.

I wanted to go into all of this, because it colors my response to "where to
start"...

I happen to be a voracious reader and can't help but recommend a couple of
books that truly helped me answer this question for myself:

The book "Test Driven Development by
Example<http://www.amazon.com/Test-Driven-Development-Addison-Wesley-Signature/dp/0321146530/sr=8-1/qid=1164773372/ref=pd_bbs_sr_1/104-2146572-6188719?ie=UTF8&s=books>"
written by Kent Beck <http://c2.com/cgi/wiki?KentBeck> (the founder of XP)
is an excellent read and leaves a lot of the ancillary details of XP out,
but gives a strong introduction to how this one part works. I have read this
book over and over again and yet I know there is more information in there
waiting to be gleaned.

The other major book that impacted my development deeply was "Design
Patterns<http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612/ref=cm_lm_fullview_prod_1/104-2146572-6188719>"
by the Gang of Four. This book is so dense and academic that I couldn't
understand much more than the introduction the first 5 or 6 times I sat down
to read it. Ali and I finally broke down and created a Design Patterns Study
Group <http://www.industriallogic.com/papers/learning.html> in order to more
fully understand what these guys were trying to teach us. I don't think I
have ever learned so much so quickly, and can't recommend doing this
strongly enough.

To your specific question of whether you should dig deep and start writing
and testing features like a Polygon, or try to stay general and start with
higher-level features like "Create Room", I have to say that my answer is
sadly - both.

What we try to do when we start a project is to stand over a big table and
write down every feature that comes to mind - one feature to each note card.
Some of these note cards look like "user stories", some of them are simply
technical details or class names and some of them are essentially
components. The best term that I can come up with to describe them are
"modules". They're basically units of functionality.

When we're with the customer, we talk about "User Stories" or "Features"
like "Login" or "Display a list of thingys", or "edit a single thingy". But
when we're note carding, we usually talk about components and entities. We
don't try to note card every single class that we're going to build, but
usually wind up seeing classes emerge from this process. When we're done, we
have a pretty good idea of how the next iteration (week or two) is going to
look. If we want "Login" to work, we'll need a user name and password
TextInput control. We'll need some kind of submit button, failure feedback,
a panel of some sort, and hopefully some mechanism where we can store the
fact that someone has in fact logged in.

After note carding a user story like this, we usually sit down and start
writing components. What should a TextInput control look like to support
login? NOT how many features could I possibly ever need from a TextInput
control... This is a critical and major problem that Ali and I both have
difficulty balancing in every single project. It is so enticing to build the
world's best TextInput control - one that does everything you could ever
think of. But - for this iteration - we need Login, not a scalable, HTML
WYSIWYG text editor. It's like building a gesture of your application. You
start from the outside with general features, and you instantly drill deep
down into the details - but the crux is to not spend too much time worrying
over those details. TDD drives you back to the feature as soon as the detail
work is "good enough".

The really tough problem is trying to figure out how general a feature to
start with, so that you don't need 500 details in order to even begin.
That's where note cards come in really handy. They help you think about
things in a more modular way and take on a group of tasks that can be
accomplished in an afternoon or two. If you find yourself immersed in a task
that you thought would take an afternoon, and now it's 3 days later, at
least you know where you are for this iteration. If you find that happening
every time you sit down, you can start to finally address your enduring
optimism (I'm still working on that by the way). The idea is that you're
building and delivering useful functionality every day.

The real benefit to this type of process comes when the business people
crawl up to your desk in a panic because they need something different from
what they used to think they needed, and you're able to say - "That's not a
problem, I've only built the things that you've already seen, and I'm happy
to talk about this new feature that you're interested in, let's try to
figure out what you need right now."

Well, I think I've run off at the mouth long enough and hopefully some of
the links here will help to better explain what I'm rambling on and on
about...


Good Luck,


Luke
www.asunit.org