What made me start doing TDD

In 2001 I was writing robocode robots and battling them with some co-workers. Things were going well enough — win some, lose some — when a friend suggested we try writing unit tests for our bots. Great idea! I'd been wanting to learn unit testing since at least '97 when I read about it on the C2 wiki.

Before I started writing the tests I thought they would help me catch those last couple of bugs in my program. Sure the average programmer wrote a bug ever 2-5 lines, but I was pretty sure I was better than average and had only a few remaining. After all, not only was I pretty careful with my code but I'd been testing and debugging my bot code for a couple of weeks.

Then I started writing the tests.

Suddenly a bug only every 5 lines sounded pretty good! How had this CRAP ever seemed to work at all?!?

Once I realized how much I sucked without tests I didn't want to write code without them, and TDD was the most efficient way to do that.

... so the "heart" approach is a way of sidestepping the psychological immune system that normally operates to conserve our current view point, our current stored wisdom.

I'm deriving this view point primarily from:

http://www.amazon.com/Influence-Psychology-Persuasion-Robert-Cialdini/dp/0688128165

and

http://www.amazon.com/Wisdom-Paradox-Stronger-Brain-Grows/dp/1592401104

Thoughts on MacHeist

I pay for software, but I won't pay for software if I'm not sure I'll use it. MacHeist has allowed me to purchase software that I was curious about, but that I wouldn't normally buy, because I wouldn't use them enough to justify the cost. Previous examples are Pixelmator and VectorDesigner; current examples are Acorn and Espresso.

I don't know how much the developers got from my purchase, but it is more than they would have had otherwise. I don't know how much they would be willing to pay me to refer them to a friend who was switching to the platform, but they got that too.

So what MacHeist has done is allowed me to pay developers to market for them in return for using their software which I wouldn't have used (or purchased) otherwise.

Win-win.

product owner feel threatened by IxD?

