Transitioning From Matt to Steve

Animation might take a few seconds to load.

Link Roundup

• Quality-Speed Tradeoff — You’re kidding yourself: Ron Jeffries on the quality vs. speed argument
• The Pomodoro Technique
• Agile in a Flash: Agile Reference in the form of flashcards, with explanations and comments
• Clean Code Grades: Clean Code Developer Grade system is a graduated collection of principles, rules and practices which a software professional can use to produce "cleaner" code. It is based partly on the contents of the book Clean Code by Robert C. Martin.
• Kanban, Flow and Cadence
• Burndowns and Flareups in Agile Design
  

Link roundup

• Announcing Trinidad: In-process test runner for FitNesse wiki pages
• Rake Stats: How to log Rails 'rake stats' command output over time and add extensions to it into CruiseControl
  
• Clarke Ching's "Rocks into Gold": a biztech parable for software developers who want to Survive - and then Thrive – through the Credit Crunch.
  
• Hiring Software Developers: The Agile Aptitude Test
• Agile Payback: The adoption of agile programming methods has proved one of the most effective and popular strategies of the past year
• Anthrax and Standups: Slightly old but relevant post from Brian Marick on story-based standups
• Playgrounds & a Thought on Testing

Asynchrony honorably mentioned as Great Place to Work

St. Louis Magazine has an article that notes something that those of us who work at Asychrony already knew: Asynchrony is a great place to work. We received an honorable mention in the publication's January issue highlighting the area's Great Places to Work. Sure, our "Employees play Halo on two 40-inch TVs," but we're got several of the other perks that other companies have, and some that they don't. Like flexible childcare, pet-friendliness, FFASHH, and, of course, the free lunches. That chinese food in the first-floor refrigerator was for everyone, right?

Defense Systems highlights Asynchrony's SOA work at USTRANSCOM

Defense Systems magazine had a good article about Asynchrony's SOA work at USTRANSCOM. Here's a snippet with a quote from Steve:

The prescriptive architecture is due for delivery in the fall of 2009, said Steve Elfanbaum, Asynchrony’s president. But it won’t take the full length of the contract for new Web-based capabilities to come out, or for the transition architecture to be fully defined.

“People (in USTRANSCOM) are already clamoring for new services and want to use what we have now,” he said. “So as things come out of this process, as the various templates and standards fall out, we’ll start to use those as soon as we can.”

That's textbook agile philosophy, providing value as soon as possible. Who says government contracts can't be done agilely (or at least more agilely)?

Link roundup

• Retrospective facilitation -- John Wilger
• Kanban introduction -- Eric Landes (podcast)
• "How we develop software at Socialtext" (video)
• Getting Real About Agile Design
• Working through Screens (ebook on user interaction)
• Agile Philanthropy
  

Environmentally friendly, reusable story cards

Besides conversation, nothing beats the tactile, low-fi index card for communicating story information. And for environmentally friendly story cards, nothing beats this invention (well, we're not really sure it's an invention in the strictest sense) by Asynchronite Dan King: The Lamindex Story Card. As the name implies, it's a laminated index card that can be used and reused for countless stories and countless projects.




They're relatively cheap to make (just go to Kinko's if you don't have your own laminator or teacher friend), though Dan advises getting the "special kind" of laminate for easy cleaning.

The Toilet Paper (Installment 25): Single-Responsibility Principle (SOLID, part 2)

A class should have exactly one reason to change

The Single-Responsibility Principle (SRP) helps you create classes that are resilient in the face of requirements changes. Put more simply, the SRP guides you in creating individual classes that are highly focused on a single implementation concept, so that each individual class is less likely to be affected by each requirements change. Each class is very limited in what it knows how to do and what it knows about, so an individual requirement change is less likely to affect that class. As a result, classes that change less often and accumulate less code are less likely to accumulate bugs as well. They can be tested thoroughly and raise the overall quality of your application.

