Last Weekend's Code Retreat in Boulder

First up, thanks to Adam Esterline for coordinating last Saturday’s code retreat. Then thanks to Rally Software for hosting the event, for sponsoring lunch, and for supplying a half dozen developers. It’s great to see a company with multiple software craftsmen interested in spending a Saturday working on their craft. And thanks to LeanDog for sponsoring breakfast and consistently looking to sponsor craftsmanship in the software community.

As an added bonus, due to the small crowd, it was decided that we’d head up to the real office and use actual pairing stations for the day. Pairing does not require a nice setup to work. The biggest benefits are simply in the collaborative nature of writing code. That said, pairing can be tiring, since it is such a focused, concentrated effort, so it is nice to be able help facilitate that focus by having a comfortable setup where each of you can easily see what’s going on in the code, make changes, and not be constantly turning the monitor so you can get a better view. This setup was different than ones I’ve used before. Two very large monitors, two keyboards, and two mice composing two mirrored setups attached to a common Mac tower. The monitors were set on the corners of the tables (rather than side-by-side),facilitating face to face discussion (when not focused on the screen). It was a nice switch from a 15” laptop.

We followed the Corey Haines prescribed method of code retreating (see How It Works) for the most part and after a basic introduction to Conway’s Game of Life, we began iteration 1.

At the start, all the pairs were thinking the same way, work top down. Start with the Grid. (I swear this wasn’t my influence) This crew was already quite proficient at TDD and at things like keeping methods small. In turn, this iteration was about getting our brains into the game. In my pair, we only ran into to some trouble once it got down to the point to code up the rules for the Cell. Until that point, all steps were precise and small. The trouble was now avoiding a big step, but the iteration ended, so we reverted everything and took a break. (In retrospect, I think we were thinking too big for that next step. We’ll see if the next time I remember some of my later thoughts on avoiding that.)

Something that happens to me every time I work with Game of Life (similarly LCD Display kata) is I end up drawing out examples. Here’s a rendition of the index card we had:



One of these times I really want to go ahead and give a shot to iterating on some simple visualizations. Maybe a Grid.visualize() using System.out.

Iteration 2. We switched pairs and again had a common curiosity of how would this feel differently if we were to start from the inside with Cell. The cell was put together pretty fast. I was quite happy with our 1 line implementation (and it would have still been 1 line if we had fixed the bug in it). We still had a bunch of time, so we went to working on the Grid. Even though we didn’t end up completing the Grid still, it was insightful that we weren’t going to have any of the “big step” issues we ran into at the end of iteration 1. Given the Cell had its rule set to evolve, it was easy write simple tests for evolving the Grid.

On to iteration 3 and "TDD like you mean it”. I’m still fascinated by how to make this work, but I need a lot more practice. I think Adam and I were the only two who had tried it before, so the rest of the group was new to the concept. Short version: it’s fun; it fries your brain a bit.

After lunch, we moved into the experimenting stage. For iteration 4, the experiment was avoid using if statements (assertions in tests not included). I don’t have great notes from my pair’s results, but the other pair ended up in an interesting place. From what I understood, they created a decision table of some sort where each cell could map its evolution from its current state. From a distance, it looked complex and not exactly expressive. They also got caught up in the data, which caused some slips in their test driving. An interesting concept, that I’ve seen something like in production code, so cool to see how making it expressive is a real challenge.

