Jake Scruggs

writes ruby/wears crazy shirts

More Lighting Talks!

A lot of people skip the lighting talks, but I find that some of the best stuff at any given conference comes out of the these intense 7 minutes sessions.

Jared Ning: "Ruby Without Borders"
Matthew Todd gave a talk last year asking for people to came to Tanzania and help him code in Ruby. Jared did and he loved the experience.
He mentioned a very useful TextMate short-cut:
If you have a bunch of files and folders open in the project drawer and you click the chevron (the triangle thingy) to close a top level folder then when you open it back up TextMate remembers the state of what folders were open and closed underneath. But sometimes you want to close down all the folders underneath. Option clicking on the chevron will do that. Also, option clicking on a closed chevron will open up all sub folders. I've been looking for this.

Check out Ruby Without Borders.

Jeffrey Taylor: "Fast Multi-protocol XML Parsing"
Jeffrey's project had to read a lot of RSS feeds and it was super slow even with the fast ruby xml parsers. So he rolled his own, which can be found here:


Jeffrey used the sax model to do super fast xml parsing (10 times faster than nokogiri - he claims). He does admit that the code has a Flog score of over 500 for one method.

Hal Fulton: "Reia: The Next Big Thing"
Reia is an attempt to combine Erlang and Ruby. If you want the cool concurrency of Erlang with Rubyish syntax, take a look.

Yehuda Katz: http://github.com/wycats/bundler
A true dependency resolver
From the README:

Bundler is a tool that manages gem dependencies for your ruby application. It takes a gem manifest file and is able to fetch, download, and install the gems and all child dependencies specified in this manifest. It can manage any update to the gem manifest file and update the bundled gems accordingly. It also lets you run any ruby code in context of the bundled gem environment.
So basically it's a better way to vendor your gems with your project. Check it out if you've had trouble using other systems.

Before Matz's Q and A, Jim Freeze got up and talked about Lone Star Ruby Conf's attendance over it's three year span:
2007 - 200
2008 - 282
2009 - 230ish

Which is right around where they want it. Small enough to be intimate, large enough to be interesting. And that size group fits nicely in the Norris Conference Center.

Btw, the network was outstanding this year. They bought something like 6 wireless routers and although sometimes it was sluggish, it remains some of the best wireless I've had at a conference. Usually the high tech load crashes the network within minutes.

Matz Q and A
The two answers that stood out to me were when he said that the Perl $ variables were the thing he regrets the most about designing Ruby. Also, when I asked him about how often he gets to write in Ruby he said that the largest Ruby program he ever wrote is 2-3000 lines of ruby code. It was a mail client with Emacs front end. Generally he uses it for scripts and such. I find it amazing and a little heartbreaking that Matz doesn't get to program in the language he created and clearly loves.

Encoding Domains - Rich Kilmer

First, there was a lot of buzz about Prezi at the conference. Prezi is a canvas presentation tool that so impressed Rich Kilmer that he learned it the night before and wrote his keynote in it. In Prezi you put all your text, videos, images, sound files, and whatever in one huge canvas and then tell give it a bunch of waypoints and zoom levels to follow. It's pretty bad-ass.

This was Rich's first keynote ever. Which is kinda hard the believe as he's been doing amazing things with Ruby since the dawn of time (which is 2000, btw). In it he discussed how software libraries don't have value, they have potential. What has real value is encoding domains. He told an interesting story about how he encoded the domain of a massive military project mostly by sitting down with some experts in the field and figuring out how they would like the DSL to read. Once he had captured all the information they could enter in to their logistics system in syntactically correct Ruby, he went about making it work. He called it syntax driven development and it worked so well that 5 years later he still gets calls about the prototype he wrote in two months. Apparently they are still trying to create the real product in some other language.

Well, the perfect storm of conferences (Agile 2009, Software Craftsmanship North America, and Lone Star Ruby Conf) is now over and I'm looking forward to actually writing some Ruby tomorrow. I need the rest.

Last night Matz gave a keynote entitled "Why do we Love Ruby?" He talked about how Ruby embodies Quality Without A Name (Qwan). Here's a description of Qwan.

I think it might be time to retire this talk, as I've seen it more than a few times before. I'd much rather hear about interesting problems he's solved while designing Ruby or meditations on where the language is heading. A humble suggestion from a guy who's very grateful for Ruby.

TDD: More than just "testing" - Evan Light

Evan started out his talk by pointing out that lately we've been focusing more on tools and techniques more than the goal of testing. Testing is not the end, it is a way to help you get to the goal of a well designed application.

He did a live BDD coding demo - which is very courageous. I've seen way too many presenter's brains melt under the hot lights and audience pressure. He managed to pull it off and show some Behavior Driven Development. Evan likes to write out his series of specs/tests before he writes any code. It's sort of a high level sketching out of the design. Then he works on getting them to pass. Watching him work I was struck by how much good BDD is a conversation between the tests and the code - going back and forth. Sometimes the tests push bask and tell you the code needs to change, but just as often the code can push back on a naive test.

At this point I got up and gave my talk. The crowd was way more into it than when I gave the same talk a few days ago at Agile2009. Later people kept coming up to me and thanking me for the talk and metric_fu. Felt pretty good.

Lightning talks:

How to Get More Women (in Programming) - Sara Brumfield


  • Impostor syndrome - a lot of women feel like they are impostors so they don't go to conferences. They don't realize that just about everyone feels that way.
  • Voice of unquestionable authority - The one guy who asks the really hard intense question. This action can intimidate women a lot more than men.

Suggestion: Offer women's t-shirts at you conference. Little things like that encourage women to attend.

The "Pipeline Problem." Math classes filter out some women, programming classes filter out more, the job itself keeps filtering. Sara feels that we've been trying to solve the pipeline problem for years, but she feels it's not working.

Sara posted a more detailed description of her thoughts on the subject.

Prawn - Gregory Brown

Prawn is a Ruby gem for creating PDFs.
  • High level interface for basic reports.
  • It's the fastest pure ruby pdf generator
  • Prawn is pure Ruby with no tricky dependencies so it runs on all the Rubys
  • M17I is a top priority
The PDF specification is 1300 pages so it's been interesting. 1.0 of Prawn should come out soon.

HTML5 & CSS3 - Dallas Pool

The combination of HTML5 and CSS3 manages to move a lot of the dynamic view stuff out of flash, javascript, and photoshop and into... the view! Looks pretty cool.

If you want to know more checkout a presentation he gave here: http://www.scribd.com/doc/19111526/HTML5-Presentation

CodingMentors.com - Mark McSpadden

Mark wants you to get involved with mentoring developers in specific areas or to get mentorship. You can commit to remote mentoring and limited hours so don't be scared.

Spork - Tim Harper

Spork is a gem that forks the linux process so you can run rails specs faster. Basically you don't have to load up the rails environment every time you run a test (which is why tests that claim to take 0.023 seconds really take 5)

Time for lunch!

I have to admit that this morning I was not looking forward to seeing another day of presentations after 3 days of Agile 2009 and 1 of Software Craftsmanship North America, but almost immediately upon entering the Norris Conference Center I felt welcomed. Part of this is that Jim Freeze, the LSRC head organizer, is a heck of a nice guy who recognized me in the hallway and said hello but also that when I sat down I noticed that every table had plenty of power for computers. Awesome. At Agile there was no power in any of the rooms and very limited access anywhere else. I type up my notes on the presentations as they happen (and I notice a lot of others do the same) so I spent much of my time at Agile glancing at my diminishing power and hoping I could make it through the next session. I know a lot of people hate open laptops at conferences but studies have shown that if you give some people something to do with their hands while they listen to a presentation they consume it more effectively. I know it can seem annoying to have the person next to you furiously IM-ing all his friends but that may just be his or her way of listening.

Something interesting - Dave Thomas

Ah to be so famous that don't have to bother to title your talks. Despite what seemed like a lack of preparation, once he got up there his talk seemed quite polished and interesting.

Dave mentioned early on that it's his tenth year using Ruby which is amazing for a man who has "the attention span of a gnat."


First of all, Ruby is a Multi-paradigm language. Ruby can do procedural, prototypes, objects, and even a passible interpretations of functional all in one somewhat unified whole. They idea is to let you, the programmer, do what you like.

"Ruby thinks the way I think" - which means it's imperfect. "It's gloriously imperfect."

Dave then showed a bunch of quotes from famous people talking about how the sterility of perfection can hinder creativeness. He ultimately concluded that if their is no ambiguity, there is no room for you.

An example of Ruby's ambiguity:
def foo x
puts x

foo { :e => 2 } # Syntax error!
foo :e => 2 # Totally fine