Let's look at an example. Suppose we have a Product class that models information and behavior associated with some widget we're selling. It might look something like this:

public class Product {
 public String Name { get; private set; }
 public String Sku { get; private set; }
 public Money ShippingCharges(Destination dest) {…}
 public Money CalculateDiscount(Contract contract){…}
}

Assuming that the implementations of how to calculate shipping charges and discounts are inside both of those methods, this class clearly has multiple responsibilities – three, in fact. First, it models a product, which has properties, shipping charges and discounts. But this class also charges shipping and calculates discounts. This may not seem that important, but it means that this particular class is harder to understand and changes more often than would otherwise be necessary. The biggest shortcoming, however, is that the logic for these calculations is hidden inside the Product class, making these non-trivial bits of code harder to find and harder to test independently.

To solve this, refactor this class so that it delegates the responsibility of how doing the calculations are done to two other, more specialized classes, such as ShippingChargeCalculator and PriceDiscounter. That would leave you with three classes, each of which has one reason to change, decreasing the complexity of the system and increasing maintainability, flexibility, and testability.

You can find much more on the SRP on Google. Try searching for "ActiveRecord Single-Responsibility Principle" for hours of enjoyment!

Link roundup

Product Ownership

• Becoming a Great Scrum Product Owner (eBook)

Testing

• Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing (book)
• JNarrate: Tool that allows you to write acceptance tests with code using a fluent API
• Craft of Software blog: Matt Heusser's new blog for testers
• Software Craftsmanship: Google group
  

Best Practices

• Linda Rising podcast on Retrospectives
• Kanban and Retrospectives
  

Agile

• “Seven Years Later: What the Agile Manifesto Left Out” presentation by Brian Marick at Agile Development Practices

Asynchrony Principals Aging Like Fine Wine

First image is from around the time of our 1999 start-up. The second is the 2009 version.

Using JavaScript to check if an image is loaded

I had an interesting problem the other day. The project I'm on is a real estate listing website. It's very Web 2.0, using AJAX calls to provide the user with a rich experience. We use the Prototype Library for all our AJAX calls and DOM manipulation.

So the problem came about with the enlarged photo browsing portion of the site. Each listing has at least one photo associated with it. If the listing has more than one photo, then the user can browse through the photo with simple NEXT & PREVIOUS links. Under the scene, when the user presses one of the links we make a simple AJAX call to load the next image and swap out the div the image belongs to.

The problem came about when we were testing in IE. The footer would sometimes appear right over the image. IE wasn't recognizing that one of the div elements was supposed to grow to match the size of the image inside it. The simple fix was to set the Height of the problem div to the Height of the child div that is holding the image. To do this all I had to do was call this method in the "onComplete" section of my AJAX call.

This worked in most cases but there were still times when the footer tag would appear in the middle. With the help of firebug lite, and Nate Young, I realized that my method was being called before the image was finished loading. The solution was loading the image and checking the "complete" on the image object. If the image isn't finished, just make a simple recursive call.

function moveFooter(){
  if ($('enlargedImageDiv') && $('imageContainer')){
    var image = 
      new Image($('imageContainer').siblings[0]);
    if(image.complete) {
      Element.setStyle($('enlargedImageDiv'), {
        height:$('imageContainer').getHeight()+41
      });
    }else{
      moveFooter()
    } 
 }
}

Is estimating a bad practice?

According to Naresh Jain, writing in response to a LinkedIn Agile Alliance discussion, it is:

Estimates are a hang-over from the waterfall world. For the last 6 years, I’ve been very happy and successful building products and delivering projects without all the estimation related ab-ra-ca-dab-ra. No more real-time, ideal-time, story point, function point; non-sense. I’ve realized the key is to focus on the flow of the deliverable and not whether your are delivering according to the estimates.

He goes on to make a pretty compelling case for the abolition of estimates (he provides some useful back-and-forth with his detractors in the comments, too). Since some of our teams have started down the kan-ban path, it would be interesting to know how much of our experience squares with Jain's claims.