Iteration 5’s experiment was nothing but 1 line methods (return this; // didn’t count). My pair and I got rolling along pretty quickly. Having done some experimenting with fluent interfaces before, this helped us especially in the tests to keep to 1 line; not test 1 thing; not assert 1 thing; but 1 line. Fun :) As we got deeper into Grid though, it got more challenging. We decided to go ahead and get to green with many line methods (read: nested for loops) and then refactor. (Again in retrospect, I think we needed a smaller step here.) Anyway, we put our refactoring hats on and started to pick it apart. It was definitely good practice in finding ways to extract methods and the code did get more and more expressive.

Finally iteration 6 (getting tired), we had a bit of discussion around being Acceptance Test Driven. Since we were in Java, we were discussing JBehave and looking at how that would have influence the design of our Grid’s interface. I do see this as a benefit to ATDD (and BDD), but I’m most interested in getting people to work this way in order to emphasize the importance and dramatic effect of having a discussion about a requirement in terms of specific (executable) examples written from the user’s perspective by a collective of analyst, developer, and tester. But I digress...

It was a great day. For me, very nice to be close to home. And as is always the case with code retreats, it was great pairing with other craftsmen, off the treadmill of the normal work day. It was a very insightful day for me. I need to find another one to attend...

But wait... as it turns out at Agile 2010 in Orlando this August, I’ll be facilitating a code retreat session (Wednesday, 11 August 2010, 09:00 - 10:30). We’ll have 2 shorter than normal iterations, but for those interested we’ll continue iterating afterward in the open space. Hope to see you there.

Developer Priorities and Guiding Principles

Sometimes you have an inclination about a design and then when you get into implementing, you run into a conflict with your inclination and possibly get stuck wondering what to do.

Recently, a pair on my current project was test-driving their solution to the current story. They had to query a service for some search results, but there were some special conditions. If the service throws an exception, present message A. If there are 0 records returned, message B. If there are over a 100 records returned, message C. Otherwise return the results themselves.

A fairly simple approach to this would be to have your controller delegate to a business class, get the results, and then inspect the results and return the appropriate answer with just a couple if’s. Opinions may differ right there. Some might like the fact that the specialized error message being displayed is “in the presentation tier”. Others might say, “why is your controller making choices like that?” And others might say, “if..else?yuck”.

Well lets use our priorities to figure out what we’re going to do. First, be test-driven. We should first and foremost be delivering a testable and tested solution. To me, it wasn’t even an option to just return that result set past the controller to the view and code the decision (aka logic) of displaying results vs. error message and what error message in the UI proper. At least in our environment (JSPs & WebLogic), that’s not testable.

Next priority, remove duplication. I’m not going to get into the purity discussion of whether you write the duplicate logic first and then refactor it vs. write the first case then refactor it at the start of the second case vs. “see it coming” and put the first case in the right place (or so we hope). In fact, in the case I’m referring to, we did the latter, but right behind this feature is another feature to do the same thing (notably with the exact same error conditions) from another angle. The second feature will have a different controller, but will be able to reuse the same business class. Anyway, we felt justified in that decision.

Back to the duplication. In order to avoid duplication, the suggestion was to push the logic of analyzing the result set to the business class, where in the special cases we’ll throw an exception with the appropriate message. Now maybe some of you are reacting like this pair did to the suggestion 1) is no results really an error? and 2) it makes me itch that we’re pushing the message Strings into the business tier. My response... I agree, but... I consider the first 2 priorities to be much more important than this itch I have. a) it’s in one place, so when the itch festers, we can fix it for both cases quickly. b) it’s tested, so when the itch festers, we can fix it safely.

In fact, in this case, both cases will have BDD tests on them while the business class will be fully TDD’d.

My point: have a bias towards action and use your development priorities as a guide.
My opinion: 1) testability 2) remove duplication.

Application Servers and Test-Driven Development

If you are considering tying your next project to an application server, you should seriously consider the consequences of this. What are you really after? Why do you think this is a good idea?

More than likely there are a handful of alternatives to all of your concerns. And if you were to pursue these alternatives, you will greatly improve the productivity of your team.

If you are a member of such a team where you have little to do with the decision to run under an application server, I will also make some suggestions on how to work around the server more effectively.

Background

I am a very strong believer that being test-driven is excellent start towards generally improving your productivity. I am also a believer in being story-test-driven, however that’ll be a discussion for another day. When I say “test-driven”, I am specifically referring to the red-green-refactor mantra of TDD. With respect to application servers, this does not include JunitEE and/or Cactus style testing. It’s simply not practical to write a test, compile it, build an ear, deploy it, and run your test to see it fail. On my current project, the average round trip to make this happen once is about 30 minutes. In the TDD circle of life, generally speaking, I want this cycle to be less than 5 seconds (once the test is written).

