Agile Otter Blog

 A big thread erupted, all full of misunderstandings and miscommunications, about the idea of "private" methods.  It all started quite innocently (I maintain) when someone asked how we felt about testing private methods. Some people jumped in with "Absolutely Not! Never! That's wrong! Test via public interfaces." I thought a little longer, and said "I'm not sure" and then later "I'm not sure that 'private' is even needed." This is where the problems started, and maybe here I can clarify what I meant by it all.  People assume (and insist) that I could only possibly mean that they should substitute 'public' for all protected and private members, polluting the interface, and inviting the violation of a class' internal state.  That was never my intention and still isn't. Still, this is what people insist that I must have meant from the start. I suppose this is because that's what they imagined me to mean and it...

 I've noticed that for several years now, one of the most frequently asked questions in agile forums deals with the splitting of stories.  We simply can't create a feature, epic, or improvement in a single gesture. If we are going to make progress, we have to start somewhere and build in small pieces. One way or another, whether we release after each piece or not, we have to make progress in bits and pieces.  In the bad old waterfall days, the analysts and designers would come up with a system with functional decomposition. It would essentially describe a tree with upper-level modules calling lower-level modules all the way down to individual functions. After the designers have done a top-down design, the developers would start building the system starting from the bottom-up. They would build the pieces and the higher-level pieces that use those pieces until they had components, sub-assemblies, subsystems, and eventually the entire product.  This "top-down design, bo...