Ruby's interpreter has some quirks - there are heuristics that make your code read naturally and work 99% of the time. So, Dave concluded, some ambiguity is worth it.

Ruby keywords are loose. For example, is 'begin' is a keyword? Check this out:

>> c = Object.new
=> #
>> def c.begin
>> puts "hello"
>> end
=> nil
>> c.begin
=> nil


Ruby's view is there is no right way.

The progress in Ruby is Messy. The size of the Ruby tarball is going going up
exponentially while the number of methods is going up linearly. And Ruby 1.9 is very different from 1.8x. The benefit to breaking some backwards compatibility is new and powerful features keep entering the language.

The People are Messy.

Ruby was the wild west in the beginning with a small true community. But then someone found Gold in them thar hills. Rails came in and all of a sudden the group grew by leaps and bounds.

Dave was physically sick reading Zed's rant (in which Zed Shaw said some none too nice things about Dave). It was 9 months before he slept properly again. Dave thought he was part of the Ruby community. But Ruby is not a singular community anymore. To say Ruby is a community now would be like claiming there was a screwdriver community. Ruby is a resource around which communities gather.

In conclusion: Messy can be fun.

Programming Intuition - Glenn Vanderburg

Last year Glenn gave a talk called 'Tactical Design' in which he advocated focusing on three things for the beginning programmer:

  • Do One Thing
  • DRY
  • SLAP (Single Level of Abstraction Principle)

Last year's talk was all about what you can do. This talk was about how you think.

What makes a programmer good is not a command of the syntax, it's more like art. Great programmers all talk about code as if they can touch and smell it. Large portions of human brains are designed to use 5 senses.

Glenn showed Bobby McFerrin at the world science festival teaching the audience the Pentatonic scale. Then he showed a visualization of Frederic Chopin nocturne opus 27 #2. The point being that music/computation/thinking are all would up together.

At one of Paul Graham's shops they had some mechanical gauges to tracking networks traffic. He could hear the gauges moving and knew when there is a problem without ever having to get up and look at the display.

Glenn was saying that we need to cultivate a sense of code. The best programers seem to use all the parts of their brain including the 5 senses. Quick feedback is essential to this.

Module Magic - James Edward Gray II

So when confreaks post this talk online go check it out. There was way too much code on the screen for me to even attempt to copy it all down. James showed off some pretty cool things you can do with modules. Check out his slides or the full talks and meditate on the code. What I really like about James' presentations is that he knows how to start off slow. He has a real teacher's gift for bringing an audience along.

Towards the end of the talk James said that he feels that modules can replace a lot of what we use inheritance to do now and without inheritance's side effects.

Update, he's posted the slides.

Succeeding with Rails - Chad Pytel

Chad is one of the founders of Thoughtbot and he went through some Thoughtbot's values and strategies that have guided them.

Hiring process:
1. Initial Resume and code review
2. Initial phone call - high level (who you are, what your goals are)
3. Second techincal interview.
4. Week long immersive trial. Payed.

Core hiring principles:
  • Look for the best Skill and Attitude at a Salary you can afford.
  • They hire all technicians (coders)
  • No subcontractors or outsourcing

  • Do the best you can for the client
  • Be proactive (over communicate). Have the hard conversations early.
  • Set expectations and keep setting them. See above
  • Be nice. And fire the not nice customers.
  • Work the way they want or no deal.

Client interaction:
  • Their project planning form is online.
  • They use highrise for managing client information.
  • Use master services agreement (how we work and how much you pay us) and set out the first several iterations
  • Appoint a project lead (PM/CP)

Development values:
  • Practice sustainable development - 40 hour work week
  • Design first (build the user interface)
  • TDD
  • Iterative development - use Pivotal Tracker
  • Focus on time instead of money
  • People should do what they enjoy
  • Always at least 2 developers
  • Rotate people in and out of projects

Everything you do is marketing

Open Source:
  • A part of their culture
  • Payback for all the open source they use
  • It Legitimizes what they do
  • Gives them crowd-sourcing support
  • They keep the quality of their open source high by using it internally before it goes out

Why did they get into products?:
  • Consulting scales with people - but they don't want lots of people.
  • Products scale without large groups of people

They focus on solving problems that they have and products they enjoy building

Checking under the Hood: A Guide to Rails Engines - Mike Perham

This was interesting talk where Mike went over Rails Engines, which are basically like a plugin that can have views and controllers.

Note: The real application code always wins over the engine in cases of name or file collision. You can use this to your advantage with a view you need to change.

There are no way to add migrations

To avoid model name collisions use name-spacing (Foo::User instead of User).

'helpers :all' will not load engine helpers

Static assets need to be copied over from the engine to the app

Dataflow: Declarative concurrency in Ruby - Larry Diehl

Dataflow is a ruby gem that handles some interesting concurrency problems in Ruby.

In your model:

class Foo
declare :my_var
def initialize
unify my_var, 1
unify my_var, 3 # kaboom

the second time you try to change my_var, it blows up.

local do | x, y |
Thread.new { unify x, "blah"}
Thread.new { unify y, "argh #{x}"}
y.should == "argh blah"

No mater how long the threads take a call to y will work in the above code.

There is a need_later method that will go off and do it's thing. If you try to call a method on the object returned by need_later it will either wait (if its not done) or return it (if the thread has finished).

FutureQueue, may come in at some point. With FutureQueue you can pop from it before you push to it.

Larry made inspect not block for debugging purposes.

Agile's Too Slow: Developing a Facebook App for the Obama Campaign - Andy Slocum

Andy worked on the Facebook application for the Obama campaign. In two months they build a Facebook app that could assist users in encouraging their friends to register and vote. There where only two people on the project and they came in with the common ideas of XP: continuous integration, weekly iterations, story estimates, developer testing, etc.

Except that all of the above was way too heavy for the Obama campaign's pace. They'd have an Iteration planning meeting on Monday and by the Tuesday it was out of date because so much had changed. Also Facebook apps don't really run very well outside of Facebook so they could only write tests around code that was completely isolated from the Facebook stuff. So they basically moved to a lean process with priorities set at the standup meeting every day. They also ditched the idea of continuous integration as there were only two people to integrate.

An interesting part of the presentation was about the lack of privacy in Facebook. Any Facebook app can get the birth date, state of residence, and name of any user and all their friends. So the Obama app could use existing voter registration databases to figure out if a user's friends were already registered.

They deployed the application multiple times a day. Their load testing was asking one of the stakeholders, who had over a thousand Facebook friends, to test out the new features.

The Ogre and the Wimp: Cleaver Influencing Tricks - Help the Most Reluctant Teams -- Anda Abramovici

This talk was about how to introduce agile practices to particularly stubborn developers. Anda was a consultant on project where she had a bunch of developers who didn't want to pair or use TDD. She conspired with an upper level manager known for her toughness to come in and play the Ogre while she played the wimp. She would join the team and pretend to be just as unhappy and resistant to TDD and Pairing as the rest, but then the Ogre would come in and demand that the team increase it's test coverage. Then she'd feign resistance while helping the developers respond to the 'crazy' demands of the Ogre.

Later they conspired to move a bunch of equipment into Anda's workstation so she had no place to sit. So she shared an station with another developer. Eventually they started pairing.

They also recommended using free drinks to help the wimp bond with her new team.

All this seemed a little dishonest to me and has a large chance of backfiring if the wimp was ever found out as an agile advocate. It did, however, work for them.

Slow and Brittle: Replacing End to End testing -- Arlo Belshee and James Shore

