Code And Cocktails

Second Successful DMing! A Character Death, Treasure and XP

| Comments

The characters, two from last time and two new ones went off the
moathouse (/FINALLY/). They hired Kobort & Turoko to come along. I
haven't decided just when/if those two will double cross the group, but
so far the time has not been right.

They encountered the infamous Giant Frogs in front the moathouse. The
Giant Frogs which are well know to TPK plenty of groups did not roll too
well and there were no deaths. One halfling swallowed but managed to
get out, and couple people brought to near 0 HP.

They quickly scampered back to town and I was kind and allowed the
Cleric from the player who could not make it to do some Cure Light
Wounds so they only lost a day in town.

Again they went back, and again they took their sweet time doing
anything - but they found the Spider! or more like it found them and
started to gnaw on a halfling's head (same halfling as above). Finally
before getting killed itself it managed to sink is fangs into the Magic
User who succumbed to its poison. Poor magic user, never actually cast any spells in this game.

So then back again to town, a smidge of loot dispersal and Players had
to go home early so we called it there.

Fun was had. Dice were rolled. Monsters killed. It was successful.

Well That Went Well - DMing AD&D1e for the First Time in Years...

| Comments

In my normal gaming group the usual suspects of who runs the games
didn't have any big ideas and/or were busy with real life to put the
work into a big story. So I took a risk and said I'd run a AD&D 1e
game, some module I had, just to keep the dice rolling.

Well, my first session was tonight, the two main people in our gaming
group showed up and with their 4 characters total they met most of the
important people in the quaint Village of Hommlet. The players seemed
to enjoy themselves, and I did as well.

I had too much fun over-acting several NPCs and also kept them on their
toes a bit when the young hobbit thief wanted to do some
extra-curricular activities the minute he entered town.

Next session they will be heading to the moat house and we'll see how
well they will survive that. It would be smart of them to take on some
help, hirelings or just let some of the NPCs join them. But who to
trust?! Zert the smooth talking fighter? Turuko & his big, dumb friend
Kobort? Or maybe Elmo the fall down drunk son of the Captain of the

I know who they should and should not pick, and am pleased to see that
they may be making some poor decisions... its more fun that way :).

Slow Programming Movement (Response to @marick & @RonJeffries)

| Comments


On August 3 Brian Marick tweeted [1]

Agile is a melding of a craft ethic and super-responsiveness to change. How would some explicit Slow Programming fit in?

Then, on August 4, Ron Jeffries responded: [2]

@marick I wonder if TDD might be “Slow Programming”

I also responded quickly – but wanted to take the time now fill in some more details to my response[3].

This response is based upon my personal understanding of the ‘Slow Movement’[4] which may or may not be entirely in line with the actual goals/aspirations of the ‘Slow Movement’. Also at the time of this writing I find that there is already a Wikipedia entry for ‘Slow Programming’[5] but I disagree with the description of that as linked from the Wikipedia article[6].

What Slow Programming means (to me)

To me the “Slow *” movement is about being deliberate, mind-full and sustainable. Thus slow programming would involve programming in a way that is done with thought, and is sustainable over a long term. It would not involve quick “hacking” of code to meet arbitrary deadlines in a way that cannot be kept up for weeks/months/years.

The ‘Agile’ process(es)/practices to me lead us to this “Slow Programming”. Specifically the practices of TDD & Sustainable Pace.

We all know that going ‘fast’ does not mean necessarily going ‘well’. As Kent Beck says: “If it doesn’t need to work; I can get it done much faster”.

TDD leads me to program very mind-fully. Always thinking of the next thing the piece of code must do or not do. Before TDD I would just write the code I thought was needed for the requirement. But with TDD I write the requirement as a test and then write the code to make the test pass. That leads me to be constantly thinking about the requirement; constantly questioning the requirement. I am always asking the “Customer” what they meant, do they mean “this” or “that”; and what if “something-else” happens? My code with TDD is not done more quickly than before; but in the end I know exactly what it does; and it does not more. In the past my code might do things I had not intended (for better or for worse).

