[cse491] [marick at exampler.com: Re: [agile-testing] How to design stories to cover framework and infrastructure tasks]

[C. Titus Brown]

A good e-mail on software development strategies.  You, ahem, might note
some similarities here with aspects of the progression of homeworks in
cse 491...

--titus

----- Forwarded message from Brian Marick <marick at exampler.com> -----

To: agile-testing at yahoogroups.com
From: Brian Marick <marick at exampler.com>

On Oct 23, 2008, at 3:44 AM, adam_peter.knight wrote:
> This is because much of our development work involves first developing
> a framework for the new functionality (e.g. an interface to a new
> back-end data store) which has no functionality to expose to the test
> team, then adding in all of the functionality covered by our 'stories'
> at the end.
>
This is the way we were all taught to develop: take time building the  
infrastructure, then giddily (because it's so easy) slap features on  
top of it. Many Agile proponents prefer a different way, because it's  
less prone to waste: develop a "slice" through the application that  
includes both something of value to the end user and a bit of the  
infrastructure. Then do the next slice, taking care to generalize when  
the code for the current slice overlaps with the code for a previous  
slice.  Continue in this way until you generalize your way to an  
infrastructure that - because of the continuous rework - looks as if  
it were superbly designed to match the system's requirements. (No  
wasted code, just the right abstractions, etc.)

This is a hard shift for programmers to make, in two ways:

1. ... believing it's possible at all.
2. ... developing the skills to do it.

1. Seeing is believing, but the problem is that you only really get to  
see it when you're working with people who do it. You can't look at  
the systems they build and say, "Yes, I see what they did!", because  
the systems just look well-designed. The only book I know of that  
shows how it works is Jeffries' _Extreme Programming Adventures in C#_  
<http://www.amazon.com/dp/0735619492> (pay special attention to how  
undo comes in at the end - clever). But that book is 560 pages long,  
and it shows the building of a rather small app. You need that level  
of detail to show that it's not a parlor trick, but that level of  
detail is too wordy for print.

About all I can say when I'm coaching teams is "I've seen it. Let's  
assume it's possible, give it a serious try, and then decide."

2. Probably the key skill is refactoring. Wake's _Refactoring  
Workbook_ <http://www.amazon.com/dp/0321109295> is good. Kerievsky's  
_Refactoring to Patterns_ <http://www.amazon.com/dp/0321213351> gets a  
little more into how you can use refactoring to build structure that  
looks like it was well-designed all along.

But those books don't really teach the key part of the key skill,  
which is recognizing when two special cases need to be generalized  
into one (when a refactoring is a good idea). Here's how I think you  
develop that skill: you start out not recognizing it. You end up with  
N special cases and the generality is lost in the details. The problem  
gets bad enough that even you, with not-yet-sharpened senses, feel it.  
Now you have to have the discipline to take the time to fix it. Your  
senses are now more sharp. Repeat until code starts making you  
uncomfortable earlier and you have the discipline to act on your  
discomfort sooner.


Making the switch - even trying it out - definitely pushes people out  
of their comfort zone. Some people like that; a lot of people don't.  
It also tends to fire off primate status-protecting behavior. The  
highest-status people are likely so because they're the best at big up- 
front design. They have to reshape old skills and habits of thought,  
which I think is harder than just learning new ones.

-----
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.exampler.com/blog, www.twitter.com/marick


----- End forwarded message -----

-- 
C. Titus Brown, ctb at msu.edu