This was a workshop where we discussed the problems of End to End testing (they tend to be, uh, slow and brittle) and possible solutions. I had to leave to catch my flight to Austin (I'm on a plane to Lone Star Ruby Conf as I type this) before the end so I'm interested to hear what they came up with. One of the answers was the idea of giving up on trying to test all paths in an End to End test and focusing on unit tests and an abbreviated 'smoke test' suite that is forbidden to go above 5 minutes. There was quite a lot of passion in the room.

OK, I'm exhausted. Time to hit 'Publish Post' and relax for a bit as tomorrow will be my third conference in as many days.

This was the first ever Software Craftsmanship conference and it was put on by my company Obtiva and 8th Light (a company I have pretty strong ties to). It was a pretty big day for the Craftsmanship movement and our little companies.

Software Craftsmanship Manifesto is:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:
  • Not only working software, but also well-crafted software
  • Not only responding to change, but also steadily adding value
  • Not only individuals and interactions, but also a community of professionals
  • Not only customer collaboration, but also productive partnerships
That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

The idea is to build on the Agile Manifesto toward better software and the community that surrounds it.

Swimming Upstream, Sprouting Legs, and Running Free -- Ken Auer

This is by far the most provoking talk I've heard in awhile. At the beginning Ken announced that he wasn't going to be politically correct. And as the talk went on I kept wondering what that was going to be. Would he go after women drivers, Mexicans, president Obama...? I kept waiting for the other shoe to drop.

Ken had a fairly happy childhood where he desperately wanted to be a baseball player. But, alas, that dream doesn't often come true. But he was good at math so he played a lot of "Strat-O-Matic Baseball" which is a game where you use the stats of baseball players. He developed a series of algorithms so that he could beat all his friends. This, of course, lead to a career in computers.

The other theme in Ken's life is religion. This, apparently, is 'not politically correct' part of the talk. I gotta say that it's takes a lot of chutzpah to talk about religion at a software development conference. I have never heard somebody say "Do you accept Jesus Christ as your personal saviour?" at any conference before, but I have now.

Ken attended church all throughout childhood going there "whenever the doors were open." But he feels that he was sort of passively religious during that time. He didn't know much about the bible or question any of the church's practices.

In Ken's software life he had his eyes opened by the Object Oriented revolution when he attended the first ever OOPSLA in 1986. He and his company got into OO and Smalltalk very early on and produced a bunch of working software before anyone could tell them that Smalltalk wasn't for 'real' software. It's funny how often people succeed because they didn't know it was supposed to be hard.

Also, around this time, Ken started attending Bible study groups and thinking more about his work/life balance. He spent a few years ruminating about how to affect a change and eventually came up with the idea that he would start his own company "Role Model Software." Over the years Ken has:
  • Mentored a bunch of apprentices
  • Built a huge house where he lives, works, and teaches his children (he's a homeschooler)
  • Become an elder at his church
  • Created a lot of working software

Ken seems pretty happy with the current of his life. He's managed to combine a bunch of the formerly separate aspects of his life into one unified whole.

Late in Ken's presentation he ran out of time and had to skip past a bunch of slides (I think I saw Darwin in there somewhere) and wound up with a slide that said "I don't believe we came out of the mire. But we need to." Which I take to mean that he doesn't believe in Evolution but that he feels that our current software situation is a bit of a mess and needs to be changed.

Again, easily the most provoking conference presentation I've ever seen.

Self Eduction and the Craftsman - Michael Feathers

Michael's talk was mostly a list of things he thought that people who were self taught or apprenticed might not have learned (because they weren't in a formal Computer Science program).

Things you need to know about:
  • Big-O, Little-O, and Theta Notation
  • Covariance & Contravariance
  • Types
  • Objects are Closures
  • State Machines
  • Regular Expressions
  • Turning Machines
  • The Halting Problem - limits on verifiability
  • Worse is Better (just good enough) (less features is easier to debug)
  • Redundancy is not strength - "It's a weird industry where we are the things that introduce problems into a working system" "The same spec given to different teams tends to produce the same bugs"
  • Security on Sand ("On Trusting Trust") Security can only be so good
  • Location Transparency is a Myth
  • Objects are Clay
Books that you might not have read:
Structure and Interpretation of Computer Programs
"Designing Object Systems" Cook and Daniels (Syntropy)
"Graphs: Theory and Algorithms" Swamy (Graph Theory)
"Compilers" Aho, Sethi, Ullman (The Dragon Book)
Discrete Mathematics - Anderson
Theory of computation - Michael Sipser

Observations from an Old Warhorse - Fred George

This talk, by the highly engaging Fred George, was a series of completely unrelated observations from a guy who's done a lot of Agile and non-Agile projects.

What is considered a big application?
1970 - 10K Lines
1980 - 100K
1990 - 1M
2000 - 10M
2010 - 100M

But effort seems to rise and fall to build big applications because we keep getting advances in writing software and all advances have this in common: Simplify the problem. Get rid of duplication.

Discard to Make Languages more Robust:
Tektronics School of Objects: 'if' is suspicious 'else' is almost always wrong.

I've heard this 'If/Else' claim before but without any examples, it's hard to understand how to purge my code of all the 'Else's.

(Rails - TDD) == Productive VB
If application is less than a page of code would you..
- write tests?
- pair?

Fred doesn't write test or pair on micro projects.

Feedback => Quality
1. Frequent releases
2. iterations
3. Stand ups
4. Tasking Cycle 1-2 hours (all the way through a story in 1-2 hours? This guy is big into Lean.)
5. Pair Programming

Lean: Identify and Eliminate Waste
What are you making?
How do you make it faster

Story life cycle.
Finger charts are useful.

Iterations are dead
From scrum's couple of months
to xp's 2-3 weeks
to ThoughtWorks 1 week
to Daily (part of the stand up)

Fred uses a Kanban board to track stories in progress.

Developers pick up the most important thing next. If management wants to have a meeting -- let them.

Continuous Deployment

Holy Grail of Software Development: Short lead times

Right now on Fred's team: Over 50% of stories are deployed within 2 days of the story surfacing. Which reduces the need for branching.

Grand Unified Theory of Software Design -- Jim Weirich

This was an interesting attempt to find a unifying principle underlying all software principles (Don't Repeat Yourself, Single Responsibility, etc.). Sort of like how physicists are looking for a single underlying law to the four fundamental forces.

Jim thinks that using 'connascence' he can derive many of the principles. Connascence is defined by thefreedictionary.com as:
1. The common birth of two or more at the same tome; production of two or more together.
2. That which is born or produced with another.
3. The act of growing together.

For software connascence is when changing one piece of software requires a corresponding change in another place.

As the distance between the software increases we want to use weaker forms of Connascence

A weak form of connascence is connascence of name
def foo(bar)
bar + 1
if I change the name of 'bar,' I have to change the next line too. If I change the name of the function 'foo,' I'll have to change all the places that call the 'foo.' So, even within connascence of name there are levels.

Connascence of position is when order matters (worse than connascence of name):
def foo(a,b,c,d,e)

People calling this method have to remember the order of the arguments. A common solution in Ruby is to use a hash to move to a lower form of connascence (connascence of name):

def foo(options)

so you can call the method like so:
foo(:position => 54, :height => 10, :width => 20, :depth => 3, :solid => true)

A common connascence of meaning problem is magic numbers. If many places have to know that -999 means a bad response this is connascence of meaning.

Connascence of timing is race conditions

Connascence of Execution is when the order of the steps matters.

Unfortunately I wasn't able to get down all his examples of how Connascence is the common link for all software problems (and I think this is a work in progress) so hopefully Jim will write this up in more detail some day.

What if Bacteria Designed Computers? -- Ward Cunningham

Ward Cunningham is legend in Agile, XP, and computing in general so he can pretty much talk about what he wants and everyone will applaud at the end. Today he was talking about buying tiny IC chips, wiring them together, and getting them to communicate like cells. By doing this he was able to build completely new and seemingly complicated devices (such as a flag waving robot) simply by swapping some parts around. Was this a powerful metaphor for having a reusable tool set or just a guy talking about geeky stuff? He never came out and made it explicit. I enjoyed the talk none the less.

The Business of Craftsmanship - Kevin Taylor, Micah Martin, and Carl Erickson

The owners of three craftsmanship oriented shops got together and took questions from the audience. Carl Erickson founded Atomic Object in 2001 in Grand Rapids, MI. Kevin Taylor started Obtiva in 2005 and Micah Martin created 8th Light in 2006.

This discussion rather quickly became about how the Apprenticeship programs work at each company. At Atomic object it seems to be a summer thing for college students and it continues from summer to summer as long as it's working out. If it goes well, it leads to a hire. Obtiva brings in apprentices and the apprenticeship may continue for a year or two before they are moved out of the apprenticeship. Apprentices can be moved into billable work whenever they are ready which could be a matter of weeks or months but no more than 3 months (it's a paid position so the company can only afford to carry someone for so long). At 8th Light apprentices are assigned to one of the higher level consultants and are non-billable for 3 months. After a series of challenges they are either given another 3 months, promoted, or let go.

All three companies have experimented with different types of overseeing the apprentices and have generally found that someone needs to 'own' the mentor-ship of an apprentice otherwise, as Carl Erickson said, "You'd see two apprentices off in a corner working together" and that didn't work.

At that point I had to run off and give my "What's the Right Level of Testing?" talk at Agile 2009. Since the two conferences were held a city block apart, the commute wasn't too hard. The talk went pretty well, there were about 40 attendees but they mostly seemed kinda sleepy. 4 or 5 people were pretty engaged though and seemed to enjoy it. 90 minute presentations are the rule here at Agile so when you have a 45 minute talk two of them get squished together into a 90 minute slot with no time for transition. So to attend my talk someone would have to see the 45 minute talk before me and hang around, leave another talk mid-stream, or sprint from one 45 minute talk (which could be in another tower) to mine in zero seconds. So with these rationalizations firmly in place, I feel good about the turnout and how it was received.

Tomorrow I'll be able to see some of talks but I'll have to leave early to fly to Austin to present at Lone Star Ruby Conf.

"I Come to Bury Agile, Not to Praise It" -- Keynote by Dr. Alistair Cockburn

So this is one of those classic keynotes where the title has little to do with the content of the talk. I did enjoy the keynote, very much so, but only the first 10 minutes were devoted to Agile's 'Death.'

Alistair came out following a bagpiper playing "Amazing Grace" -- like a funeral. I gotta admit that it was a pretty nice entrance. Then he gave a modified version of "I came to bury Caesar, not to praise him" speech from Shakespeare's Julius Caesar (full text here: http://alistair.cockburn.us/I+come+to+bury+Agile%2c+not+to+praise+it). His point was that Agile started out as something for small, co-located, groups and was pretty rare. It is now very prominent and used in quite large organizations. So it has gone through a bunch of changes despite the fact that we call it by the same name. Not quite a 'death' but "Isn't it weird how we still call Agile the same thing even though it's changed a lot since 2000?" isn't a catchy title for a keynote.

Then he spent the next 70 minutes talking about the 4 pillars of Agile:
1. The finite co-operative game
Goals of the game:

  • Deliver the software
  • Setup the next game
Moves you can make:
  • Invent
  • Decide
  • Communicate
The situations almost never repeat

2. Craft
Pay attention to skills and to the medium

People learn in 3 stages:
  • Shu: learn a technique
  • Ha: Collect techniques
  • Ri: Invent/blend techniques
Beginners tend to get stuck in the 'Shu' box. Alistair claims he spends most of his time trying to kick people out of the 'Shu box.'

3. Lean processes
Aim for continuous flow
Watch your queues (where the bottlenecks are)

4. Knowledge Acquisition
If you integrate all the time (or release) you can have knowledge lead cost (spending on the project) then you can trim the tail of the project to deliver on time or extend to get a little bit better value. If you integrate late the options are: Deliver late or work overtime.

At one point he claimed that there are studies that show how expensive distance is to a company. 12 people not pairing costs 100,000 per year and goes up to $300,000 if they are on different floors. Taking a look at his slides, I think this fact was taken from the book "Managing the Flow of Technology," but I'm not sure.

Link to the slides.

Idea Factory - Brian Marick, David Carlton

This was an attempt to relate 3 ideas of how scientific ideas are adopted to Agile.

The "Trading Zones" idea is from a book by Peter Galison titled "Image and Logic: A Material Culture of Microphysics." The idea is to setup local areas where separate groups working on the same project, but do drastically different things, can get together and possibly form a common language.

Packages are a way of, well, packaging your ideas so that they are easy to assimilate and adopt.
Example: JUnit made it easy to do TDD. (That's kind of what I'm trying to do with metric_fu and code metrics).

Actor/Network theory is a study of "how does a fact become a fact?" A successful idea will, over time, go from:
Something that is cited conditional in publications. Ex. "Watson and Crick propose that DNA has a double helix structure"
Being cited without question. Ex. "Watson and Crick proved that DNA has a double helix structure"
Being assumed. "Given the double helix nature of DNA..."

XP: My Greatest Misses 2000-2009 - J. B. Rainsberger

This was another interesting talk by Rainsberger. He discussed his greatest failures as an XP/Agile coach/trainer. Almost all of his problems were caused by his failure to consider the people part of software. His ideas, processes, and plans may have been spot on in his own mind but they were often interpreted by others as challenges or insults or worse.

The breakthrough for him was when he finally started reading the works of Gerald M. Weinberg and Virginia Satir and learned about the human side of consulting. When J.B. speaks he thinks about how what he said will be interpreted. And when he hears something jarring or offensive he tries to figure out what an alternate and generous interpretation might be for the comment.

He wrote up an article about miscommunication entitled: Don't Let Miscommunication Spiral Out Of Control

Improving Obama Campaign Software by Learning from Users -- Paul Baker, Billy Belchev, and Zack Exley

Every 4 years the election software budget goes from 0 to 800 million. Which can be hard on the software. Paul Baker and Billy Belchev were hired to evaluate a bunch of software used by Obama volunteers during the campaign to track canvassing and phone banking efforts.

They did this in 3 ways:
1. Contextual inquires (interviews)
1-5 users per task
30-45 min per interview

2. Lightweight usability testing
1-3 user per task
15-25 min per session

3. Collecting artifacts
Taking pictures and video of the environment, people, and software interacting (or, in some cases, failing to interact)

Basically they went out into the field and talked to people as they used the software. Amazing how this simple strategy quickly (they spent 9 days in the field) finds huge problems with the software.

Example quote: "The way I would really do it? I'd write her name down and call her later." Instead of use the cumbersome tracking software.

Lots of offices used Google Docs to store information because an overly restrictive permission system wouldn't let key members see data and to store specific fields the software couldn't hold.

All the sticky notes on the wall, computer, and stuff on the whiteboards will tell you what the software isn't doing (or doing well)

They used a lot of video clips with people talking about how they worked around the bad parts of the software.

Pretty good day, all in all. Tomorrow I'll be attending the Software Craftsmanship Conference sponsored by my own company Obitva. Then I have rush back to Agile to give my talk "What's the Right Level of Testing?" at 4:45. Seeing the caliber of talks here I'm pretty proud and excited to be a presenter.

It's been 5 years since I attended the granddaddy of Agile conferences and I have to say that the first day was damn good. My notes my be a little rough, so I apologize in advance, but if I don't type and post them on the day I pretty much never will.

Workflow is Orthogonal to Schedule -- Mary Poppendieck

Mary started out with an example of on time development from 1929: The Empire State Building.

In September of 1929 they started cleaning the constructions site of previous buildings and by May 1st of 1931 the building was finished and open to the public. It was exactly on time and 18% under budget.

Cash flow was king: Every day of construction was another day before they could start getting their money back.

How did they do it? They focused on flow. They thought of the project as "A marching band going through the building and out the top."

Key success factors:

  • The owner, architect, and builder got along well and worked as a team.
  • They had a deeply experienced building team.
  • There was a lot of focus placed on the key constraint: Material Flow. 500 trucks a day but only arrived with materials for the building, but they only had a few days of storage on site so everything that arrived had to go up and onto the building.
  • Decoupled the work: The systems (windows, floors interiors) were designed to be independent
  • Cash flow thinking: Every day of delay coat $10,00 ($120,000 in today's dollars)
  • The schedule was not derived from the design. The design was put in place to meet the constraints of the schedule.

Mary used this as a shining example of Lean development in the pre-computer era. So how do you run a software project with the highest degree of efficiency possible?

  • Establish high level system goals (what do we really need).
  • Involve those who understand the details early in the process.
  • Use teamwork based on trust. Contract thinking increases costs 30-50%.
  • Reduce complexity wise wise decoupling
  • Understand and manage the constraint
  • Features can be big but dev stories must be small (1-3 days at most)

At this point she compared Kanban to Iterations. This article describes Kanbab better than I could do it justice: http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html

Schedules (are way different from flow)
1. If you have a level work flow you have both predictability and control without a schedule
2 Schedules based on experience are reliable
3. Schedules summed up from task breakdown are not.
- without experience, task break-down/sum up schedules are a hypothesis
- without slack, task breakdown/sum up schedules are deterministic and do not allow for normal variation
- attempts to remove normal variation from a system cause oscillation

Asking for feedback means you'll get it. You can only commit to 50-70% of what you want because you will get feedback that takes over the rest of the time.

Small batch size means you can get 80-90% utilization -- an iron law of math. Utilization above this range causes thrashing and wastes lots more time than it gives you.

Optimize Throughput, not utilization

She covered a lot of interesting stuff in her talk and I feel like I've not really captured the flow and force of her arguments. Mary is one of the best Agile speakers around and I recommend taking any opportunity to see her talk.

What Do Agile Coaches Do? -- Liz Sedley and Rachel Davies

This was a tutorial were the audience broke into groups and discussed Agile coaching. The presenters posited that there are 3 types of coaching:
  • Consultative - Trying to change process
  • Motivational - Encouragement
  • Education - Helping understanding

We looked at some common problems that Agile coaches face and discussed solutions. I thought the conversations I had were pretty interesting but I would have liked to hear more from Liz Sedley and Rachel Davies about there experiences in Agile coaching as they had just written a book on the subject.

Integration Tests are a Scam -- J.B. Rainsberger

This was a pretty awesome talk and I totally owe my attendance to Colin Harris, as he recommended a blog post to me about just this topic by just this author.

J.B. defines integrations tests as any tests that test more than one class.

Why is this bad? Well he spent 90 minutes making a very solid case, but let me try to sum up:

First he started off by saying that he's talking about developer tests and not customer tests. In other words, he cares about tests you run before you check in not huge regression suites used by Q.A.

1. Integration tests are slow. Slow tests will eventually become ignored tests.

2. Testing a group of, say, 3 interacting objects creates a ridiculous amount of tests you need to write. If there are 5 paths through the main object under test, but the methods it uses in another object have 3 and 10 paths respectively then you should write 3 X 5 X 10 = 150 tests to exhaustively try out all the paths. However, if you test each object in isolation then you need to write 3 + 5 + 10 = 18 tests to get the same coverage of paths. You are far more likely to write 18 tests, then 150.

The way J.B. does this is to create interfaces for all his objects that have complex behavior (He likes Domain Driven Design so he tends to refer to these objects as 'Services') and then use 'Doubles' (mocks and stubs) to eliminate the need to use the real objects. Now when you use doubles, you need to make sure that the thing you're mocking on one end really does return what you think it does on the other.

When I asked him about having setups with lots and lots of mocks he claimed that if you're having trouble mocking things in your tests you probably have problems with your models. Sigh. He's probably right. For instance, if you need to have a mock that returns a mock which returns a mock you probably have an object that is breaking your layered design.

Of course when I test in Rails I have to do this all the time. Part of the reason is that good design is way hard and I'm still learning. But the other is that Rails has ActiveRecord which is an entity that is responsible for it's own persistence and that is something that J.B. and a lot of people I respect look down upon.

Rainsberger gave me a lot of things to think about which is pretty much the highest praise I can give a session.

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

This is the last post of the series.

Wednesday 8-18-04

Last day of XPAU and I'm pretty burnt. I'm typing this from the airport in Calgary where they inform me that they are running an hour behind. This is bad because my connecting flight in Las Vegas is an hour and 20 minutes after I land. So I'll have 20 minutes to catch my flight, assuming they can keep to their prediction. I don't have high hopes. I might have to miss work tomorrow.

Which would kinda suck because I need to figure out what's going on this year. With Rylander and Miller gone, I'm going to need some time to plan with the new guys.

Today I slept in and skipped the morning stuff. Then I hung out in the FitFest room, writing code, and chatting with Micah, David, and Paul. Ken stopped by later and we said our goodbyes. I hope I see him sometime soon. The last address was on the history of the waterfall and agile. The presenter did a good job showing how the originator of waterfall was actually arguing against waterfall and for iterative development. And how iterative development actually has been going for 30-40 years. But it has been marginalized and contained. The hope is that the Agile movement can kill the waterfall once and for all. But, who knows, 40 years from now we might be just another slide in a presentation.

Me and the OM crew went out for one last bite after the conference wrapped. Hard to say goodbye to those guys. Paul and David live in the city so there's a chance I'll still see them, but Micah's way, way out in the 'burbs so that'll be tough. Nothing a little effort can't overcome.

Is this my last entry? It just might be, the apprenticeship is over. Thanks for reading.

I was pretty exhausted and down when I wrote those words. Setting up for a year of teaching takes a lot of work and I had done nothing. I was facing no sleep followed by a mad scramble to get ready for new students.

So what did happen? At this point I had already turned in my code submission to ThoughtWorks and when they didn't get back to me after a few weeks I thought it was all over. What I didn't know is that ThoughtWorks is known in the field for having a very long interview process. I had already talked to 2 different people and submitted code so I thought they had enough to make a decision. Sometime near the middle of September they called me in for a day of tests and interviewing. I got job a week or so after that and started in early October. Which meant that I had to leave school with the year just started, but my high school was cool about it and didn't fine me or suspend my license (which they had the legal right to do).

I guess I could spend some time wishing I had continued this blog while working at ThoughtWorks, but instead I'm just going to be pleased that I managed to document so much of an important time in my life. There were days when I didn't really feel like blogging after a day of getting my brain crushed by code but I'm glad I stuck with it as long as I did.

I still see Micah, David, and Paul fairly often, btw.

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

Tuesday 8-17-04

Got up late, hustled downstairs to get some breakfast, only too discover that I didn't care much for either of the Keynotes that morning. Some Microsoft guy was gonna talk about Visual Studio and M.S. agility. Hmm. I had already chatted with the guys at the Microsoft booth about the new Visual Studio and here's the scoop: The will be unit testing integrated, but it will be Microsoft's own version. They did say that V.S. will let other products add on and integrate on their own -- but they couldn't show me that. I will be interested to see if they will allow Nunit to integrate as seamlessly as IntelliJ and Eclipse do. So I wasn't real interested in that. The other talk was about the future of C++. I'm still trying to avoid C++ until I have to acknowledge its presence, so I avoided that talk and hung out in the FitFest room. And had a good time writing some tests/code/test/code with a Swedish? guy named Carsten. When you carry a torch you can see the Wumpus for many rooms away, but he can see you. He will wake from his slumber and chase you until you are gone from his line of sight. The big problem was that 'moveWumpus' was private and only accessed from a method that had to do with arrows. So it took us a while to figure out why this was -- the Wumpus wakes up when you shoot an arrow and miss. He then moves to a random room. So we stumbled around with various means of integrating this, but eventually ended up following the already established pattern of having a Boolean variable that is checked by the 'evaluate' function. So we checked 'hasTorch' in the evaluate method and then wrote an algorithm that looked along the lines of sight. It worked, but it is es muy crappisimo. First the line of sight business is duplicated in the shoot arrow function so we really should pull it out and abstract it. And the WumpusGame class has way too much going on in it. And the commands really suck (the are methods that shoot arrows, and magic arrows, but no way to access those command while playing the game). Unfortunately, both Carsten and I had to go before we could do this refactoring.

I talked to Micah about this latter and he had an interesting point. Even though the code was ugly, we had added way more functionality than last year (where the code size tripled and no new acceptance tests passed). And also the ugly code emphasized the need for sharing knowledge of the system by pairing and switching pairs. Carsten and I sat down and had no idea how anything worked. In order to add some functionality we had to poke around the code for 45 minutes. And then, because we had to leave and couldn't work with other people, our knowledge of what needs to be fixed and how to fix it walked out the door with us. When we came back later, things had sufficiently changed so that we couldn't be sure that our refactoring was valid anymore.

Later I sat in on a panel called 'Is XP relevant?' Which was mostly an excuse to start a fight. Bob started one by claiming that XP was irrelevant. Lots of people objected to the name 'Extreme Programming' because it scares people and others objected to getting rid of it because they think the agile is too watered down a concept too support. There was the same general disagreement about how much it is our job as developers to be polite and sell XP or Agile or whatever. I don't like selling, but I don't want to code in a waterfall company.

The big end of the Conference banquette was probably more loud music and dancing than most programmers are comfortable with, so when that started up most heading for the door. Before we cleared the room, there was the announcement of the next year's conference name: 'Agile United' I guess XP is too scary to have in the title. The counter argument is that Scrum and RUP aren't in the title so why should XP be privileged? Bob has worries that somebody might start up a conference with XPish title and all the unification we're seeking will be lost.

Bob's after dinner talk had to do with astronomy -- surprise! He talked about how Kepler had a beautiful theory regarding the motion of the planets, but when he looked at the data he found his theory was wrong. So Kepler adapted. His idea was that XP is a beautiful idea, but we must keep looking at the data to weed out the bad parts.

For those who didn't want to dance, there was charity poker. 10 bucks Canadian gets you $10,000 funny moneys. Then you could play blackjack or poker and for every $10,000 you turned in you go a raffle ticket. I ended up playing pretty well, got lots of raffle tickets, then Micah's mom gave me her raffle tickets so I won two books. One was a Microsoft ASP book which I gave away, the other was 'User Stories Applied' by Mike Cohn. I saw mike Cohen speak on the Managing Agile Projects panel, and he seemed pretty cool (and like he might be able to break me in two) so I'm gonna read it. Not just because I fear for my safety, but also because a number of people said it was good stuff.

Bob is famous for sticking astronomy into any and all talks he gives. At this year's Rails Conf he didn't even try to integrate it into the talk. 10 minutes of entertaining stuff about the age of the solar system and then a bit about Smalltalk.

At some point this evening I talked to a bunch of people from ThoughtWorks, including my recruiter Sonia. I had met her though a reader of this here blog a week or 2 back but I hadn't mentioned it because nothing was for sure. The ThoughtWorks people seemed pretty cool and everyone at Object Mentor said it was a good place to work. I think at some point this evening I made my pitch to Micah for a job at Object Mentor saying that I could be the IT guy for OM while I learned more and could slowly work my way into real work. Ultimately they declined my offer but were very nice about it and said that they just were not hiring at that moment but maybe in 6 months or so we could talk again. I was a bit crushed as I thought working at ThoughtWorks was a bit of a long shot. I had done a few other interviews and most companies were pretty put off by my lack of experience. So with XPAU just about over and my apprenticeship done it was looking like I'd have to teach another year of high school physics. Maybe this was all just a fun/stressful summer adventure.

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

Sunday 8-15-04

Every time I think I understand FitNesse I'm wrong. After a day of using it for Acceptance Testing I know a lot more about it, but I'm going to assume there's more. But this is jumping to the end, I'll back up.

At the beginning of 'XP for a Day' Micah and James (the teachers) split the groups up and we started the planning game. James, the customer, had a bunch of stories written on 3X5 cards that he wanted implemented in the game. For example: One was a magic arrow that you could fire that would turn if it hit a wall (you specify the direction it will turn when you fire it). Another was a GUI for the game. And another was shooting regular arrows that would kill the Wumpus if they passed through the room he was in. Another was a randomly generated map. And so on. After James introduced the cards the time had come to assign numbers to them. This is one of the tricker parts for the first time XPer. The numbers are unit-less and do not correspond to a set amount of time. But the are a measure of how much time the task will take. Huh? Lemme 'splain: Take all the cards and arrange them from easy to hard. Some are the same level so they will be a pile of easy, a pile of hard and a few piles in between. Now let's call the features in the easy pile ones. What does one means? It doesn't. But now we have a reference. All the other cards are defined in terms of the easiest ones. Is this task two times more difficult or three times more difficult than the simple ones? Unfortunately, since most programmers have a background of spending lots of time on design we spent too much time arguing over the points on each card. But it was a good learning experience. Then we guessed how many point we thought we could do in one iteration (1.5 hours in this mini-XP version). My group had no idea, but everybody else said 4 and we went along with the crowd. How many did we finish? 1 point. And here's where I take a bit of issue with the class. Learning FitNesse is a day in and of itself. None of us were that familiar with it (I had used it in the TDD class I took, but some problems still were beyond me) and so we spent most of our iteration trying to figure out how to get the acceptance tests to work. Leaving precious little time to code.

Which is everybody's biggest fear about TDD -- that the test will slow you down. And I think one iteration will always be sacrificed to figuring out FitNesse or Junit (which we used too, but most were familiar with it) or whatever. The second iteration went much better. Now that we knew how to set up fixtures and get them to work, we were able to hit our target velocity much better. My personal feeling is that this needed to be two days if FitNesse will be new to most of the student (as I suspect it will be). If it has to be one day, then maybe unit test will have to be enough. Regardless, I learned a bunch and felt the class was a qualified success.

The problem with having students work on real things is that often they get hung up on something that shouldn't be the focus of the class. I had this one week long physics project where the students would plan how to launch a spaceship and have it reach Mars. The first step is drawing a scale model of the solar system out to Mars. Most of the kids spent the better part of the first day just trying to figure out a scale so you can fit all the orbits on the paper. I had foolishly assumed that such a task would take a few minutes because it was easy for me.

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

Saturday 8-14-04

Travel day today. Flew to Phoenix, AZ (4 hours) and then to Calgary (3 hours) plus 1 hour for lateness and layovers is an 8 hour trip that should have taken 3 (Chi to Cal). And there was a fun little dash from gate A11 to B7 (which are much farther apart than you might guess using your knowledge of the alphabet) because my first flight landed late.

Check in at the Hyatt Regency was easy and gorgeous. The conference space is really nice too. Micah, Paul, David, James, Justin (Micah's younger brother), Bob, and I spent some of Saturday night setting up the 'XP for a Day' Tutorial space. There's gonna be 3 teams of 4 (2 pairs each) working on 'Hunt the Wumpus.' So we needed to link all the computers up, set up FitNesse, and get CVS working. James has been nice enough to let me sit in on the tutorial, so I'm excited to see how much functionality we can add to 'Hunt the Wumpus.' Which is an old text-based game from the late 70s early 80s. You walk around a cave trying to shoot the Wumpus with an arrow. But if you go into to room with the Wumpus, he eats you. And there's pits to kill you and bats to randomly transport you. Some functionality has already been done, so we're going keep the project going.

Later we ate at the James Joyce bar and Bob talked about almost killing himself with carbon tetra chloride, high voltage transformers, and all sorts of other experiments he did when a child. I told some physics teacher stories. Ron Jeffries talked about the perils of rainwater management. We tried to get David to do some magic tricks (he was a magician in another life) but he politely declined.

Yeah, it was a pretty heady atmosphere at the eXtreme Programing Agile United conference. Bob knows everyone in the community so hanging out with him means you get to make a fool of yourself in front of some heavyweights. Ron Jeffries was tons of fun chat with -- that guy has some stories to tell and man can he tell em'.

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

Friday 8-13-04

Last day in Gurnee. The Object Mentors decided that pizza wasn't enough for my birthday, so they took me out to one of those fancy Japanese steakhouses. Ya know, I've never actually been to one of those knife-flying, death-defying, make-it-all-on-a-grill-while-you-watch restaurants. A good time was had by all.

It's been a good summer. I've learned tons about class design principles, patterns, pair programming, test driven design, and a whole bunch of intangibles. Without a doubt the coolest thing about working at OM was being able to lean over and ask David, or Micah, or Paul, or James, or -- Look, everybody sitting next to me had great ideas about programming and, as cool as all their classes are, working with great programmers is a much better way to learn.

Speaking of Object Mentor's classes, I've been meaning offer up my critique -- from a teacher's point of view. What I like, and what most non-teachers usually screw up, is the commitment to lab work. If there's a lot of material to cover you can seem to cover it quicker with more lecture and less lab, but that's a big mistake. Just because you throw a slide up on the screen and yap about it does not mean that anybody had any idea what's going on. In my experience, 40-50% of the class are thinking about something besides what I'm talking about at any given moment. So it's crucial to have the students work out the presented ideas in the lab. First, because it forces them to talk to each other and fill in the gaps where somebody was distracted by thoughts of girls, or candy, or shiny objects. And second, because if a student knows they're probably going to put the presented ideas into action they pay just a bit closer attention. The lab, in this case, is writing some code. Because OM is XP, they do all code writing in pairs. Which is very cool. One person can get stuck, but two can tackle ideas that would confound either individually. So the classes don't bog down when a few people are way behind and others have zoomed ahead. The groups tend to keep everybody moving along at the same pace (well not exactly, but it's much better). Which is probably a good argument for pair programming in the non-classroom: Nobody gets lost. I tell ya, I miss it when I have to work by myself. There's nobody there to keep me from doing something stupid so I waste lots of time running down a blind alley when a pair would look over my shoulder and say 'What the hell are you doing that for?'

Well I gotta pack for XPAU -- next post will be from Canada!

There are many times in life where you can go faster short term but you have to pay more on the back end. Sometimes it's worth it (startups coming to mind), but I worry that once you've compromised your ideals once it's hard to know where to stop.

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

Thursday 8-12-04

My Birthday today and the guys at OM were kind enough to buy me some pizza. Later on tonight I'm going to have a quiet little get-together at my favorite restaurant: Club Lucky.

Tomorrow is my last day at Object Mentor's Gurnee location. Saturday I'll be heading up to Canada and XPAU. Paul (the other OM apprentice) and I will be sharing a room at the Hyatt Regency. But here's the fun part: The last day of XPAU is Wednesday and my job as high school physics teacher starts back up on Thursday. So I'll be catching an 8:30pm flight from Calgary on Wednesday that arrives in Chicago (via Las Vegas) at 5am Thursday morning. Then it's a cab ride to work and meetings that start at 7:30am. Let's hope some sleep happens on the plane.

I'm pretty excited about XPAU, although I don't know what I'll be doing exactly. Basically Paul and I are Micah's goon squad and any person or technology that gets in his way will be dealt with shortly. However, Lance mentioned that he might also need some help with a project or two he's working on so I'll probably be pretty busy. In between duties for OM I'll be attending as many non-tutorials as possible. And trying to network (shudder).

My good friend Ken Hlebek (we went to high school together, fer cryin' out loud) will be attending and presenting. Something called 'Being Extreme with Eclipse.' Ken is the guy who was kind enough to introduce me to Object Mentor and, since he lives in Oakland, CA., I don't get to see him that often. Even when he does manage to get back to the Chicago area, he's inundated by visits from and to family (big, big, big family) so I still don't see him. Should be fun to catch up.

Weird how this all started: I get frustrated with teaching so I call an old high school friend and he puts me in contact with a guy he's met once or twice. How this all leads to a new career seems improbably at best. But it does prove a point I've been trying to make about private schools forever: You're not paying for a better education, you're paying for the friends and connections your kid will make at the pricey school. Most people are shocked to learn that private school teachers make much less than their public school counterparts. Even at high schools that cost 30K per year. Almost all of them leave as soon as they can for a public school. So why doesn't that experience and talent turn a private school into a terrible place? Well, 2 big reasons: First, people who spend 30K per year on education are generally smart, have raised their kids to value education, and care about what happens in the school they are paying so much for. And second, if you go to school with the children of such parents you will have connections to important people for the rest of your life and they will pressure you to do better in school. As a teacher, I've seen the same kid do well in a class of students who cared about school and then do terrible in a class that was indifferent. We all want to believe that we're beautiful snowflakes of individuality but the truth is that the people around you influence your progress way more than we'd like to believe. I had a friend whom I could call to help me out and that's how this all started. Now it's true that I still had to do the work when I got the opportunity but without that opportunity I would have probably had to face years of night classes to get a degree in CS. And faced with that colossal amount of work with no certain outcome there's a pretty good chance I would have just started showing more movies and phoning it in as a teacher.

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

Wednesday 8-11-04

I successfully broke the connection between the ChessBoard and the Pawn and the King. Pawn has its own PawnChessBoardIntereface and the king has KingChessBoardInterface. Each of these interfaces are pretty thin, so I'm back in a more comfortable place, design wise. I've also figured out a way to keep the rest of the pieces from needing to know about the ChessBoard. Instead of creating a FindAllLegalMoves method for each piece object, I'm going to look at the type of check the king is in. The king can be attacked straight on, diagonally, or it's a knight attack. If it's a Knight attack, this particular attack can't be blocked so I don't have to worry about trying. With diagonal or straight attacks I can find the squares between the king and the attack and then check to see if any of the king's men can move to one of those squares with my, already created, isItALegalMove method. But I still have to create a method to find those squares between the threat and threatened.

David left his laptop power adaptor at home, so he mentioned a trip to CDW to get a spare. Paul, Micah, and I immediately perked up and jumped on that bandwagon. Micah's wife called a little on and I overhead this little snippet of conversation: "Well I've already got lunch plans at, uhh, CDW." We are nerds.

David is working on dot Net (he's to be Object Mentor's dot Net expert) Asp now. Asp is a scripting language, like PHP, but it's Microsoft's baby. Visual Studio has this Asp GUI (Graphical User Interface) creation tool which is WYSIWYG (What You See Is What You Get). But, as with most WYSIWYG stuff, you only sorta get what you saw in the tool. The idea sounds pretty cool: by dragging and dropping you can create a web-based GUI in a few minutes. And what it mostly does for you is give you a good start -- there's a bunch of manual code editing after the tool finishes. So David is messing around with it and he keeps checking the changes he's made in Internet Explorer. Then he decides to check the results in Mozilla (an alternate browser): Guess what he sees?

Nothing. Absolutely nothing. And the stuff he's asking Mozzila to do is totally stuff Mozilla can do (little boxes where you can type in data: A web form), but Microsoft has rigged it so that its product won't work with competing browsers. Micah tried to open up the page with Safari, but still no go. He thinks there's a way to get it to work on other browsers, but the point is, that by default and design, Asp has way decreased compatibility on non Microsoft products. Not cool, man.

As I was new to computing this willful disregard for other browsers was shocking to me. Now I just sort of accept it. Many of my readers probably develop web sites and know this, but I would estimate that supporting IE6 and IE7's non standard behavior eats up 10-20% of any development team's capacity on average. There may be weeks where you are only burning 5% on IE but then some huge hairy IE6 bug will come rolling in and you'll lose a week of a developer's time. Microsoft will tell you that if their browsers strictly interpreted html, most of the internet would be broken. They're probably right: There are a lot of old webpages out there that have some busted html that only works in IE. But supporting them means making crazy problems for people who want to follow the spec.

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

Tuesday 8-10-04

Well, I got the king's weirdo move logic straightened out. And the pawn's. But now I'm looking at my ChessBoard class and I'm unhappy. ChessBoard does a lot stuff and I'm beginning to suspect that all the chess pieces are going to have to know about it. Why, you ask? Lemme tell ya: In order to figure out if there is a checkmate I have to first figure out if the king is in danger. No problem: did it already. But checkmate means that the king not only is in danger but that there is no way to get it out of danger on the next move. One way to get out of check would be to move the king. So I need a findAllLegalMoves method in the king class. But to find all the legal moves, the king will have to know what pieces are on the board. Another way to get out of check is to take the piece that is threatening the king. I got that working earlier today. But the last way to get out of check is the killer. One of the king's men can shield the king by getting between it and the threat. So now I need to look at all the king's men and see if they can move into a blocking space. Of course, this means that all the piece objects need a findAllLegalMoves method and to do that they need to know about the board.

A UML diagram of my chess program would now have lots and lots of arrows heading towards the ChessBoard class. Which is terrible design. A small change in the ChessBoard would now mean that I have to change all of the chess pieces. How to break up this dependency nightmare? More interfaces acting as firewalls between my objects. Micah suggested I need to look at which methods each piece uses from the ChessBoard and create a different interface for each. So the king and pawn might each have their own interface with the ChessBoard, but the rest of the pieces would have a different and thinner interface (less methods). That's a pretty big bit of refactoring so I better have at it.

Yeah. The chessboard stuff again. I find it kind of sweet that distant-past-Jake would spend all this time trying to arrange the dependencies so as to make the classes loosely coupled. But it's also kinda ridiculous. Maybe a game like Go would have been a better candidate as its pieces don't need to know too much but Chess, with it's complicated rules and numerous corner cases, is very hard to tackle. Chess is like a business that's been running for a few hundred years -- any interesting problem is some sort of crazy exception to the general rules. So it was a good portent of things to come but a rather frustrating last project at Object Mentor.

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

Monday 8-9-04

XPAU is only a week away and most of the things that need to be shipped have been shipped. So Monday was the calm before the storm. Micah had a hundred or so neglected emails to answer and some odds-and-end work to do. David and Paul were pairing on the dot Net FitNesse project (making FitNesse work with C#). And I have been asked (dared) to write a chess program by Micah.

Before I get into the intricate parts of chess software, I should mention David's correction of my previous post. On the subject of acceptance testing vs. unit testing, he says that it's important to point out that the customer owns the ATs and developers own the UTs. A developer can have loads of passing UTs, but it's the ATs that the customer ultimately cares about.

On the subject of Chess, I'm finding that just getting the computer to moderate a game between two humans is a more interesting problem than I thought. The main culprits are the pawn and the king. Here's a list of king behavior the computer must enforce: kings can move one square in any direction (including diagonals), they cannot move into check (a square that is threatened by an opposing piece), they can castle ( king side castle: move two square to the right and have the king side rook move two square to the left. Queen side castle: king moves two squares to the left and the queen side rook ends up on its immediate right.) but only if the king hasn't moved yet, the rook hasn't moved yet, there are no pieces in the way, the king isn't castling out of check, or through a space that would be check, or into check. A little bit conditional, eh? I've got all that programming done except for the moving the rook part. In my design, pieces can tell the board object if a given move is a legal move and then the board can use that information to decide whether to move the piece. The problem is that if the king castles, I have to have some way of telling the rook to move. I could program that into the board object, but then some of the king's logic is stored in the board object. This is very bad programming form. Latter on if I, or somebody else, wants to create some sort of chess variant where the king moves differently this person won't think to look for part of the information about the king in the board object. So if they try to change how castling works, the board will keep trying to move the rook and that could cause all sorts of hard to find bugs. And I would have to go sit in the bad programmer corner. I'm thinking about creating a 'move' command that can be issued to the pieces which, in most cases, would do nothing but in the case of the king and the pawn (which can turn into another piece if it reaches the back rank and has this weird way of taking another pawn without landing on its square called 'en passan') would do some additional things. What bugs me about this is first that it's dummy command for most of the pieces and that it doesn't really do what it says. 'Move' won't make the pieces move (the board takes care of that), it'll just get them to perform the actions of certain special moves. I need a better name.

Also there's the problem of checkmate. Check isn't so bad: I wrote an algorithm that looks at all the opposing pieces to see if they threaten a given square. Now checkmate might just seem like looking at all the possible moves of the king and seeing if they also put him in check, but it's a little more tricky than that. There's two other ways to get out of check besides moving out of the way: you can take the piece that is threatening your king, or you may move one of your pieces in front of the king to protect him. Both of which are interesting programming challenges.

Yes the Acceptance Tests should be owned by the customer. However, the developer often writes the Acceptance Tests because while the customer technically owns them he or she doesn't have the technical ability to make sure the tests do what the customer wants. This can lead to trouble if, for example, the customer wants to make sure a user can be created, logged in, change their profile, and logout. A developer writing that test might be tempted to just go right at the database to create a user (which really doesn't click through the app the way a customer would) and while the test would appear to be testing sign-up that page could be busted without the test failing. Getting a good Acceptance Test framework up and running, maintaining it, and making sure it tests what you care about is a daunting task and takes way more effort (and hardware) than most clients realize. The out of the box solutions that record clicks are either inflexible (you can't do loops or have variables or assert what you want), proprietary, slow, or (usually) all three. And custom solutions take time and precious developer resources. In short, automated acceptance testing is hard and needs a fair amount of resources.

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

Friday 8-6-04

Last day of the TDD and refactoring class today. We started with an intro to FitNesse, which is acceptance testing. The basic idea is that while unit tests are concerned with the inner workings of the classes and methods, acceptance testing is after more global behavior. An acceptance test tends to simulate the actual operation of the program. What you do is enter some data in a table that the user might enter. Now this table is in a wiki which is being served by FitNesse which may be running locally or on the company server. Then, when you push the button (on the wiki page) that sez 'Test,' FitNesse parses the wiki text and feeds the data from the table into your program. And then it checks the output against the table you created (on the wiki) with the expected output.

Which sounds a lot like a unit test -- just applied to a larger scale. And it mostly is, but with the added benefit that it's easier to write a test in a wiki than to learn java, or C#, or whatever. That means that the customer can write the acceptance tests and you can gets busy making them pass. Which is pretty cool.

The tick of Fitness is that you have to write a bunch of interface code between your natural language wiki tests and your code -- In that way it's kind of like cucumber. But anyone wishing to write Fitness/Cucumber tests has to learn to think a bit like a programmer because you can't write just any sentence and have the magic computer turn it into a test. We programmers often forget how hard our job is until we see non-coders attempt to do what we do every day. Often a team will try to adopt an acceptance testing framework because the tests look so easy to write but that is deceptive -- computers can't really read natural language yet and so writing acceptance tests as a non programmer can be frustrating because the cucumber or selenium or fitnesse or whatever tests look like sentences but a slight deviation from the form produces a cryptic error message. Ultimately I think they are worthwhile but you have to have a serious commitment from the people writing the tests to learn how write the tests.

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

Thursday 8-5-04

Well, knowing more about mocking objects would have helped a lot when I was writing my TDD Tic Tac Toe. Mocking Objects was, of course, one of the subjects of today's class. The whole day was devoted to TDD (the first day we were refactoring existing sample code) but I was pretty familiar with most of it except for the mock object pattern. Which seems like a big part and just goes to show that sometimes it's nice to have someone explain something to you even though you think you already understand it.

I'm working with a possible future intern: Matt. He's at DePaul and might be helping OM out in the fall (he has to work around his class schedule). Matt's been taking a bunch of non-computer classes this summer so he's a little rusty in the programming department. And he keeps wanting to write code without tests. However, I remember my first day at OM when I couldn't even get a simple bowling score program to work (yes, they try that one out on everyone). It's hard pairing with somebody who knows a lot more than you. Can be intimidating.

Five years down the line I'm still learning something about testing every day. I'm giving a talk entitled "What's the Right Level of Testing?" at Agile 2009 and Lone Star Ruby Conf -- in it I discuss the difficulties of balancing testing, team moral, velocity, assurance, and code quality. After looking over my slides I have to say that most of the teams I've been on have gotten it wrong more often than right. Which is all the more interesting because I've been working at the test-friendly ThoughtWorks and Obtiva. Testing is hard (but seems deceptively simple) and it can easily be over or under done.

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

Wednesday 8-4-04

Good news! With Jet Brains' 'Resharper' plug-in installed, Visual Studio is way more fun. Not as cool as IntelliJ, but it's getting there. As you might have guessed, the TDD and Refactoring class is being taught in C#. The first day was weird for me: I realized that a few months ago I would have been way overwhelmed but now I was following along with ease. I wasn't some sort of huge revelation, it's just that while James was writing a bunch of UML on the board I not only didn't have that sinking feeling UML used to inspire but I knew what pattern he was going for before he finished. Cool. The course is shaping up like this: Basic refactoring and Unit tests today, tomorrow should be test-first programming with refactoring (always with refactoring), and I suspect we will get into FitNesse late tomorrow or Friday.

A few minutes ago I finished up my TDD re-write of Tic Tac Toe and I'm including a zipped version of the source code here (tests are included, of course) [Future Jake note: the files can be found on Github at http://github.com/jscruggs/tic-tac-toe/tree/master in the third_pass_tdd directory]. Feel free to open it up, run the tests, and give me some feedback. It's a text-based game so don't expect a gui or anything fancy. I use a minimax algorithm to make the computer choose the best move. If you want to know more about my history with the Tic Tac Toe program, you should look at my may 2004 post.

How do I feel about writing TTT test-first verses without-a-net? I gotta say that the tests make everything more sane. With TDD, I could focus on one problem at a time without having to be driven crazy by weird bugs and mountains of suspect code. During my first non-test version of minimax I had this bug where when I asked the computer to move it filled in all 9 of the spaces. I spent days staring at code before I realized that I was passing a reference to the board instead of a value (so the board got changed as the computer tried checked of the possible moves). Of course I didn't find this bug until I had written enough code to make it run, so I was stuck looking at everything. When I wrote the minimax test-first, I focused on just the minimax method and the test. That's it ' any problems had to be somewhere in those lines of code. Which made it lots easier.

Now you may object that having written TTT once, it was easier to write it a second time. Yes, but when I re-wrote TTT in Python, without tests, I still had tons of problems with bugs (see blog entries 6-14-04 through 6-17-04).

Once again I have posted my early bad code to github so you can see it in all its splendor. And that action gets at one of the reasons I'm re-visiting these posts: To point out that everyone came from somewhere. When I was getting started in teaching and programing I often made the mistake of lionizing those above me (without even thinking about it) instead of realizing that they were just people like me who hard worked hard to get better.

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

Tuesday 8-3-04

Other than a little bit of time spent with Micah explaining Word Press to Bob, I was able to code all day. Whoo! Some hints from Micah yesterday and a lot of trial and error today led me to finally get the hang of testing methods that rely on user input from the keyboard. When the program is really running, I pass in a regular old keyboard InputStream (System.in) to my userInput method. However, in a test, I can load up a ByteArrayInputStream with all the values I want entered (separated by newlines, of course) and then every time a function I'm testing calls for a user input it gets my preset values instead. Which is pretty darn cool.

Of course this took a large chunk of the day to get it working exactly how I want. Java IO can be a wee bit tricky. The rest of my time was spent applying the finishing touches to my long-neglected TDD Tic Tac Toe game. Should be ready for prime-time tomorrow.

Speaking of tomorrow, I'll be taking a class with James Grenning: Test Driven Design and Refactoring. Unit testing has been interesting, but I'm itching to see how FitNesse extends things. Since the paying customers want the class in C#, there's a good chance that I'll revisiting Microsoft Visual Studio. We gotta get Jet Brains' add-on installed soon because life is unpleasant without refactoring tools

When I applied to ThoughtWorks I used the trick I learned above in my coding submission to test input from the command line. Later on when I got hired I asked to see what people said about my code and one of the comments was "Some of the things he tested would never fail." First of all -- the anonymous reviewer was right. One can reasonably assume that core Java IO will work and so it doesn't have to be tested in your application. But second -- it was pretty cool to see that I had tested way more than a ThoughtWorker thought was necessary.

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

Monday 8-2-04

Word Press has been successfully installed on the Object Mentor servers and 'ButUncleBob.com' should be available for blogging in a few days. So head on over there sometime soon and pick a fight with Bob Martin about some XP practice or other.

The install, as usual, was a bit of a problem until we realized that since PHP and MySQL were installed separately, we had to run a program to make them talk to each other. Said program was downloaded, installed, and then everything went smoothly. Nice.

Micah has now officially charged me with making a chess program to compete with his creation. Baby steps, Micah. First I gotta get it to let two humans play each other. After some discussion I've given up on my 'special moves class' because it's way more of a maintenance nightmare then the problem it's supposed to solve (letting ChessPieces know about the ChessBoard). I also want to finish my TDD version of Tic Tac Toe. The Land of Linux was fun to visit, but it's good to be back writing some tests and makin' 'em pass.

Yeah, I kinda stayed away from Linux for awhile after that first experience. It's all summed up here in a nice and cute sorta way but there was a few weeks there of coming in every day and feeling like my operating system was out to get me. I literally knew nothing about using 'Nix OS so every problem was hampered by the fact that even the simplest of things (like using ps and grep to find out what was running, or the 'which' command, or where command paths were stored, etc.) was a herculean task in the face of my limited abilities.