Code And Cocktails

TDD and REPL Analogies?

| Comments

(a half-baked thought)

In a previous post I realized that to me TDD has a little bit of the same feel as working in a REPL. When I first learned the technique it really clicked for me since I always preferred what i referred to as exploratory coding, that is, cycles of trying out little changes and moving toward the solution of the whole problem.

In a language with a REPL this exploratory coding is pretty normal. It is very natural to try something, play with ideas, and periodically save off the code you want. Without a REPL and TDD the cycle is slower, which leads to making larger changes since the cost of small changes is so high. Without a REPL, but with TDD, the cycles can be kept pretty short: short cycles of unit tests, longer cycles of integration and end-to-end testing.

So TDD gives one the ability to try out ideas quickly like in a REPL. It is not as good as a REPL. Of course TDD has other effects so the fact it is not a REPL is made up for. But, to me, the benefit of being able to play with ideas, trying lots of things, saving the good and discarding the bad should not be forgotten.

As an example of this sort of REPL/TDD based play I offer this video from Mike Feathers doing the String Calculator kata in Haskell.

How I Learned Agile All Wrong and Still Ended Up Liking It.

| Comments


Up until several years ago I only knew one way to do a software project. The “usual” way: Requirements document; bunch of coding; deadlines which were basically impossible; throwing the app at QA; thrashing to “improve quality”; sending it to the customer and then “firefighting” to fix the fact that it didn’t meet the requirements. Sure there were glimpse of other ways; small changes to the process etc.; but generally the same.

Then I learned about “Agile”. (I fully intend those quotes). The company I worked for was bought by another larger company. That company seems to have had a team which “went Agile” from the bottom up and the company decided that it was going to be the “new way”. I was one of the “important people” who was on the new project which was going to be one of the flagship “Agile” projects.

What I Was Taught

We got two(ish) days of consulting. We were taught story writing, planning poker, iterations, QA in-iteration, and some TDD examples (damn Bowling Game). The impression I got was that we’d be working in close teams, prioritizing every iteration (because requirements are always changing), working hard to produce only the code we need (and do it cleanly), release this frequently to get quick feedback. I also was “taught” the “don’t do design” idea. I know several of my team members feel they heard the same.

I thought this was AWESOME. I drank the Kool-Aid and then went back for a second cup.

I worked to learn more and more. The company sent me to Agile2008, and I I took myself to Agile2009. I went to other conferences, I read books, blogs, I went to meetups and talked with people.

What I Learned

I learned many things, sometimes the hard way, not all direct lessons.

I learned that “going Agile” isn’t going to work unless people want to give it a try. Imposing “Agile” from above won’t work. The people involved need to want to at least try it. Most important of course is the by-in from management in and above the team.

I learned, and am still learning, ways to help teach and learn from my coworkers. At first, being very gung-ho about it, I came off a bit too “you’re doing it wrong!” and that turned people off and probably burned a few bridges that could have been useful later.

I learned that having QA in-iteration, or even better, “pairing” with QA on the tests (automated or manual) for a story is very powerful and can flush out issues (potential or realized) quickly.

I learned that the “don’t design” idea doesn’t work. (I probably wasn’t intentionally taught that, but I really feel that it came out during our training. Perhaps an overemphasis on not getting attached to an up-front design and letting TDD take its course.) I initially tried it, while my coworkers rejected it, and TDD, without trying it. I think by trying - and not succeeding - at it I have become better at what amount of design is needed, and how TDD can lead to good designs (at least at the micro level).

I learned that my ideas about OO design were not good. I was mostly just doing imperative programming in big bags of loosely related things I called classes.

I learned that clean code is flexible and can be easy to understand and make changes to. I learned that I had a LOT more to learn about writing clean code.

What I Like

I love the idea of transparency. This was not taught. I learned it own my own and I feel it is one of the most important things about “Agile” and wonder why it is not presented more. It can be scary, very scary, not to be able to hide behind the buffered schedule, or the layers of management, but in the end I think it is better to be open and up-front about everything going on in a project. If there are problems it is best to get them out in the open earlier, so that they can be addressed earlier (when it is generally easier to address them).

I like working incrementally. Working on small stories in time-boxed iterations help me to keep focused. Each iteration I have to make sure that we have a (at least potentially) releasable product. I learned long ago that today’s new product is tomorrow’s maintenance product. So bringing out the maintenance problems by practicing the release every iteration brings out the maintenance problems sooner.