There are many reasons to be test-driven in your development. Writing tests first ensures your code is testable. Writing tests first clearly influences your design. Writing tests first definitely helps you minimize over-engineering your solution (which also saves you a lot of time). And the left over artifact of tests helps you avoid unintentional breaks from future enhancement and from refactoring. The tests support refactoring, which in turn keeps you from suffering code rot. And code rot might not kill your project instantly, but it will kill morale. There are many other reasons as well, but I’d recommend you read Test Driven Development by Kent Beck, Refactoring by Martin Fowler, and Clean Code by Robert Martin for that. As for app server development and test-driven strategies, I would strongly recommend you read J2EE Development without EJB by Rod Johnson.

Now if you do happen to have an application server, you need to consciously work to architect around it in order to be able to effectively test-drive your code. Things to consider: First, minimize your dependencies on the app server. Regardless of what front-end framework you use, keep the front-end extremely thin and light. You can certainly use JavaScript on your client, because you can unit test JavaScript with any of a handful of frameworks, none of which require you to be running the app server to run your tests. By thin and light I’m referring to JSPs, JPFs, Actions, etc. You want little to no logic in these files. Utilize some form of MVC here to maintain a good separation of concerns. If you keep nothing but simple mappings from domain/model objects to view objects and otherwise just make simple calls to the POJOs just beyond the application server, then you can keep the top-most level of your POJO model focused on the behaviors required by the application. You can easily TDD your way from there.

Just a thought: I recommend making it a goal of yours to start up the application server as few times as possible every iteration. I’m even thinking about keeping a metric for this, because I’m sure it will be directly correlated with story cycle time.

I hope this could help frame your dealings with an application server with a little bit of stategic thinking as well as help make your testing strategy more effective.

May all your tests run green.

Top Down

I’ve been following a top-down approach to programming for years. I feel like it is the best approach to not over-engineering things. Along with ATDD and TDD, it’s a very methodical, disciplined approach. It’s also customer-centric, since by starting with an acceptance test, you’re focusing on the behavior the customer wants.

At this weekend’s #coderetreat (http://coderetreat.ning.com/, July 2009, Farmington Hills, MI), I was intrigued by the approaches taken in attacking Conway’s Game of Life (http://en.wikipedia.org/wiki/Conway's_Game_of_Life). With the game of life, it turns out there are 2 major approaches that seemed to dominate. The first approach we’ll call “cell”, which is a bottom-up approach (much to my chagrin ;-)). The other we’ll call “grid” and that’s the top-down approach.

With cell being bottom-up (or inside out), you start with a cell and TDD the behaviors of life and death for the cell first. Now for a kata, that’s fine, because you can only do so much in 1 hour before the next iteration.

I was looking to approach the problem as an application however, a craft I’m always interested in honing, I so went straight to grid. That’s not necessarily the best name, but from this perspective, my pair and I started with questions like “what will the user need to see first?” “OK, a grid and then the user will need to set some initial cells to alive.” And so on. It should be relatively obvious, that the design from this approach will emerge quite differently.

In the past, I’ve worked with FitNesse and more recently with easyb. Both of which could do the trick of ATDD’ing the grid, but Jeff “Cheezy” Morgan introduced us to the new and improved JBehave at #coderetreat. JBehave has a super short setup time and actually runs seamlessly via the JUnit runner. So we ATDD’d our grid with in the afternoon with JBehave by defining the behaviors the user would require. Such as:

Given I have a grid

And I select some cell at 2 and 4 to be alive

And I select some cell at 3 and 3 to be alive

And I select some cell at 3 and 4 to be alive

When I evolve

Then the cell at 3 and 3 is alive

And the cell at 2 and 5 is alive

And I’m excited to do more with JBehave.