I can imagine an engineering team turning to Interaction Design as part of their work turning Product Owner stories/use cases into product. (Ok, I don't need to imagine this, but I'm going to assume I'm not unique here...)

I can imagine that as you get into the conversations that are part of IxD the Product Owners might feel threatened, because suddenly engineering is asking penetrating questions about who these users really are and what they're really trying to accomplish. A PO who's used to getting away with vague descriptions might take this personally, might interpret this either as an attack or as a power grab by engineering. (Ok, I admit that I'm not just imagining this.)

I think engineering is less likely to respond this way to the PO bringing IxD into the process since these questions/issues fall more naturally into the PO domain and less into the engineering domain. The exception are the UI people who might feel like IxD infringes on the creative aspect of their jobs.

feeling stupid

Jtf:safariwatir jfredrick$ ruby safariwatir_script.rb 

/opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:32:in `gem_original_require': no such file to load -- ./safariwatir/../watir/exceptions (LoadError)

from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:32:in `require'

from ./safariwatir/scripter.rb:2

from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'

from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `require'

from ./safariwatir.rb:2

from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'

from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `require'

from safariwatir_script.rb:2

Watir lists.html

An Unordered List:

An Ordered List:

I hate error messages while installing

Jtf:ostatli jfredrick$ sudo gem install firewatir

Successfully installed xml-simple-1.0.11

Successfully installed rubyforge-1.0.2

Successfully installed hoe-1.8.3

Successfully installed s4t-utils-1.0.4

Successfully installed builder-2.1.2

Successfully installed user-choices-1.1.6

Successfully installed commonwatir-1.6.2

Successfully installed firewatir-1.6.2

8 gems installed

Installing ri documentation for rubyforge-1.0.2...

Installing ri documentation for hoe-1.8.3...

Installing ri documentation for s4t-utils-1.0.4...

Installing ri documentation for builder-2.1.2...

ERROR:  While generating documentation for builder-2.1.2

... MESSAGE:   Unhandled special: Special: type=17, text="<!-- HI -->"

... RDOC args: --ri --op /opt/local/lib/ruby/gems/1.8/doc/builder-2.1.2/ri --title Builder -- Easy XML Building --main README --line-numbers --quiet lib CHANGES Rakefile README doc/releases/builder-1.2.4.rdoc doc/releases/builder-2.0.0.rdoc doc/releases/builder-2.1.1.rdoc

(continuing with the rest of the installation)

Installing ri documentation for user-choices-1.1.6...

Installing ri documentation for commonwatir-1.6.2...

Installing ri documentation for firewatir-1.6.2...

Installing RDoc documentation for rubyforge-1.0.2...

Installing RDoc documentation for hoe-1.8.3...

Installing RDoc documentation for s4t-utils-1.0.4...

Installing RDoc documentation for builder-2.1.2...

Installing RDoc documentation for user-choices-1.1.6...

Installing RDoc documentation for commonwatir-1.6.2...

Installing RDoc documentation for firewatir-1.6.2...

"monad tutorial fallacy" and reading great code

For over a month now I've been planning a blog asking for examples of great code, code that is worthy of study. The idea being that programmers could learn from the masters they way practitioners in other disciplines do.

But reading about the "monad tutorial fallacy" makes me wonder if this is viable. Just as you can't understand how monads are burritos without having struggled with the problem on your own I suspect you can't grasp the greatness of a piece of code without having struggled with the same (or similar) problem first-hand.

If I'm right the idea of having students read the works of master coders might be a lost cause. However this probably strengthens the case for code reviews. People on the same team do struggle with the same problems, so the best code on the team is certainly worthy of study. It might not be the Great but better to have Good that you can benefit from than Great that you don't.

I expect that in a project the estimates at first will be inconsistent as the team jells and gets their arms around the problem space and their solution. But over time their estimates will begin to have a kind of consistency to them that make velocity a meaningful tool for estimating throughput & backlog.

If there are context changes within a project I believe you'd go through a settling period where estimates were of limited value, but that after a while a new equilibrium would be established.

I don't think the velocity before and after the context changes would be comparable, at least not in the general case. If they were in a specific case it would either be an accident or a function of the team normalizing the values.

The team normalizing the values is such a key component that it almost stands by itself for why velocities across projects (with different teams) can't be compared.

muddle

I had offered Newtonian mechanics and flat earth theory as various levels of wrong. Flat earth theory was a late substitution for creationism but it turned out to be a poor one. I had intended to contrast Newtonian mechanics as wrong but a useful approximation, while I was thinking of flat earth as ridiculously wrong and not even useful... except that it is. I use the approximation of a flat earth all the time.

So let me rephrase the question to @marick: Wrong in the way flat earth theory is wrong or in the way creationism is wrong?

AlphaLabelIncrementer

package com.jeffreyfredrick.cc;

import org.apache.log4j.Logger;

import org.jdom.Element;

import net.sourceforge.cruisecontrol.LabelIncrementer;

public class AlphaLabelIncrementer implements LabelIncrementer {

    private static final Logger LOG = Logger.getLogger(AlphaLabelIncrementer.class);

    public String getDefaultLabel() {

        return "a";

    }

    public String incrementLabel(String oldLabel, Element buildLog) {

        if (!isValidLabel(oldLabel)) {

            LOG.warn("old label value of " + oldLabel + " is invalid. Returning default label.");

            return getDefaultLabel();

        }

                 char oldChar = oldLabel.charAt(0);

        char newChar = (char)((int)oldChar + 1);

        return String.valueOf(newChar);

    }

    public boolean isPreBuildIncrementer() {

        return false;

    }

    public boolean isValidLabel(String label) {

        return (label != null && label.length() == 1);

    }    

     }

AlphaLabelIncrementerTest

package com.jeffreyfredrick.cc;

import net.sourceforge.cruisecontrol.LabelIncrementer;

import junit.framework.TestCase;

public class AlphaLabelIncrementerTest extends TestCase {

    public void testLabelIncrementer() {

        LabelIncrementer incrementer = new AlphaLabelIncrementer();

        assertEquals("a", incrementer.getDefaultLabel());

        assertEquals("c", incrementer.incrementLabel("b", null));

        assertEquals(false, incrementer.isPreBuildIncrementer());

        assertEquals(true, incrementer.isValidLabel("y"));

        assertEquals(false, incrementer.isValidLabel(null));

        assertEquals(false, incrementer.isValidLabel("yes"));

    }

     }

Conversation is the key win

Brian pointed out that shorter articles require more sympathetic reading and more need for conversation. To me that is a big win of the short articles, the conversation, and it is a win for both sides. The author doesn't need to spend time guessing about which misunderstanding I'm going to have and is then freed to reply to my actual misunderstanding.

(Who will be the first to make the lean or agile development analogy for this?)

Conference by affinity vs by problem

I was thinking of what you said: "as we use Open Space there is no problem to solve". Now thinking I misunderstood you... but my initial thought was that perhaps you weren't getting what you hoped out of the Open Space conferences because you weren't choosing them based on a problem you had to solve, but rather based on "gathering of like-minded people".

I'm thinking people who come with problems in hand probably have a different experience.