I like working with in-iteration QA. Being able to work with these professionals closely helps me ensure my code does what it needs to do, does what it should, and most importantly doesn’t do anything else. It also gives me quick feedback.

I like quick feedback, always have (but I had forgotten over time). Quick feedback helps me focus on what is needed and keep the aim true. If the aim is off we know faster and adjustments can be made. Also obviously easier to fix issues found sooner than later.

I love TDD. Plain and simple. It took me a little while, but after being taught the TDD technique, I realized I knew it. I used to call that sort of programming “exploratory”. When I had a REPL, I coded by trying something out, testing, playing; then I’d save it and test the larger chunk. This would be repeated. Without a REPL I’d do it in a larger slower edit-compile-debug cycles.

Finally, I like how what I have learned has moved me to much produce much cleaner code. I still have much to learn here. But the “stressors” of repeated frequent releases, evolving requirements, and TDD have pushed me to write, IMHO, much better code. It has also driven me to think outside the imperative and OO paradigms.

What I Still Want to Learn

I do still need to learn much more about producing the best code I can. Also to keep in mind that the “best code” must also be the “right code” - it must provide the features needed.

I still need to learn some “people” things. I need to learn how to better learn from, and teach people.

And most importantly I have learned I need to learn much more.

Parting Gift From Coworker: "the Team Is Losing a... Certain... Character"

| Comments

That is what my coworker said, in his Russian-accented English.

“The team is losing a… certain… character”

He claims it was actually his wife that decided that I needed to be presented with this.


What it is is a pot-scrubber holder in the shape of chromed skull. I think I’m going to make it into a candy holder in the new office.

Writing a Unit Test Framework in a Language You Are Trying to Learn

| Comments

Tonight's session of the Boston Software Craftsmanship[1] meetup was about
playing with the Io language[2]. I didn't know anything about it before
it was announced as the topic for the next meeting.

A couple weeks ago I started googling and trying to learn the language.
I tried finding a unit testing framework given my interest in TDD, but
didn't find anything (my lack of ability to search for anything was a
trend here). So I decide to try writing one on my own. Perhaps I was
remembering Kent Beck's example of this in his book[3].

Even with my lack of search skills I feel that I learned some
interesting things about the language. I think if I spent more than
one and a half hours at it, and if my searching had been useful, I could
have gotten farther.

I think that I will make this a pattern for me. Right after "Hello
World" I'll play with a unit testing framework.

At the session tonight we ended up ganging up on my little framework and
taking some of the next steps to improve it. It may not grow anymore -
but it has served its purpose.