Sustainable Pace keeps me from overextending myself for long periods of time. Of course when a important deadline looms I push; but through long experience I know that pushing is a double edged sword: the stress keeps me focused; but the speed reduces quality.

Programming needs to do be done very conscientiously and at a pace that can be kept up in the long term. One must always be 1) doing only that which is needed, 2) questioning the customer what is needed to ensure #1 and 3) keeping up a good pace because burning out your resources are, in my opinion, unprofessional, since it leads to worse code.

In Reaction to the existing definition of Slow Programming

When I began this blog post I was not aware of an existing ‘definition’ of Slow Programming[6]. That definition appears to be made in opposition to Extreme Programming[7] and I think that is not the right angle to take. Given that we know that requirements will always change (unless the “Customer” begins a “Slow Business Requirement” Movement) the concept of having “careful design process by a fairly small number of people who know the business well”[7] is not going to work. We must design only as much as possible to handle the given requirements, meet them; then allow the “Customer” to play with them to discover their next requirements. Perhaps this is the important part of the “Slow Programming” concept: giving the “Customer” the time to discover their own requirements – not rushing them to attempt to get all their requirements before we start programming.









#bostonsc July 28 2010 Meeting Notes

| Comments

In Summary:


In Specific:

Presentation of Pairing Games

The meeting started with a good presentation by Moss & Laura from Cyrus Innovation[1]. The presentation was their “Pairing Games As Intentional Practice” talk which they will be giving at Agile2010[2]. The talk was good and had interesting ideas about playing games with pairing like one might play games with coding katas etc. e.g. Do the pairing with some specific restrictive rules such that lessons can be learned; activities practiced etc. They presented several games (Socrates, Silent Programming) they have thought up along with the classic Ping Pong; and guided us in the creation of our own game (One Minute Switching).

We put some of these games into practice when we went on to do a coding kata. I think it would be very beneficial to have the game playing in the session; but their slot does not afford this. I suggested that they us an Open Jam[3] slot; they could announce it during their talk and then guide the games during the Open Jam. New games could be developed as well. I’d love to hear about any new games that are developed.

Coding Kata with Pairing Games

After the presentation, and pizza we worked on the Tic-Tac-Toe kata. We had five pairs and decided we’d try out some of the pairing games.

The One Minute Switching Game

We started with the One Minute Switching we had designed in the session. The intention is to keep momentum going by setting a fast pace of switching pairs every minute. The pace was relentless and unforgiving! Every time we’d start something we’d switch. I thought it was a great game; it gave an urgency to all decisions and actions; but definitely not something to do for too long.

The retrospective brought out similar feelings from the other people.

The Socrates Game

We switched and I got to pair with Abby [4]. I am so happy to get to hang out with Abby again even if for a short time; she is so full of energy and great ideas. This probably helped making this paring session really ‘click’.

Our game was the Socrates game which involves the Navigator asking questions of the driver who must answer them after researching in the code; or by changing the code to answer the question. The group decided that the new person to the pair would be the Driver as it would facilitate them learning the ‘new’ code. It worked well; but all pairing groups eventually move away from this game and went to a more standard paring style after an initial use of the game.

Our retrospective on this game brought out the thoughts that perhaps with so little code to learn/research the game was not well suited.

The Silent Programming Game

This was the ‘hardest’ game. There are two rules:

  1. No talking
  2. Switch after three minutes if you haven’t already switched.

It was very hard for me to not want to just rip the keyboard away from my paring partner every second. I felt I monopolized the keyboard too much in this case. It did not help that my partner was not familiar with C#/VS2010 which we were using on this machine.

The retrospective brought up the point that perhaps this game works best when the knowledge level of the pair partners are roughly equal and they both have a good understanding of what needs to get done in the next roughly 30 minutes.

My Quick Retrospective on the Code Katas

I think for the future we should spend a few minutes to set up the initial code needed so we have a failing first (generically named) test. Basically just something that says

public void aTest() 
               assert.Fail("test something here"); 

One or two ‘iterations’ of the One Minute Switching game was spent just doing this; as several of us were not entirely familiar with the IDE etc.

