Wednesday, December 31, 2008

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.

Tuesday, December 30, 2008

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:
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.

Tuesday, December 23, 2008

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.

Monday, December 22, 2008

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".

Wednesday, December 17, 2008

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.

Tuesday, December 16, 2008

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!).

Tuesday, December 09, 2008

Hendrickson on ATDD

The prolific Elisabeth Hendrickson has posted another insightful piece on her blog, an overview of Acceptance-Test-Driven Development. I'll let you read it, which includes a .pdf with more details, but I wanted to highlight a graphic from the .pdf:

I think we do the Discuss and Develop components well, but our weaker muscles tend to be the Distill and Demo aspects. Distilling takes a bit more time, but I think it's an example of the old saying "a stitch in time saves nine."

Friday, December 05, 2008

Twitter badges now on blog sidebar

I added individual Twitter badges of Asynchrony employees to the sidebar of this blog. Apparently, there's no way to aggregate multiple Twitter accounts into one badge that I've seen. If someone wants to try, let me know.

Also, I'm using the big block flash badges because there's no easy way to display multiple individual non-flash badges on the same html page. You can read more about it.