My basic unit test framework for the Io language can be found on
github[4]. (But Io does seem to have its own unit test framework built
in, but it is hard to find (.../libs/iovm/io/
It is built right into the VM, use it instead of mine please).

Footnotes: [1]




Change Your Organization or Change Your Organization

| Comments

Several years ago I was pointed to Martin Fowler’s quote. For the next few years I tried the first half of the quote. It was hard bit I didn’t really have much luck. Sometimes I felt like giving up; quitting or worse - going with the flow. I sometimes wanted to let the people and company do what it wanted and let the chips fall - at least I would be able to say “I told you so”.

Finally I decided to follow the second part of the quote; and that is what I’ve done. In some ways it feels a little like quitting or giving up. But trying to change the organization that doesn’t want to change is very tiring.

I hope that the new organization will be a better fit for me.

Fit. I think that is the key. The company was a good fit for me, but not any more. We no longer fit; and so since I cannot work to change them, I’ll do the changing.

Hope I’ll get over feeling like I’ve failed.

Change Is Scary

| Comments

Today I did something that was hard for me - something I haven’t done for a decade - I quit my job and accepted another one. It hasn’t been a decade because my current job was so great, as people who I have talked with over the last couple years know, but because I was scared. Change is not easy for me - especially change which seems big to me - like changing my job. I pay my mortgage with that paycheck after all, thus I put a lot of importance upon it, probably too much.

But now change is happening. My new position may not be my “dream job”, I don’t even know what that might be frankly, but I think it has a good chance of being a better job. I’ll be working with some great people and I am sure I’ll learn a lot.

I’ll be put in the position where people are going to expect I’ll know a lot of things - and I’m simply not going to. I’m going to try to deal with those situations, when they arise, without running away screaming.

This change has been long overdue, but I am finally taking it.

Here’s to change.

Rode a 1/3 Century!

| Comments

My goal today was to ride a “marathon” – but in the end I extended myself to 1/3 century. Given that I had some errands to run I just made that the “reason” for my trip. I rode Gale. Gale Gale is a 39 year old, many-10s of pounds 3 speed. She’s awesome. 

First to get fitted for a tux – that was easy – but I realized that my bike computer wasn’t zeroed out so I did that when I got to the mall – so 2.5-3 miles is actually missing from the rest of this story.

Then to the vet – over the hills of Brookline – to get cat food. Ugh the hills killed my knees because I took them too aggressively. The 8lb bag made the bike a bit wobbly – but made it home OK.

Then I rode off to the office to load up both panniers with books from the office – no reason to leave the books there anymore. Two panniers FULL of compsci books made the bike VERY wiggly, had to be very careful. A protest in the common right where I get into it diverted me around the common on the street – which gave me the opportunity to see and say Hi to a coworker, Heather Kanser.

Now, home again, I had to go back out to get mileage. I decided to head to Fresh Pond and take a ride around. Lovely ride but the clouds were gathering and then the “lovely” spring rain started. Cold but refreshing. The path around the reservoir was annoying – LOTS of dog walking – will need to check if bicycles are even allowed on the path – maybe not.

It was on the way back that I got to my first goal, a marathon of riding: A marathon of
riding and I decided to push on to 1/3 century – but where to go? Why the Squirrel Brand Company building: Squirrel Brand
Company. Heading towards home I realized I needed to pad my ride a bit more – so I just took a LONG way home – and riding through a COLD rain – and then finally: 33.33

Got home a very short ride later and my final ride was just a bit over 1/3 century Final
Tally. Average speed just over 10mph. 

Other than my knees bothering me a bit (due to the overly aggressive early riding) I’m feeling good. Going to go get some Chinese food!

LoseIt helpfully tells me that my ride burned 1424 calories. Means I can eat plenty of it without worry. Yum.

@nashjain at @boston_sc - Clean Code vs. Sufficient Design

| Comments

I kept wanting to say something to the effect: "But no... you gotta make
the code clean..." (and I probably pretty much DID say that several

But the point Naresh[2] made is valid: Spending lots of time on making sure
your code is clean may not be the best/most profitable way to spend your

I think a good way to summarize his point is: "If you have a good team
(which you trust), with smart people and tight collaboration with
customers, then the code is not important and will take care if itself".
He suggests an approach of building apps/features quickly (and perhaps
not entirely cleanly) so that you can get feedback from customers
quickly to determine if it is worth spending more time on it. This
makes sense - and if the app/feature is worth it you go back and make it
better. But if it is not worth it - you don't bother; it would be a
waste of time/money.

The important issue here is what 'good enough' means. Naresh says that
you make this app/feature 'good enough'. He gives two different
examples: 1) a feature that they put together quickly and the
customer didn't care about so nothing more was done and 2) an app which
is being slowly and carefully crafted because the initial release needs
to be awesome. Both are "good enough" but "good enough" is very
different in each case.

If the team doesn't agree on what "good enough" means then you have
problem there. Which brings up that this idea that the code will take
care of itself seems to be predicated on the fact you have a great team
with high customer collaboration.

So what if you don't?

Naresh answered this by asking if pushing strict TDD or Clean Code (TM)
was a good way to fix that situation. I can't say it is[3]. Education
seems to be the best thing.

Educating my coworkers is something I realize I need to do - but I am
not sure how to go about doing it. We don't pair program - so I can't
directly "show". I need to find a way to do this.