On the other hand the One Minute Switching game was great for this; all choices of the setup needed to be done quickly as the clock was ticking!

I also liked the quick retrospectives after each pair switch. This helped me learn a little from each paring session.

In Conclusion

This was a good session. The Presentation was good and I want to hear more about it. If you are going to Agile2010 consider going to this session.

This was especially great for me because I have limited/no opportunity to pair program in my day job. I find the practice engaging, challenging, and even fun. I’m glad I got a chance to do some tonight.


[1] @moss & @lgdean on twitter;



[4] and @HackerChick on twitter.


Bicycling Activities Involve risks... Of Serious Bodily injury...death

| Comments

I was going to join in on Boston's Bike to Work convoy at the end of May
and even was going to 'register' for it (I was on the website finding out the routes etc) when the
registration brought up the 'waiver'.

I thought the waiver was going to be a simple "if you get hurt its not
our fault - take responsibility - blah blah" sort of thing. After
reading it I decided I could not agree to the waiver; and that this
organization unfortunately did not want me to join on their bike rides.

1. Section 2 of the waiver proclaims (in ALL CAPS) that: > "[I] UNDERSTAND that: (a) BICYCLING ACTIVITIES INVOLVE RISKS AND
Really?! Wow I better stop riding my bike - that thing is a death

Shall we make everyone buying or renting a car sign the same waiver?
What about people buying shoes or participating in walks (do those
walks have such waivers? I haven't been in a charity walk for many

Yes, activities one undertake in life may be risky. I would hope all
adults know that. I feel that this is bordering on fear-mongering.

2. Section 3 is all about helmet wearing. I do not personally wear a
helmet. I don't care if you do. In my opinion it is up to each
person to how they wish to manage the risks of injury from whatever
activity they are undertaking. Walking on stairs, crossing streets,
using showers or tubs have all proven to be very dangerous activities;
helmet use there may be beneficial. Also clearly motor vehicle use is
VERY dangerous (to both the occupants of those vehicles and those in
their environment) so those persons should take strong precautions.

> ANY INJURY I incur as a result of my wear a helmet".
So if i am wearing a helmet and smash my face on the pavement after
failing to properly dodge a pothole/road debris I don't have to assume
the responsibility? (The waiver does go on to close this loophole in
another section).

This section more importantly state that > "I fully understand that failure to wear a helmet while riding a
> bicycle at any point during the participation in Boston Bikes is
> strictly prohibited and will result in my expulsion from the event."
Since I don't want to make a fuss, nor make anyone on the ride be
forced to 'expulse' me I must not join the ride (sadly).

It seems to me that through this waiver (which must be 'signed' to join
in these rides) that Boston Bikes wants to encourage helmet use more
than bicycling. I, myself, would like to encourage more (safe) bicycle riding, so for
now, I will lead by example. I ride my bike nearly everywhere. I
signal my turns and lane changes, I stop at red lights and stop signs, I
yield to pedestrians in crosswalks. I ride carefully, for my sake and
for the sake of the other road users around me. I hope that the other
road users take this example to heart and do the same.

Does Software Craftstmanship Have 'Survival Fitnesse' in My Environment? (Comment on @unclebobmartin QCon Keynote 2010)

| Comments

(Short comment on "Convincing Others' slide from Bob Martin's QCon 2010
Keynote (~0:45:00 - 0:47:00 in the video

Uncle Bob suggests that simply doing the best job you can, and sticking
to your principles and disciplines can convince others that the
craftsmanship approach is a better one.

However that assumes that the Software Craftsmanship has a survival
fitnesse greater than other approaches in your environment.

If you are working in an environment where non-craftsmen are seen to be
better (more features produced faster) than the craftsman (less features
produced slower, but _better_) then no one will be convinced to change
behavior. In such an environment there is no REASON to change - in fact
changing would be detrimental.

I currently fear that I work in such an environment.

(I fully understand that this is a case of 'change your organization or
change your organization' (stress on the latter) - and I HAVE stuck with
this position for too long given the conflict on values that seem to