Jain also references Joshua Kerievsky's Agile 2008 presentation on the same topic.

An acceptance-test development approach by any other name would smell as sweet

Gaffo forwarded this snippet from the RSpec users list in response to the question "Is there a difference between Behaviour-Driven-Development and Story-Driven-Development?":

Excellent question,

I think the more common term is STDD (Story Test Driven Development). There is ATDD (Acceptance-Test Driven Development too) ;-)

They are all variations on the same theme and only marginally different IMO. The biggest difference seems to be that different people and groups promote them and talk about them in slightly different ways, and emphasise the various techniques differently. My personal take is that BDD *is* ATDD/STDD, but with an additional emphasis on Business value and getting the words right. I'm not sure how ATDD and STDD are different.

Maybe the best place to get a good balance of viewpoints on this topic is in a tool-agnostic forum - maybe this one:
http://groups.google.com/group/behaviordrivendevelopment (I don't know of any STDD or ATDD forums).

There are good articles about ATDD and STDD here:

• http://testobsessed.com/wordpress/wp-content/uploads/2008/12/example.pdf
  
• http://industriallogic.com/papers/storytest.pdf
  
• http://www.nxtbook.com/nxtbooks/sqe/bettersoftware0908/ (page 24-29)
  

Sounds about right to me. The most important thing is what you actually are doing, not what you call it (though that's important, too). Around here, I use ATDD, since I think it best describes the practice and people are already familiar with what acceptance tests are. And STDD sounds too much like STD, which doesn't exactly foster a mindset of willing acceptance.

DynamicPageList installed on wiki

We've installed the DynamicPageList extension on the company wiki. The extension is:

a universal reporting tool for MediaWikis, listing category members and intersections with various formats and details ... Typically the selection of pages to be shown will be based on one or more categories. But there are many other choices for selection criteria, like e.g. author, namespace, date, name pattern, usage of templates or references to other articles.

This allows us to dynamically generate lists, such as most-popular pages, recently-edited pages and pages edited by certain authors. I initially found the extension in my quest for a way to organize our retrospectives and let interested people see at a glance, say, the last five retrospectives for a particular project.

Path to Programming

Over the weekend, I read this article along with discussions about it on Reddit, Hacker News and a related discussion on what it takes to become a talented programmer on O'Reilly's blog.

It got me thinking about my own path to programming:

0. My first CS course ever was in high school. I did ok, middling at best. It was taught in C++. The Borland compiler we used marked syntax errors the line after they occurred, which caused me a lot of headaches. The final assignment, biggest grade of the class, was to create a game, any game. The brightest kid in the class wrote a poker game using ascii art to actually draw the cards. I thought I was at least as smart as him, so I made a poker game as well, but halfway through writing it, realized I couldn't figure out how to determine what hand a player was dealt, so I did what any industrious 10th grader would do. I rigged the game. Every hand dealt to the player was all hearts and it always printed out:
You have a flush!
I did not go to college hoping to earn a degree in Computer Science.

1. As a biology undergrad, though, I did have to take an introductory computer science class. It was in C. What I had learned in High School was sufficient enough that I slept through every class and aced every homework assignment. In retrospect, it probably set unrealistic expectations for courses to come.

2. The summer after my freshman year, during a summer internship in a bio lab, I found myself spending every waking moment in the library reading technical computer books. The campus had a network of vending machines with student id card readers attached that would, when swiped, bill your student account. I noticed that they left the phone line that connected them to the campus network exposed, and was convinced that if only I knew a little bit more about TCP/IP I could send the machine someone else's student id number and get free Snickers for the duration of my internship. I never succeeded, but at the end of the internship nothing I had still to study in biology seemed as appealing as figuring out the answers to all of the questions my reading had stirred up. That fall semester, I enrolled in CS.

3. My Operating Systems class made the most sense of any class I took as a CS major. Each assignment covered a separate system call and that system call would be printed at the top of the assignment handout, verbatim from the man page. Combined with a good specification of exactly what our program was supposed to output and how we were to deal with error conditions meant that in order to turn in a working program, all I had to do was read the assignment and the man pages enough times to put statements together in the right order. I won't even pretend that I understood how my assignment to write a primitive shell worked, I had just read the execv man page enough times that by sheer combinatorial probability it had to work.

4. Many people in the comments on the article and in the forums noted that while initially programming may not make sense to a lot of people, sometimes, out of the blue it will "click" for a student. I actually had an "Aha" moment during a final as time was being called. The last question on the last test of Computer Architecture and Assembly Programming, asked what instruction was equivalent to popping the top of the call stack. I will never accuse anyone of having a dumb, blank stare again as my slack expression betrayed that fact that somewhere inside my cranium, hexadecimal notation, the von Neumann architecture, Intel memory addressing and the 8086 instruction set were coalescing into actual understanding. Even more amazing was that my brain took those tiny electrical impulses and mechanically translated them into little carbon-graphite scratches representing a correct answer. I remember leaving the test, talking to a fellow student for whom that question had not ignited any cranial conflagrations and despite the urge to prove my superiority, I withheld my hard won answer from him, realizing that sometimes the possession of knowledge comes secondary to its acquisition.

The common thread of my education, though, I think, was that I never really questioned why things worked the way they did or worried that I didn't have as much control over them as I wanted. In High School I never questioned why I wrote int main(char* argc, char** argv) even though I had no idea what those two arguments were, nor ever used them in my programs, nor (until my infamous OS shell assignment) questioned how those values would ever be populated.

More theologically inclined students wanted to know why the for loop looked the way it did or pouted when they knew that they wanted their code to be compiled, but could not properly translate that knowledge into a series of dashes and letters that gcc would understand.

I never questioned the magical gcc incantation that was usually provided to me. Cryptic error messages, I felt deep down, were my fault. It is this same suspicion that persists in me even today, keeping me from writing copious amounts of bug reports for the software I use.

I did know I hated C++ and liked C, though I had seen the phrase C/C++ bandied about so often that I thought that they were merely two different styles of writing the same language, sort of like the distinction between which style of brace indentation you chose.

And once, while practicing for a programming contest, competing against my advising professor, he blew my mind by writing some 4 or 5 line string function in C that I had written with 1 in Java, and like the master to the grasshopper, asked my how mine could still be slower.

There were more classes, but I was a college student and blissfully unaware of the totality with which my life after college would be consumed with, well, life after college and I tried not to let too many more painful epiphanies erupt inside my skull. Departed from college for a handful of years, I now work with very smart people that force these epiphanies on me cruelly and with great relish. Its probably why our company has been as successful as it has been and makes me wonder just what their path to programming was.

So, to end of this heinously long post, I completely agree with whoever it was that said "A little bit of knowledge is a dangerous thing".

Link Roundup

Methodology:

• Scrum-ban

User experience:

• Five-second test
• Agile Usability, George Dinwiddie’s blog
• Getting Agile with user-centered design
  

Programming:

• Reusability vs. Usability: Where to Draw the Line?
• Will the holidays create discipline debt?
  

Testing:

• Simple strategies to keep quality visible

Conferences:

• CITCON 2009

Reducing authorization Redundancy in Web.config

We are developing a website that includes several pages, where user access is by page. The users are assigned to groups, which correspond to user roles, in Active Directory. Access to the various pages is based upon a member's being associated with any one of a group of roles.

Here is an example that illustrates the situation:

A user is granted access to the pages, "Bananas.aspx", "MonkeyMatch.aspx", and "Swingers.aspx" if (s)he is in any of the roles: "monkey a", "monkey b", "monkey c".

A user is granted access to the pages, "JavaJabber.aspx", "RailsRules.aspx", and "CodeGuru.aspx" if (s)he is in either of the roles: "geek 0" or "geek 1".

A user in the admin role is granted access to all pages.

Only a user in the admin role is granted access to the page, "SpyOnGeeksAndMonkeys.aspx".


So, Web.config might look like this:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<!-- blah, blah ... -->
<system.web>
  <authentication mode="Forms">
     <forms name=".ADAuthCookie" timeout="10" loginUrl="login.aspx" defaultUrl="default.axpx />
  </authentication>
  <authorization>
     <deny users="?" />
  </authorization>
  <!-- blah, blah, blah -->
</system.web>
<location path="Bananas.aspx">
   <system.web>
     <allow roles="monkey a,monkey b,monkey c,admin" />
     <deny users="*" />
  </system.web>
</location>
<location path="MonkeyMatch.aspx">
  <system.web>
     <allow roles="monkey a,monkey b,monkey c,admin" />
     <deny users="*" />
  </system.web>
</location>
<location path="JavaJabber.aspx">
  <system.web>
     <allow roles="geek 0,geek 1,admin" />
     <deny users="*" />
  </system.web>
</location>
<location path="RailsRules.aspx">
  <system.web>
     <allow roles="geek 0,geek 1,admin" />
     <deny users="*" />
  </system.web>
</location>
<location path="CodeGuru.aspx">
  <system.web>
     <allow roles="geek 0,geek 1,admin" />
     <deny users="*" />
  </system.web>
</location>
<location path="SpyOnGeeksAndMonkeys.aspx">
  <system.web>
     <allow roles="admin" />
     <deny users="*" />
  </system.web>
</location>
<location path="images">
  <system.web>
     <allow users="*" />
  </system.web>
</location>
<location path="javascript">
  <system.web>
     <allow users="*" />
  </system.web>
</location>
<location path="css">
  <system.web>
     <allow users="*" />
  </system.web>
</location>
<!-- blah, blah, blah -->
</configuration>

You can see the problem! Having the list of roles duplicated in the various location elements is definitely asking for trouble. What are the chances that someone will mess up the roles on a new page -- or even in the original configuration. As the number of roles and the number of pages increase, it gets even worse.

It would be very nice if the path attribute of the location element could take multiple paths. Unfortunately, it doesn't.

There are options. We could organize the structure of the site around authorization. In that case each location element would only need to reference the containing folder. Sometimes that makes sense.

Another option is to use the configSource attribute of the authorization element. We can then write separate files that have the configuration that we need. For example, we can write these files:

AuthMonkey.config

<authorization>
<allow roles="monkey a,monkey b,admin" />
<deny users="*" />
</authorization>

AuthGeek.config

<authorization>
<allow roles="geek 0,geek 1,admin" />
<deny users="*" />
</authorization>

AuthAdmin.config

<authorization>
<allow roles="admin" />
<deny users="*" />
</authorization>

AuthAllowAllUsers.config

<authorization>
<allow users="*" />
</authorization>

The web.config location elements can now be replaced with:

<location path="Bananas.aspx">
 <system.web>
    <authorization configSource="AuthMonkey.config" />
 </system.web>
</location>
<location path="MonkeyMatch.aspx">
 <system.web>
    <authorization configSource="AuthMonkey.config" />
 </system.web>
</location>
<location path="JavaJabber.aspx">
 <system.web>
    <authorization configSource="AuthGeek.config" />
 </system.web>
</location>
<location path="RailsRules.aspx">
 <system.web>
    <authorization configSource="AuthGeek.config" />
 </system.web>
</location>
<location path="CodeGuru.aspx">
 <system.web>
    <authorization configSource="AuthGeek.config" />
 </system.web>
</location>
<location path="SpyOnGeeksAndMonkeys.aspx">
 <system.web>
    <authorization configSource="AuthAdmin.config" />
 </system.web>
</location>
<location path="images">
 <system.web>
    <authorization configSource="AuthAllowAllUsers.config" />
 </system.web>
</location>
<location path="css">
 <system.web>
    <authorization configSource="AuthAllowAllUsers.config" />
 </system.web>
</location>
<location path="javascript">
 <system.web>
    <authorization configSource="AuthAllowAllUsers.config" />
 </system.web>
</location>

As a result, the groups of roles are kept in one place. The Web.config file now references the appropriate authorization rules in the location elements. This is a great improvement over redundant values in the allow and deny elements.

Acceptance testing pains converting WatiN tests to run in Selenium

For the last year and a half we have been using WatiN to drive our automated integration/acceptance tests for one of our projects  (If you'd like some insight into our decision, see Adam's blog post on it), and it has worked out really well. However, lately we have been experiencing pain when it comes to running our acceptance tests, and we have considered moving our tests to run using Selenium instead.

Our first point of pain is the amount of time it takes to run our acceptance tests. We have around 500+ and they have been taking close to 40 minutes to run. I'm not sure at what point they began to take so long, but I hardly considered 40 minutes to be acceptable. One of the key ideas behind Test Driven Development is the red, green, refactor principle, which requires you to run your tests often. With the acceptance tests taking 40 minutes to run, I had begun to find myself running those tests less and thus losing the security blanket that we had created by writing those tests from the very beginning.

Another point of pain is testing the number of web browsers we are supporting. Currently we are supporting eight different browsers, Firefox 2 & 3 (Mac & PC varieties), Safari 2.0.4 & 3 (Mac only), IE 6 & 7. We are looking to add support for at least two more, Google Chrome & IE 8. One of WatiN's biggest limitations is that it only runs in IE. Our stories had to be tested manually in the other browsers to ensure they were complete and if you do this often enough it, you will loose a lot of time out of your development cycle.

We decided to reexamine using Selenium, particularly Selenium Grid and Selenium RC, in our test suite. We were hoping to a) Speed up the time it took to run out tests b) Run our test across a larger set of browsers. Knowing how the Grid works, we knew that b could easily be achieved, but how would the speed compared to WatiN.