[1] I feel that my disagreements with Naresh's points are not entirely
logical and are based around my current lack of trust (and opinion
mismatch) with my current team. I agree that his approach is pragmatic -
I worry that 'pragmatism' can be the cover for lots of dumb stuff which
cause pain in the end. Again this goes back to a trust in the team - I
do not currently have trust in my current team and that is coloring my
opinion of how I think his suggestions could work. For them to work in
my current situation would involve a large change, not only of myself,
but of the organization and its members - which I don't think is likely
to happen (but is this opinion too just because I do not trust the

[2] @nashjain

[3] Although as Zach[4] pointed out: in my current situation, doing TDD
and making the code Clean(TM) is sort of a defensive strategy for me.

[4] @zdsbs

#scna Notes & Retrospective

| Comments

* Abstract:

The SCNA 2010 conference was well organized, energizing and personally
useful. The short talk/long break format was a surprising success for
me; allowing attendance in many good talks while at the same time having
great discussion/chats with many people, both new to me and those I look
up to. Hopefully at least some of these connections will be lasting and
the energy gained from this conference will propel me forward to better

* In Summary:

- Craft vs. Art vs. Commodity / Form vs. Function: Making 'beautiful'
code is a great thing to do - but may not be what is needed.
Targeting craft (like a well tailored suit, as opposed to a
beautiful-but-impractical dress, or business casual from Sears) is
probably the sweet spot.

- Value to the Customer: Deliver what the customer needs - not what you
think that need. If you think they need something else - TALK with
them. Maybe in the end you can't do the work they need.

- Always learning: Not a new point, but another good reminder.

- Lots of connections made: Met lots of people, hopefully some of these
connections will last.

* In Specific:

** The format:

Coming into the conference I was not sure if I was going to like the
shorter talks and longer break format, but on the whole, I thought it
turned out really well. During those breaks I met many, many passionate
and smart people. Also these longer breaks let me chat, or at least
thank, some people who I look up to in this community. In other
conferences the short time between talks reduces this opportunity, the
speaker gets mobbed by people at the end of a talk, so having the longer
time allows more people to catch the speakers and others in the rooms
and hallways.

** The talks:

I found the quality and content of the talks to be generally very high
and the single-track format helped me ensure I didn't miss anything. A few points about the talks:

- Uncle bob's point about multiple-cores/cpus making threading/state
problems more prevalent is very important. If the trend does
continue in computer manufacturing we will need to find better and
more efficient ways to deal with the issues that arise. We need to
find ways to help NOT have the problems in the first place.
Functional programming seems like it might be a good direction to

- Doug Bradbury's "personal statement" talk made a distinction I liked
between craft and manufacturing (which links a bit with Fowler's talk
later). Crafts are things made by hand, manufacturing is when things
are made by machines. His talk really showed his passion for
'making' things, which comes out for him in programming. I also
really liked his thought that the design of the program reflects the

- Michael Norton's talk about training software professional, making
the analogy to medical doctors, made some good points to think
further on. I don't have a clear opinion on the whole
certification/licensing issue myself (but my gut feeling is I don't
like the idea - but that is just a gut reaction without much
thought). The part of the analogy I really liked was the idea of
residency, collaborative learning and continuing education.

- Ken Auer's started me thinking more about bringing value to the
customer, it is a part of development that I partially ignore, or
work on less. Later talks added to this. - From the apprenticeship panel I liked to hear from Collin that he
felt that the programmer/musician analogy is often interpreted
incorrectly, that it is not, to him, some sort of brain ability, but
the focus on practice. I liked to hear this because unlike many of my
colleagues I have NO musical ability and hearing the analogy is
always a bit like hearing that I'll never be really good because I'm
not musical.

- Chad Fowler's talk gave me a useful spectrum between 'art' and
'commodity' with 'craft' in between. Form is most important for art
& craft while Function is most important for craft and commodity.
Programmer's focus on making beautiful code, myself included, is
tending to go to far into the art end as what the customer wants is
something functional. His example of clothing, the beautiful dress
which is not useful as clothing - but is art, the expensive but very
well made/tailored suit is craft, and the business casual clothing
from Sears is commodity. Also it was another mention of the need to
listen to what the customer _needs_. If the customer needs commodity
and you make art - you have not done the job right. Unless the
customer truly wants something disposable then craft is best target.

- Keavy McMinn's talk was another good "personal statement" talk. Like
the musician-programmer analogy I've never liked the
artist-programmer analogy since there too I don't have much, if any,
'artistic' ability. However her points were well taken, the factors
which helped her as both artist and programmer are general enough to
be taken as good ideas for anyone.

- Enrique Comba-Riepenhausen's talk again hit the customer-value point.
I found it interesting that three speakers, independently focused on
this point, their talks overlapped and fit together well. There was
some bemusement on each later speaker that the previous speaker(s)
had "given my talk already" but each added their own factor. From
Enrique I got reinforcement for the importance of _knowing_ the
customer, even _feeling_ for the customer. This is an issue I am
personally dealing with as I don't feel like I "get" my customer,
they are not people I would "hang out with", they are not "my people"
so to speak. I feel this affecting my work.

- Corey Haines gave a good wrap-up talk and demanded that we stay
positive, for both ourselves and the community. Negativity is
another personal issue I deal with in all parts of my life, and in my
work it has a particular effect on my work and my coworker's work.
Also I am coming to the conclusion that I want to _help_ other
developers in some way to write better code. Being negative will not
help. Happiness is important.[2]

** Extracurricular activities:

Outside of the conference itself, the Chicago Dine-around; the welcome
party; and the after party were even more great opportunities to talk
and connect with people. The organization of this and the execution of
the dine-around & after-party left me very happy with the execution of
the conference as a whole.[3]

A few things which came out of this that I am interested to see what
happens are: - Patrick Welsh mentioned that he was working (with Mike Hill) on a
piece of specifically bad, but plausible code to be used as a sort of
refactoring test. I want to see it, and use it measure of lack of

- I gave restaurant advice in Boston/Cambridge to someone going there.
Want to hear if they liked any of the places I recommended.

- Determined I need to try to figure what specifically is wrong with
work, so I can better determine if there is anything _I_ can do about
it. ** The bottom line:

The conference was tiring, so much to think about, so much socializing,
and so many really smart people making me feel dumb[4] just smashed me
down by the end. But - it is a good tired, the tired of a job well

** Retrospective

I need to do a better job of planning out learning/training. I need to
connect with, communicate with and learn from fellow travelers in the
Craftsmanship community (someday I will also then teach others what I
know). I need to find a new position where I can be happier, which will
help me do better work, which will help me be happier, etc, etc. I need
to be better about gathering contact info (or at least NAMES) of people
I talk with; there are a few people I remember really enjoying my talks
with, who I can't even recall a first name, let along a twitter/gmail
name. I need to challenge myself, I spend too much of my time just going
with the flow, that will not lead to my growth.

Footnotes: [1] And this left me with an interesting frission between his obviously
strong religious belief that leads him to feel that since he
believes his god created him in that god's image that he too is a
'creator'. If the design reflects upon the designer, then I don't
think that this god is a very good designer. The "design" I see
around me is so full of rude hacks to get the job done that I don't
think it is something to be really _proud_ of. The world needs some
'refactoring' in my opinion. Lots of redundancy, dead code, bugs
etc. I hope to be a better designer than this god.

[2] Oh and cats!

[3] Also, selfishly and frugally, having my dinner/drinks mostly paid
for me made me quite happy too.

[4] When surrounded by all these passionate, brilliant people I feel so
humbled, so small, so dumb. But, this is not something that can't
be changed, it is after all good to be the worst amongst the great,
there is so much opportunity to learn.

#coderetreat Thoughts

| Comments

The code retreat at the 8th Light offices was the first one I had ever
attended. Overall I thought it was great, and again was well organized
like the SCNA conference was.

I came into the code retreat feeling a bit intimidated and left feeling
tired and a bit intimidated. Just like the conference the code retreat
was _tiring_, but still a good tired. And like the conference I was a
bit intimidated by all the passionate, smart people around me. I hope
to be half as good as these people are.

I am very happy that I did get to pair with really smart people in
Clojure, Ruby, Javascript and C#.

* High Points:

** I had never written a line of Javascript before and never even really
read much either. It is very weird, but in a good way. I'm going to
add it to my list in order to at least familiarize myself with it. I
think knowing a bit of it will help me understand other languages
better. My pair (Sean McMillan) did a very good job taking the time to explain the
features and constructs of the language so that we can work

** The God class was an accident, as most gods are probably. Marty and
I started the session saying we'd work on the 'always delegate'
constraint. We quickly decided that Cells needed to delegate to
someone above them... who could that be? God of course. But that
flippant naming changed EVERYTHING. The whole session changed. All
our naming changed. Near the end, we were writing some code and it
wasn't feeling right, Corey pointed out the encapsulation problem in
it. Cells were telling God what to do. Nothing can tell God what to
do! The problem would have been visible without the naming but with
the naming the code FELT wrong.

** During lunch we had a discussion that brought up the idea of the
Cells themselves knowing about their neighbors, mixing this with
genetic programming could lead to extra data on each cell which gets
combined when the dead cell comes back to life rule is applied, as
this could be seen as a reproductive step. Furthermore the extra
data could be somehow relevant to the Game of Life itself, e.g. some
cells might be more resistant to over/under-population than others,
thus surviving longer. I found this a very interesting idea and may
try to find time to play with it more.

* Low Points:

I felt I was a bad pair in a few cases as my thinking got rather cloudy
and unfocused at a few points in the afternoon (especially when pairing
in C# with @MaggieLongshore! sorry!)

* In Retrospect: In retrospect I feel I could have gotten more out of it if I could have
snapped myself out of my mindset that I wanted to "get as far as I
could" earlier in the day. That would have let me play with other
constraints, like no numbers, totally functional etc.