So I’m actually advocating first and foremost attending #coderetreat and using a kata-based approach to honing your craftsmanship skills. Second, I’m recommending trying to approach things very consciously from the customer’s perspective and in a way that will lead quickly to executable software, specifically top-down. Use your ATDD framework of choice (even XUnit), define a behavior of the application, then TDD the necessary units to deliver that behavior… rinse… repeat.

Don’t Get Burned

I believe that sprint burndowns are a crutch.  You should be aware of their misuse and you should figure out what you can do to move beyond them.

Like crutches, a sprint burndown can be useful to get you on your feet.  Their intention is to help you see where you are with respect to the stories estimated during sprint planning. 

If you feel you /need/ a sprint burndown, then I’d ask why?  Do the current stories in flight and done so far not tell you where you are?  If not, then that’s the thing I’m saying you should be looking into and fixing.  Perhaps your stories are too big, so they’re in progress for 5+ days and you want to know if it’s going to be 4 days or 6 days?  Perhaps the team is not communicating enough?  Is there a high percentage of the team working on each story (especially larger stories)?  Are there at least a few team or partial team meetings around the design of each story (and I don’t mean during planning) as well as around design changes discovered?  If not, why not?  Would that help communicate the status of the story?

If your team is healthy, then you should be regularly experimenting with process improvements.  Try removing the burndown.  Retrospect on what was missing without it.  Perhaps bring it back and strive to fix some of the other issues as well.  Then try removing it again when you feel the communication or whatever has improved.  Ultimately though, planning (and tracking of the plan) is waste, plain and simple, and we should strive to minimize it.

That’s all presuming you’re using your burndown properly in the first place.  Here are a few things to beware to never do even if you do keep a burndown. 

Don’t let your burndown manage you.  Just because 7 of 10 tasks are done, remember the story is /not done/ and so it is building inventory (i.e. useless to the customer) until the story is done.  At the end of the sprint, it’s a binary done vs. not done.

Don’t get actual hours confused with ideal hours.  No one should even begin to think that because you have x engineers for n days at approximately j hours per day that you should be able to deliver x * n * j hours of work this sprint.  Fred Brooks told us years ago, “the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth”.  I believe the context fits here.

Yesterday’s weather relates to velocity, which is story estimates not task estimates.  This is not a precise number.  We’re talking about estimates here.  Estimates are not precise and to think that they are is bad for business.  If you want things to be more precise, then shorten your sprint length and go from what’s been delivered.  That’s precise, because it’s done.

Don’t let the tasks manage you.  The next healthy thing to do after eliminating the sprint burndown is eliminating task breakdowns altogether, but that’s another topic.  Just leave it to say that because you have tasks from sprint planning, don’t just each grab your tasks and go to your cubes and work on them.  It’s far more effective to have a pair (or more) tackle the story as a team.  We want to /encourage/ communication. 

And this may sound obvious, but trust me, it doesn’t always happen.  If a task on the board is no longer relevant, remove it.  If something else must be done for the story to be done, add it.  If you see a refactoring to do while working on the story, do it.

Now that’s all about sprint burndowns.  Release burndowns can be a different story, however, but again a future topic.

Simple Is Not Easy

Simple requires discipline and courage.

 

Just implementing some feature without tests and without really considering the class responsibilities involved… that’s easy… well for a little while anyway. However, being disciplined to test-drive your change in and then refactor mercilessly for single responsibility, removing duplication, etc that’s how you keep your design simple.

 

Just exposing your class’s data and then reaching into it further, violating the Law of Demeter, that’s easy. However, being disciplined to recognize you have some inappropriate touching going on and instead at least encapsulating that into tested methods will help keep your design simple.

 

Even then, if you do recognize for example a class is too big, just taking some of it (hopefully related pieces) and putting them in dependent classes can be easy. However, ensuring that you do so without creating a nest of intertwined dependencies, required to keep it simple, isn’t necessarily easy.

 

I am interested in simple designs and disciplined approaches to keep a design emerging simply. I am also interested how to better influence others to do the same.