As a test we converted a small subset of our fixtures, about 10, over to Selenium and did some slight benchmarking. After the 10 fixtures were converted, we didn't see any initial improvement in the average test time. It was decided the advantage gained by being able to test across multiple browsers was more than enough for us to convert the rest of our tests to Selenium.

It appeared the quickest way to move forward was to rewrite our tests using SeleniumIDE. It took two developers about a week and a half to convert every test over and flush out any old tests or broken tests. After this was all said and done the Selenium tests ran about two to five minutes faster than the WatiN tests, but I feel that what we gained was well worth the effort. At the very least, we did not slow ourselves down and we can now test across multiple browsers with ease, and I like knowing that whatever changes we make will be tested and tested well.

*We were able to speed the tests up and get them to run in as little as 12 minutes. I'll share that in a later post.

Pairamid

A few teams at Asynchrony have used pairing charts as a mechanism to help us pair and change pairs frequently so that we gain the benefits of sharing knowledge, widening our understanding of the code, etc. Here's an example of something I call the "pairamid" (pun intended):
In this particular pairing chart, we put a tally for each pairing session, color-coded by day of the week. It serves as a gentle reminder in our war room that we shouldn't let one of the squares have too many more tallies than any other and that person x should try pairing with person y (which we obviously weren't doing very well that iteration!).

Link roundup

Product ownership:

• A Product Needs an Owner

Agile adoption:

• Little Scrum Pigs and the Big, Bad Wolf

Testing:

• Best Practices for Implementing Automated Functional Testing Solutions
• ATDD: An Overview
  

Tools:

• Choosing a code-coverage tool
  

Reference:

• RDocul.us: All Ruby Docs, always up to date!

Conferences:

• StarEast 2009
• Software Craftsmanship 2009