Articles Feed

Craftsman Swap at Relevance - Day 4

by: colin | July 9th, 2010 | 0 comments »

Today was my last day at Relevance, pairing again with Stuart Sierra. Along with Alan Dipert, we arrived at a solution for our data woes from yesterday, and deployed it. The approach we chose exposed a problem with data interpretation when a Clojure-precondition-thrown AssertionError came back to bite us later in the day. Note to self: AssertionError, which preconditions throw, is a java.lang.Error, not a java.lang.Exception. Catch it accordingly, especially if you're running these preconditions in a thread pool!

Today may have been the most fast-paced of my time here. In the morning after the project standup, Alan did some whiteboarding with Stuart and me to explain the architecture and requirements of a spike that we spent the rest of the day on. It's going to be a pretty cool system that integrates with the rest of the client system. The interesting bits include writing to Redis (potentially with a C application) and a web service (in Clojure) that reads from Redis server to provide data to end users.

So Stuart and I started from scratch on a new Compojure app with Clojure 1.2, Leiningen, and redis-clojure. We got set up relatively quickly, and implemented a tiny web service that parses a request to find what to read from Redis, does all the proper error handling, and returns a reasonable result. We had ideas about providing several types of web services (HTML, JSON, XML, perhaps even plain text), but for the purposes of the spike, we just used the browser.

I had fully expected Stuart's knowledge of Clojure to be impressive, and I wasn't disappointed. I didn't see too many things I hadn't seen before, but having seen things is different than knowing just when to use them. There was a new macro, condp, that I hadn't seen before, and it seems like a great substitute for cond in situations where all the predicates look very similar. And if you've ever been frustrated by needing to restart a Clojure process in order to add a jar to the classpath, you'll be excited to know that Stuart is working on an interesting solution involving Nailgun.

It's also been cool to hear a couple of questions Stuart Halloway asked us about Clojure idioms (he kindly included me in the questions, which were really for Stuart Sierra). It's sometimes easy to forget that everybody's human, and the smartest people will often ask for help rather than forge ahead as a lone warrior, and they're better off for it - even when it's just rubber ducking.

On that note, my experience here has been that almost everyone seems to be pairing all the time, and those who aren't pairing are either working on project management or QA-type tasks, or have their code reviewed by someone else later on. My own experience at 8th Light has always been that two heads are better than one, so this was cool to see. Additionally, as I've said before, the developers all seem to be very good at client-relations issues, and I discovered today that, as I suspected, Relevance uses its own developers as project managers for all projects. This seems very noteworthy to me - it's been rare that I've seen a developer as project manager, but it seems to be the rule here. This is also often the case for the QA role. Certainly there is a lot of testing going on here at both the unit and acceptance test level, but there is often a developer doing QA on other developers' work.

My experience this week was great. I would highly recommend anyone considering doing something like a craftsman swap / journeyman pairing tour to just do it. This has been a wonderful experience, and it's easy to see why people like Corey Haines have been such proponents of this sort of thing. Relevance would be an excellent choice for a visit if you can make it happen - I've learned a lot, and I look forward to bringing more of that back to the team at 8th Light when I get back to Chicagoland.

Many thanks to 8th Light and Relevance for the opportunity to do this!

Craftsman Swap at Relevance - Day 3

by: colin | July 8th, 2010 | 0 comments »

Day 3 at Relevance began, as the previous days, with the company standup. Stuart Sierra, of clojure.test and Practical Clojure fame, was my pair for the day. Yep, there are two Stuarts at Relevance with Clojure books! If you're interested in Clojure, and you haven't already purchased the Apress book, electronic or print, you should do that.

We started off with some Bash scripting for a cron job. Mostly pretty straightforward stuff, though I did really like the way the structure and logging behavior in the script turned out. I won't go so far as to say that this (or any) Bash script is a thing of beauty, but it's very clear, concise, and is going to do the job very well. One cool thing I hadn't realized was possible (and Stuart mentioned that a decent amount configuration is necessary for this) is that we used using sendmail to, well, send mail - but directly from the command line. So we had something along these lines:

  message=`cat email_file_contents.txt`
  sendmail -t $message

Our needs weren't very complex with regard to things like email headers, so it really was dirt simple to use, which was a very pleasant surprise.

We worked in Emacs, which was a bit of a struggle for me, but a reminder that I ought to be able to get around a bit better in that editor, as I'm interested in Clojure and many people in the community are gung-ho about it. org-mode was one notable takeaway there - we used the tables there to structure our table-based tests, and it can do some pretty cool formatting. I'll also say in Emacs' favor that users and authors sure are serious about documentation (just look at the previous link or the GNU Emacs Manuals), which I love to see. However, it can be a bit intimidating when you feel like you have to read a few books to get to know the editor.

At the project standup with Stuart, Alan Dipert, and Shay Frendt, the client reported a problem with a story that's still in progress, so Stuart and I spent the remainder of the day chasing this bug. There were several bright spots, however: we added several higher-level tests around some data-translation layers of the system (which includes JRuby on Rails and Clojure applications). Our tests were on the Clojure side of things, which was great to get a chance to see. Stuart had this great idea to write table-based tests a la Cucumber or Fitnesse, and we wrote a quick and dirty parser for a syntax similar to Cucumber's, plumbed a few tests in, and found one of our problems after a bit of data correction. We found the other, more mysterious problem soon afterward, and spent most of the rest of the day trying to track down the exact reason for it. It's interesting that neither of these problems had much to do with code - they were both problems with data. In one case, we received data in a format we didn't expect, and in the other, a subset of data suddenly went missing. I generally feel like good practices like TDD and pair programming can save you from many unexpected errors, but I don't know that there's a good solution for cases where data is mucked up, besides deploying, seeing what real data looks like, and adapting based on those results. I would suggest something like Haskell's QuickCheck (and similar ideas elsewhere), to try out more possibilities in the tests, but even if we used something like that here, I have a feeling we would have still ended up with an incorrect constraint, so wouldn't have caught these problems.

These problems make me wonder if, as external data drives more and more of a given application, it becomes more and more important for the data itself to be tested. That is, it would be ideal to be able to write tests that make assertions against the structure and contents of the external data. I'm not sure whether that would have been possible in this case, due to privacy concerns, but it's an idea that I'd love to hear feedback on anyway. And now that I imagine such a test system more carefully, maybe that's just design by contract in a different light?

Looking forward to tomorrow!

Craftsman Swap at Relevance - Day 2

by: colin | July 7th, 2010 | 4 comments »

Today was my second at Relevance for our craftmanship swap (see my first post for the goods on Day 1). Chris and I continued work on the project from yesterday. I was glad to have a chance to continue the story work we'd started, and see it through to completion by this afternoon, eliminating a few timezone bugs along the way (I'll get back to that).

We started the morning off with the company-wide stand-up meeting again, followed by a retrospective for the project I was pairing on. Chris explained that every iteration on a given project, Relevance does either a retrospective or a risk assessment meeting. After some scheduling and telephone difficulties on the client's side were (mostly) sorted out, Jason kicked us off as the retrospective facilitator. I haven't been on a project that held retrospectives on a regular basis before (though we've certainly done them at times), so it was interesting to see the very structured approach Relevance takes. As a brief outline, the team (and customers) began by outlining their expectations and hopes for the retrospective, followed by ratings of how several areas of the project (communication, ROI, building the right thing, etc.) were going, and finally a review and a set of action items with due dates attached. The team members - Chris, Jason, Don Mullen, and Michael Parenteau - were all excellent at interacting with the customers. I like to think that I'm pretty good at that kind of interaction, but there's a lot I picked up in a short time on that conference call. I heard a lot of rephrasing the customer's concerns to verify that the team always had the correct interpretation, and I'm sure the customer came away feeling like their needs were really being addressed, especially with the clear action items to address any issues that came up. Michael's design work on this project, incidentally, is pretty killer and got rave reviews from both of the client representatives.

In yesterday's installment, I neglected to mention the project management tool the teams use, Mingle. It's a very nice tool, which looks to have a ton of features, but (unlike some other many-featured products I've used) manages to keep the interface very clean and simple. I'm not sure in what situations I'd feel compelled to switch to it over something nice (and free) like Pivotal Tracker or Agile Zen, but it is an impressive piece of software that I'm glad to have had a chance to take a look at.

So... time zones. Every time I deal with them it's a mind-bending struggle to keep all the concerns in their proper place, and today was no exception. We had our Time.zone in Rails set to UTC, but were still getting some EST times. Well, it turns out things like Date.today.beginning_of_day don't respect that setting and use whatever the default system time zone is. After about an hour of investigations and pondering, we eventually decided to replace most uses of Date with the Rails TimeWithZone object, allowing some mildly unsavory naming with the understanding that the decision is going to need to be revisited to account for various user time zones anyway. It seems to me that this is a universal problem for apps that might be used in different time zones. Chris suggested that this might add to the often-quoted-but-rarely-sourced list of hard problems in computer science: cache invalidation and naming* (and off-by-one errors?). So henceforth, time zones are in there too. That's right, you heard it here first: it's three (or four, depending on if you're telling the off-by-one joke) hard problems: cache invalidation, naming, and time zones.

After work Aaron Bedra, Alex Warr, Stuart Halloway, and Stuart Sierra introduced me to my first draft-style game of Magic the Gathering. Yes, that's right, I spent the evening with three of the Clojure/core guys and learned a ton... about Magic. It was fun - I got a TON of help from everybody, especially Alex, and with a lot of help, I actually won a few rounds. We played duels, best-of-3, and I went 2-2 overall in games. And by "I", I mostly mean "the people who told me what I should put down." I heard a rumor on one end of the table that Relevance prefers to hire Magic players over non-players as programmers**, so potential applicants should take note. I don't know that I'll run out and buy a deck, but it's always fun to learn a new game, especially when the cards are named things like "Lord of Shatterskull Pass".

Sounds like I'll be sitting in with Alan Dipert's team tomorrow on some Clojure work, which I'm very much looking forward to.

* Some people on the Internet say the credit belongs to Phil Karlton, so it must be true.

** This sounds made up, and may be.

[UPDATE: fixed retrospective timing description based on Jason's comments below]

Craftsman Swap at Relevance - Day 1

by: colin | July 7th, 2010 | 2 comments »

I'm both honored and humbled to represent 8th Light on the latest Craftsmanship Swap, with Relevance in Durham, NC. I'd first heard about Relevance through Stuart Halloway's excellent book Programming Clojure, and their reputation precedes them in the Clojure community, as well as in the Ruby/Rails world. Jason Rudolph had me come in a few minutes early this morning to give me a quick introduction to the company before their company-wide standup, where the whole company gathered and very efficiently went through the interesting goings-on of the day. The plan for now is for me to spend a couple days working in Ruby/Rails, and a couple on Clojure - I'm excited about both.

I paired up with Chris Redinger to work on a Rails project that's just a few weeks old, but already doing some pretty cool stuff. There's a pretty slick graphing library on the project called Highcharts, which apparently even works on IE6 (gasp!). We did some refactoring, which was a pleasure - Chris has a great eye (nose?) for code smells and writing excellent code (as well as customer relationships), and I often felt like we were on the same wavelength as we made improvements. We ran into a strange issue with the RSpec version we were on: models seem to be loaded twice during our spec runs, which gave us annoying errors about redefining constants (when we were most definitely only defining them once). It turned out the right place for the (non-ActiveRecord) models was actually under lib/ in this case, and that cleared up our problem. Chris thought this may have already been fixed in the latest RSpec 2 beta, but unfortunately we can't upgrade because newer versions are only compatible with Rails 3, which we're not using on this project.

We also got some feature work done, of course. The code is a pleasure to work in - clean, plenty of tests, and several Thundercats references, which is perhaps most important of all. In all seriousness, it was pretty easy to jump in and contribute, and that's been due in large part to the high quality of the code. Bundler, by the way, seems awesome. I've heard mixed reviews, but my experience installing gems today was such a breeze that I'm definitely going to try to use it on my next Rails project. I also sometimes forget how freeing it is to work on a project using Git - all of our greenfield projects use it, but I've gotten used to being on Subversion projects, where making a branch is a big production. Chris uses feature branches regularly, and they seem to work pretty well.

The environment at Relevance is really nice - a big open space with lots of pairing stations, drinks and snacks, and even a keg of Aaron Bedra's delicious home-brewed Belgian-style wheat beer on tap. We had a great lunch of Thai food and very techy conversation - Node.js, Clojure, and EventMachine all got some playing time, and everyone agreed that Aquamacs was very pretty. Wait, maybe that last part went differently... After work, Aaron, his fiancee, Stuart Sierra, Jared Pace and I grabbed some Mexican food (after what was apparently a second failed attempt to eat at a place that serves something called a "Defibralator" - don't blame me, that's how they spell it on the online menu).

Chris and I ended the day working on tracking down a data issue, which we hadn't completely solved by the end of the day, but we narrowed the possible culprits down significantly, and I'm sure it'll be obvious to us in the morning. Looking forward to tomorrow's adventures!

International Craftsman Swap Day 3

by: eric | June 23rd, 2010 | 0 comments »

After attending tonights got:ruby I became obsessed with and started installing rvm. It worked swimmingly, and I’m looking forward to getting my development machine off of the embarrassingly low version of Ruby and experimenting on the latest versions without (unintentionally) screwing up my production environment. Indeed after this week I’ve got a lot to google, lookup, and research. I’ve decided I have got to get good at JQuery - probably using it on a small Rails 3 project in the near future - and learned that Jasmine has it all over ScrewUnit. This may mess up my Haskell plans - not that I’ve ever messed that up before. After that we played a lot of ping-pong, then I decided to clean up my hard drive, because it was really time. Then I realized if I’m gonna do this project as Rails3, I better make sure I can deploy it on dreamhost with bundler.

If this sounds like procrastinating it’s cause it is. I also checked email, read Anders’ blog on the elabs.se site, and watched some of Germany beating Ghana. None of this is writing the blog post and that’s because today’s blog post is going to be hard. Let’s get this out of the way first. Today was another great day at ELabs. With my Jet Lag finally kicked I really was able to contribute, using a couple ideas we’ve had before on 8th Light projects to get some cool work done on the project I’ve been working on this week. I even wrestled for the keyboard a bit (although they have two keyboards - so it was lonely, I wrestled with Pixie) then we topped it all off a cool Ruby user group meeting. The meeting was last minute, so they had lightning talks where CJ talked about Bundler and rvm, Jonas talked about a Javascript testing plugin he’s working on, we puzzled over a problem one of the other developers was having and even looked at Omni Graffle. Now that I’m awake the ELabs guys had to suffer my jokes like the 8th Light guys do all the time. Now they know why they sent me out of the country.

What’s been really nagging at me has to do with the way that the ELabs boys work. See they are what Brian Marick would call “classicist” TDDers - they essentially never use mocks. I on the other hand generally mock out a lot. What Jonas said to me was, and I’m going from memory here, “I’d rather the tests run slow than be right.” Of course taken as stated, this is a truism. Nobody is voting for slow tests, although I might argue that the tests that verify correctness are often different than unit tests, and that unit tests are verifying a different thing. Aside from speed mocks provide value in designing apis by letting you design it with a client using it, before the object itself exists, and in thinking of systems as objects passing around messages you can really focus on their interactions instead of the implementation details. Mocks lead to a cleaner design all told….except….

Except I usually stub out things for speed. Objects I’m stubbing are webservices, database objects, file access, etc. And in the best cases the benefit I get is speed, and in the worst cases I get a tangled mess of mocks where my code and tests are coupled, but nothing necessarily works. I’ve completely traded speed for correctness. Why is that? Why am I not getting all the purported benefits of mocking.

In a related note on the way here I started reading “growing object oriented software, guided by tests” by Steve Freeman and Nat Pryce. In a throw away comment they say, “Never mock out third party API’s, write thin classes that wrap those with integration tests, and mock out your objects interaction with those classes.” Now maybe you think you haven’t done this, but let me give you some typical examples of mocks:

• IO.stub!(:read).and_return(mock_file)
• ActiveRecord.should_receive(:find).with(1)

Well look at that - those are two third party API’s aren’t they? And they are often mocked out everywhere! Trading speed for correctness again. “Okay fancy boy”, you’re saying - and really why are you calling me that, “Then we shouldn’t use mocks. Problem solved.” Not so fast. Have you ever had the problem where you are testing that an object gets saved and you do this:

object.should_receive(:update_attributes).with({:my => value})

but then you think, “Gosh I really don’t care how they save the values, I just care that it gets saved.” Right now you have to call update_attributes to make this pass, but you could call update_attribute, or set the object and save!, or hell use SQL although you shouldn’t. This makes for a crappy test - one you’re likely to break then fix later instead of changing in the deliberate process of TDD. What if instead you did this:

object.should_receive(:update_my_value_to).with(value)

Of course the other things are still true - assuming it’s an active record object, but maybe it’s not. Maybe it’s a wrapper around it, or maybe it’s datamapper object, I don’t really don’t care. I’ve gone ahead and mocked this call because that’s the call I really want to see - and somewhere else I’ve test driven that call against the database. Now let’s imagine you’ve got more complicated scenarios. Ever done this?

object.should_receive(:get_this).and_return(object2)
object2.should_receive(:is_true?).and_return(false)

This is a simple example - but I’m sure you’ve seen worse. The problem is again that you really need one method, maybe two, but you probably figured out in your head the algorithm beforehand, then test drove it. Maybe you know if object2 was true you needed to set unrelated object3’s flag - so you started writing those tests. Let’s look at that rule again though - don’t mock a third party API. Well what defines a third party API? Is it a third party if another company wrote it? How about the same company - but on a different project? Or the same project but a long time ago? Or YOU six weeks ago and you forgot it. Isn’t it a third party API again? What’s the difference? Should you then mock out objectnew - and test drive it with real objects? Because it’s pretty clear the API you want doesn’t exist yet, and that’s the crux of my long wrambling argument that I’ll probably better express and codify when it’s not late and I’m not tired:

Stop mocking the API you already have - mock the API you need

And then if by chance it matches the API you already have - by all means just substitute the real object in. But write the implementation with mocks first - without using any real API unless it matches coincidentally. Pretend the object doesn’t exist yet, and then mock. And maybe then you’ll get what you’re looking for.

Eh - or maybe I should go write some Javascript.

International Craftsman Swap Day 2

by: eric | June 22nd, 2010 | 2 comments »

Before I get into some of the details of day #2 at eLabs, let me dispell a few myths about Sweden that my American readers may still believe.

Swedes buy all their furniture at IKEA

This is of course a silly idea, caused by the prominence of the IKEA brand in the United States. In fact IKEA accounts for a mere 83% of the furniture market here in Sweden, with the rest of the furniture being bought at independent specialty stores such as Wal-Mart.

Ski jumping is the primary form of transportation

Swedes have a wide variety of commuting options available to them. By far the most popular is to bike to work at speeds of upwards of 300 miles an hour, using the bodies of pedestrians to slow your bike down when you arrive at your office. The speed is necessary to outrun the second most popular form of transportation, the electric trams. The trams take a convenient route to your office, assuming they don’t fly off the tracks. Which they do, often. Ski jumping is naturally third, keeping the commuter safely above the trams and bikes, until they crash down on the brick sidewalks. Finally I believe two gentleman own cars, but they rarely drive them because they are afraid.

The Swedish Chef is President

Don’t be an idiot. Sweden has a Prime Minister, not a President.

With that out of the way, we can properly concentrate on my time at eLabs. I promised yesterday I’d document stand-ups the eLabs way, and I’m glad I did because today I got to see first-hand day 2. Standups at eLabs go something like this - everybody stands up from all projects. There’s about 8 employees, so it’s sizeable but not gigantic. On Mondays everybody gives an update for the project they are on. The rest of the week everybody just pipes up if they have a problem. What I find interesting is there is no customer involvement - these stand ups are for team members to team members - and the multiple project nature of the meetings doesn’t seem to slow them down at all.

From there they retire to pairing stations and it’s a lot quieter than the 8th Light office - especially since I’m not at the 8th Light office making noise. They have offices where the pairs work, which I find both good and bad. At 8th Light on fridays we have frequent problems where one pair is on a conference call and another is animatedly discussing a problem, so that would be helpful, on the other hand there’s definitely an energy to everybody in the same room that isn’t there when offices have doors. It’s an interesting hybrid approach, and I could get used to it.

On a personal level I wasn’t 100% today. I woke up at 4:45, apparently Jet Lagged, and learned that Gothenburg doesn’t have early morning coffee shops for iPhone hacking. After walking around the rather cold town for over an hour I finally found one at 7:30, and thought I was fine. At two I crashed, and was completely losing concentration, practically falling asleep in my chair. Fortunately they have ping pong and after a couple quick games I was back to my normal self, and really wrote some code. I really want to get better at JQuery and ScrewUnit, because right now I’m still coding too much Javascript by luck.

Afterwards Jonas was kind enough to join me for dinner and we had a lively conversation about mocks and when (or when to not) use them, as well as the way eLabs does their Rails testing. I’m too tired to properly write my thoughts now, but it’s definitely gonna be a blog post tomorrow. It was a very nice dinner and I’m glad Jonas joined me. Now if you’ll excuse me I have to dodge the death trams on my way back to Andres Apartment.

International Craftsman Swap Day 1

by: eric | June 21st, 2010 | 0 comments »

Today was day one of my Craftsmanswap with eLabs developer Anders Tornqvist, and so far they have treated me with the hospitality and graciousness I expected. Largely they’ve been led by my pair, pictured at right. This is Pixie, who’s been working in the same room as me all day, and when she hasn’t been barking at me she’s been growling. It’s been a tad….terrifying? Especially when the blood is dripping from her teeth, and she can leap so high!

Actually poor Pixie had a rough time of it last night, and it apparently led to her being out of sorts. She eventually got along with me just fine, and I was able to have a productive day pairing with Ingemar. I hope I was helpful, as I’m trying to spend most of my time listening. I hate being the guy who shows up on a project and immediately tells people how to do stuff, plus Ingemar had a grumpy boxer/pit-bull mix next to him so I wasn’t gonna ruffle feathers. The problem with that approach is that you can end up failing to contribute by being too passive, but I think I did okay today. Tomorrow I’ll probably be a little more vocal, and moreso the next day. You know, just in time for me to leave.

The highlight of our day, for me anyway, was implementing drag and drop in JQuery. I’ve never done it before - I think I’ve done it in Prototype but it’s been a while - and it’s amazing what a breeze it was. I’m going to have to find an excuse to use JQuery more, and I’ll probably try and find out some info on ScrewUnit. Of course on the plane I started reading “Growing Object Oriented Software, Guided by Tests” and a new iPhone book, so I’m nothing if not capable of overbooking myself. Speaking of which GOOS looks like a real winner, if you didn’t already know.

In addition to some JQuery at one point or another Ingemar touched on a gem or idiom I wasn’t familiar with, often with me hurriedly scribbling notes probably without him realizing it. The list of gems from today alone was:

• formtastic
• hitch
• machinist
• launchy
• carrierwave

Hitch was seriously cool, allowing us to push git changes as a pair. Formtastic is an interesting form builder, and although we had some struggles with it today Ingemar assures me it’s awesome. It did have a nice DSL syntax. We used machinist’s blueprint feature for building factory objects, kinda like factory girl. I admit I like the concise syntax, but I wonder if we should be making it easier to create lots of objects in setup for a test. Launchy cleanly launched the browser when testing at a given point, and finally I’m excited to use carrierwave for file uploads tomorrow.

I have more notes, particularly regarding the different way that eLabs does standups, but I fear this blog post has become disjointed and a tad dull, so I shall leave you until tomorrow.

Makin' somthin'

by: doug | March 15th, 2010 | 4 comments »

Today (March 15th, 2010) is my Grandfather's 90th birthday. We celebrated with him this weekend in Pike County, IL.

I spent quite a bit a time growing up with Grandpa. On many weekends and for entire weeks of the summer, I'd join him on his farm in Perry, IL. By the time I came a long, grandpa had mostly retired. He rented out his farmland, but still kept some cows around, mostly so that he'd have something to feed every morning.

Grandpa dedicated his retirement to a variety of woodworking pursuits. He made scale models of local buildings, wooden carousels, clocks, toys, banks, and even the occasional joke piece. One of my favorites was a small base with a US quarter mounted to it. A tiny dowel rod mallet slid into a hole in the base. Hand stenciled on the base was the title of the piece: "Quarter Pounder." He refinished furniture, built us an elevated playhouse, and built a scale model of our house. He'd see plans for something in a magazine or pick something up on a trip, and go to work on it in his workshop. I would tag along for much of this activity.

When I was 7 or so, Grandpa did something that I think more than anything, shaped what I was to become and do in the future. He built me my own workbench. It was kid height with kid sized tools. I know that now you can buy playschool workbenches and tools for kids. But the tools on my workbench were no plastic toys from China. They were real: a real saw that was really sharp, a vise that could crush things, a hammer that could actually drive nails. He set it up in his workshop down at the end of the big workbench.

So the story goes like this: (This is how grandpa tells it anyway.) He had lost track of me in the workshop. He had gotten involved in something and I had gone quiet. When he found me, I was hunch over the blue workbench furiously working. Grandpa asked me what I was doing, and I responded "makin' somthin'" I guess grandpa got a real kick out of my response because it's one of those family stories that has been told over and over. Here is what I remember. I really didn't know what I was making. I just knew that I was consumed by the desire to make something. So I was cutting pieces of wood and nailing them together all because I wanted to make. It was part emulation. I admired Grandpa and wanted to be like him. But it was more that he had infected me with this bug. I had caught it. I wanted to be a maker.

I studied engineering in college, but ended up gravitating towards software. Fairly recently I've discovered just why it is that software appeals so much to me. It is because software is making. In engineering, we'd design something and send it out somewhere to be made, but in software, everyday I get to step into a the world of the maker and just build stuff. Every time I open my laptop, I'm 7 years old again and hunched over my workbench consumed by the desire to make. The tools are different, the raw materials are different, the end product is different, but that feeling and that drive to make is just the same.

Thank you, Grandpa, for putting tools in my hands and showing me how to use them, and letting me make something. Happy 90th!

Zeroth rule of professionalism

by: paul | January 8th, 2010 | 1 comments »

This is a response to an article “Software Testing Craft” by Markus Gärtner in inaugural issue of Agile Record.

As an apprentice, I remember thinking that solutions to software were either right or wrong. Later this was able to be simplified to either the solution works or doesn’t work. This became my base level understanding of a software solution.

Then came the time I thought solutions should be judged by how clean or efficient they were. This was my renaissance of aesthetics in the code. How to code your intentions expressively was the goal. This too became a new base level of understanding.

Now I am of the understanding that software solutions are a judged by factors of time. Making all the trade offs correctly so the code works and is readable, but also in the shortest amount of time possible. The key thing here is to take the long term view of time. Not how much time in a single sitting, but every time you come back to the same solution. How often do you come back? How hard is it to change?

From the article, Markus says, “As a software tester, you should take responsibility for the out- come of every decision you make. I call this the zeroth rule of professionalism.”

I think this is an elegant way of stating my understanding of software solutions. Every decision you make is a function of time and understanding. By taking responsibility for each of your decisions software becomes a series of trade offs that you have to live with and learn from. When a design works and is written well, it becomes easier to live with the outcomes of your decisions.

It is much like how I learned to play chess. At first I would make a move and try to understand the consequences in position and strength. Then I learned the common openings and endgames which helped me express my strategic creativity and play moves that had aesthetic value. Finally came the important skill. Being able to project moves forward and do a risk analysis of each possible move. This let me take the previous skills and put them together in a coherent fashion. I could understand how a move fatal to my king was a consequence of a move made much earlier in the game and learn from that decision. This skill is when I started playing chess as a game rather than a set of moves.

For me, it was only through the out-comes of my design decisions that I learn this lesson. It was very important for me to be in a position transparent to the positive and negative consequences of the code I write. Like the chess analogy, I need to project forward to attempt to understand the consequences of a decision before I make it.

Why Software Development is a Craft

by: doug | October 22nd, 2009 | 4 comments »

Craftsmanship has been used as a metaphor for software development. Pete McBreen argues in his book “Software Craftsmanship” that craft is a better metaphor for software development than is engineering or science.

I take the association one step further and claim that it craft is not just a good metaphor for software development, but that software development is literally a craft.

The Hand and the Eye

A key facet of historical craft is the intimate connection between the hand and the eye. A furniture maker cuts a joint with his hands, then fits the two pieces together. If the alignment isn’t perfect, he sands and trims and fills until the joint is true. It’s a cycle of shaping and observing. A glass blower turns the bead of molten glass over and over in a steady rhythm as she shapes the glass towards its final form. Her eye informs her hands and she constantly sees the effects of the changing speed and angle of the turning rod.

Code is a physical thing. Though technically code is nothing more than some states stored on a fast spinning magnetic disk, it is just as physical as a lump of clay. Consider the language used when talking about code. It is touched, shaped, moved, broken, cut, pasted, fiddled with, tweaked, and played with. It is the physicality of code that enables the feedback between the hand and the eye. It is touched and a change is observed.

This is why Test Driven Development is such a key practice in software craftsmanship. There was a time when a programmer would write a bunch of code and try it out hours or even days later. The time between making something with the hand and seeing the results was long. When a programmer writes a little bit of test code and runs it, then a little bit of production code and runs it, this cycle shrinks to minutes or even seconds. The connection between the hand and the eye increases. The craftsman immediately sees the work of his hand.

Making

Another element that makes software development a literal craft is that software development is a process of making. Contrast that to engineering. What is the primary activity of an engineer? It is design. A civil engineer designs a bridge that an ironworker builds. The electrical engineer doesn’t typically etch or populate the circuit board. She designs a circuit that is printed on a board and populated by either machine or technician.

In contrast, the software craftsman doesn’t just design the software (though she does do that), she also makes it. She writes the code that makes it work. There is little manufacturing involved in taking the made software and putting it in the hands of the person who will use it. Sometimes there is a deployment to a server or perhaps a CD is burnt and packaged in a box. But often even these tasks are performed or automated by the maker herself.

Material

Historical craftsmen have always been makers. The potter makes a vessel; the blacksmith, a horseshoe; the weaver, a garment. These makers have always had close connection to the raw material of their work: the wool, the iron, and the clay. What then is the raw material of software craftsmanship? What is the material of which software is made?

The material of software is language. Java, Ruby, C, Scala, Clojure, etc.: these syntaxes are the medium in which the software craftsman works. What makes this media so interesting is that the materials themselves are composite materials made of more primitive materials. Beneath Ruby code lies an interpreter built in C which is compiled by a compiler. The most basic of which is built in an assembly language which is assembled by an assembler which is built in the most primitive machine language which is read directly by the computer’s processor. Each new language emerges out of other languages as craftsmen explore the materials and invent new ways of combining and deconstructing what they have at hand.

It’s similar to metal alloys like steel. Iron is combined with other metals to make an new raw material whose strength enables the construction of enormous buildings. Each new language innovation gives the software craftsman a new, more powerful material from which to build both larger and simpler systems.

Tools

A discussion of software as craft isn’t complete without mentioning tools. A software craftsman does deal with the hardware on which his software runs, but the more interesting tool set is the software that the craftsman uses to write code. The text editor or development environment, the unit testing framework, the continuous integration system, and the acceptance test system are the tools of the software craftsman’s trade. Because these tools are built from the same raw materials as the thing being made, software craftsmen have the ability like historical craftsmen to be tool makers.

Learning

The final argument for treating software development as a literal craft is the way in which it is learned. A traditional college education in computer engineering or computer science produces graduates woefully unprepared to develop software. The best way to learn how to make software is to sit down with someone who knows how to do it and learn from them. This is currently being displayed in many shops throughout the world that are embracing an apprenticeship model for training and growth. This model has been used for centuries to pass on crafts from one generation to the next.

Software is Craft

The Software Craftsmanship community is growing and having some fabulous discussions. I think that this is largely a result of people not just using craftsmanship as a way to talk about or explain software, but embracing and practicing software as a literal craft. The historical crafts have begun to inform us in the software craft and have helped us develop our practice. Most metaphors break down when taken too far, but software-as-craft isn’t losing any steam. Perhaps that is because the association is more than metaphor and software really is a craft.

Pair Fridays

by: paul | October 6th, 2009 | 0 comments »

8th Light has always had an open door policy towards developers. When anyone has asked to come hang out at 8th Light offices, we don’t turn anyone away. We also invite developers to come in and pair with us. It has been a fun practice to get to know other developers here in Chicago as well as developers traveling through town. We would like to flip that practice around and invite anyone interested in pairing with 8th Lighters or just coming in to hang out.

Every Friday we have a noon lunch and learn (lunch provided by 8th Light) and then we will be available to pair for the afternoon. Want to come in and see how we work? Learn to use Limelight? Teach us something cool? Just hang out with cool developers?

Please RSVP with me (paul [at] our domain name) so we know how much food to order.

Apprenticing to Mastery

by: paul | September 29th, 2009 | 0 comments »

Come see Dave Hoover and I speak about about software apprenticeships on November 19, 2009 in San Fransisco.

Thoughts from a Boutique Software Shop

by: paul | September 12th, 2009 | 0 comments »

Michael Feathers recently wrote a blog about boutique software shops. He drew the parallel between master chefs and software shops. There were a few great points I would like to respond to:

1. “So, where are the high-end restaurants of software development?  One place to look is in the “boutique software shops.”  I don’t know where I first heard that term, but for me it is a “catch all” for all of the small software development houses that I see springing up all over the place.”

This is an interesting phenomenon. I am not sure if this has always happened or if I am paying attention more to boutique shops now that I am a part of one. 8th Light is an 8 craftsmen software shop that started in 2006 with the goal of writing high quality software. No teaching, coaching, staff augmentation. Just writing software, with the idea that focusing on proving quality has a high correlation to success.

I agree with the high-end software shop analogy. If you take a small team of trained craftsmen focused on doing their best work, the result is most often a very strong culture of quality. Ramsay creates this strong culture of quality through a theatrical performance of yelling and screaming at failure. There are other ways for masters to do the same thing. Micah Martin, the 8th Light master craftsman, creates this strong culture by setting an example of writing good code and holding yourself to a constantly higher standard. This is the common thread that I have seen through these boutique shops–they all have an owner who is a technical leader who creates a strong culture where (excuse the pun) failure is just not an option. There are other similarities like strong discipline, small teams, cutting edge technologies, and ability to develop strong skill sets in developers, however, I think that all of these are direct descendants of the strong leadership.

2. “It’s not that development teams need UX people, it’s more like UX teams need developers.”

I partially agree with Michael. I think this statement can be replaced with any critical specialization in the domain of software applications. The reason UX is getting a spotlight is because, as Michael notes, we have stuck UX on the back burner for so long. In the last few years though, the expectations from users of software have luckily skyrocketed. It is no longer okay to plow through features, but they need to be simple, attractive, and intuitive. When I worked with Gilberto Medrano in 2005, he talked about the UX revolution that was coming. In 2006, he created a UX design while at 8th Light that continues to impress 3 years later (in web application years, that is a lifetime). Well, he was right, I can no longer stand an application which is not aesthetically pleasing. It doesn’t matter how cool the feature set–which is a weird statement to come from a developer.

This is an argument for craftsmen teams. Craftsmen have many tools in their bag, and UX is one of them. Part of being a craftsman is to know enough about UX that you can talk to an expert as well as do some UX. Just like a UX expert craftsman can dabble in code. A craftsmen has many shallow skills as well as a few very deep skills. Craftsmen teams have individuals with diverse expertise talents and a common knowledge of intermediate and beginner talents. It is very fun to be on these teams, when the work is one which has quality–quality of being “aesthetically” impressive as well as “feature set” impressive.

Reasons to Attend SCNA

by: paul | July 17th, 2009 | 1 comments »

SCNA website

1 - “The list of SCNA presenters reads like Who’s Who of Software Jedi Knighthood” -- Ray Hightower

This is a complete testament to how willing and excited the thought leaders and software masters were to speak at this conference. The creme of the crop in software mastery will be talking about how to raise the bar in our industry. I have never seen a lineup of speakers who put me in such a state of awe since the early XP Universe days. Thanks to all of them for getting together for this conference.

2 - Join software craftsmanship over crap.

Last year Uncle Bob challenged software developers to become professionals. We have spent a year of summits, manifestos, meet ups, and conferences trying to figure out how to move forward towards professionalism with this paradigm of software craftsmanship. The momentum of craftsmanship is only growing.

3 - Software craftsmen all in one room.

The google map of software craftsman who have signed the software craftsmanship manifesto has proven this to be a global community of software developers. It is unique that we have people flying in from multiple continents to participate. I am excited to meet face to face with all these craftsmen whom I know only their ideas and email addresses.

4 - Richard Sennett

A sociologist who wrote The Craftsman, Dr. Sennett has provided a template for studying the habits and techniques of craftsmanship. He touches on everything from extending your concentration to why we choose vocations so passionately. It is a true authority on craftsmanship.

Apprentice Architecture

by: paul | May 6th, 2009 | 1 comments »

Good design sense is a skill that comes only from many years of coding experience. Sometimes it can be very difficult to make those design decisions when you are an apprentice or otherwise don’t have much experience.

When I was an apprentice, oftentimes I would get a problem from Micah (my mentor) and would solve it the simplest way possible. Then I would walk up to him with my head held high and say I was done. He would almost always point out some way the architecture was not easy to extend or that he didn’t even know java had goto statements.

As an apprentice, the most important thing is to get everything to work correctly; only then should you concentrate on making sure it is good code. Writing great code with great designs is not a skill that will appear overnight. It took years of honing my design sense to be able to see designs right away, and I have only scratched the surface of my mentor’s abilities.

When I was an apprentice, I lacked the experience and skill to make difficult architectural choices. Let alone the ability to get it right on the first pass. I instead stayed close to the code and continued to move forward writing working code. This led to many design mistakes, and I had to throw out plenty of code or refactor to a better design. This is an exercise in taking a step backwards to move forwards. I learned the value of working code as well as the value of refactoring to better designs. Content before form is an important lesson I learned as an apprentice. It laid the foundation for the later lesson that good form is essential for high quality code.

As an apprentice, ask your mentor when you have completed a task if they think there is a better design. Then refactor that design and compare the two. Once again, repetition and practice will pay off as these exercises help you develop a matured design sense. You will learn from having to solve the problem without being told the design first, and then later having to re-implement a better design. This practice will internalize your design sense and eventually you will start to see the better designs the first time through.

The big problem with trying to get the design right the first time is it leads to coders block. Staring at the blank screen, trying to figure out the best way to do something. Even if you are writing the wrong code, it is important to be moving in some direction. When I see the code, oftentimes the design I get will form around the reading of the code rather than trying to think in the abstract about the whole problem at once. For me the problem and the design for the solution would be too big of a mental model to fit in my head all at once. Don’t worry, as you get more experience, your mental context will expand too. Your ability to sustain concentration will build as well as you practice and become more experienced. With experience, you won’t have to think about as many of the small problems anymore.

Architecture is like most craftsman practices in the sense that there are breakthroughs but there is always more to learn. I read a blog recently where Uncle Bob Martin talks about thinking through the architecture of a problem for hours or days before he will start. When I was an apprentice, I would not have had enough experience or a large enough mental model to think about the architectural impact of a solution. Even as a journeyman, I still only have a big enough mental model to think about an aspect of a problem, write the code, then reevaluate where the solution stands in the context of the system.

For an apprentice, bad design should not be seen as the end of the world. As long as you are learning and progressing in the techniques of creating working code, you are moving in the right direction. Design sense is a long-term skill and you will have to be patient with it. Remember that practice makes perfect.

Bug free or Free Bugs

by: paul | April 26th, 2009 | 1 comments »

I will not charge a client for a bug fix. Not a penny. If I make a mistake, it is my professional obligation to fix it.

If something doesn’t work with my car, there could be catastrophic consequences, I would be mad unless the company has a solution and offers to fix it for free. As a car owner, I expect nothing less. If a doctor makes a mistake, the patient has the right to sue the doctor for malpractice. Why is it if I make a mistake, I get off scot free? Or worse, I get paid to fix my own mistakes.

I know sometimes the devil is in the details. What is a bug? This is not an easy question to answer, but if there are customer written acceptance tests for the system, the items that fall through are fewer. These are general rules I go by when deciding if something is a bug or not.

One: I made a mistake. These are usually easy to notice, due to the redness in my face when the bug is reported. It is clear to me, I made a mistake, and it is clear I need to fix the bug. It should not cost the customer any money and the process should be transparent.

Two: There is a mistake that both development and the customer team should have caught. A scenario the customer should have specified and during development I should have noticed and brought to their attention. The fault goes on both parties and can be fixed at some version of half price (i.e. every other or a half price story).

Three: The application doesn’t behave correctly due to a missed specification. a scenario that the customer missed or a piece of the business logic that wasn’t fully correct. Almost everyone makes some mistakes. This is not a bug to me, but a feature enhancement. It can be written up as a story and completed.

I think it is important to build faith with the customer that there is a team of developers that are accountable. When you create the culture of accountability, it spreads. The customer team is willing to be accountable when they make a mistake. When no one is afraid to make or admit to a mistake, the projects quality is positively affected. Finally, by taking financial ownership of a bug, I build a trust with my stakeholders of the project.

Craftsman Swap Day 5

by: jim | April 19th, 2009 | 2 comments »

Today turned out to be little coding and quite a bit of retrospective. I was able to pair with Nate Jackson for a little bit on the iPhone application that he’s working on. I also tested a Webrat patch on a brand new Rails application via a cucumber test to wrap that up.

Over some excellent Greek food, we had an informal retrospective. A few notes from the discussion:

• The duration of the swap seems just about right. As Dave said, the law of diminishing returns likely kicks in after a few days or a week, and the cost of another week would likely outweigh the benefits.
• Kevin Taylor brought up the idea of more planning in response to my admission that I was a bit nervous Monday morning. The source of my nervousness was really due to not knowing exactly what to expect. I think that the lack of planning was actually extremely beneficial to the flow of the week. I was able to pair with many different people, and the flow between pairs was very organic and natural. Having a plan to follow probably would have changed this dynamic for the worse.
• The feeling that the swap was successful was unanimous. We all felt that we benefitted from my being onsite for the past week. I knew that I was learning a ton and having a great experience, but I was extremely happy to hear similar feelings vocalized by the Obtivians.

This was an absolutely fantastic experience. It gave me a chance to step away from client work for an entire week and explore new technologies, techniques and ideas, work with different people, and learn a lot. I believe that both 8th Light and Obtiva have compared this time away from client work to spending a week at a conference. From my experience this past week, this was better than any conference I’ve attended. Listening to speakers talk about new ideas is one thing; actually pairing with great developers and learning hands-on is in a different league.

Craftsman Swap Day 4

by: jim | April 17th, 2009 | 1 comments »

Dave Hoover and I got back to the Mad Mimi feature implementation first thing in the morning. Dave had left a failing test the previous afternoon, which was meant to serve as a reminder for where we left off. This technique is great when you need to stop in the middle of what you’re doing, and it works well as long as you know what the next step needs to be. This should help you reestablish the context you were holding when you stopped. Of course, if you’re at a natural break point and the next step isn’t clearly defined, I tend to avoid writing a failing test. Often when I come back to code after a break, I will find a simpler way to approach the problem at hand. I don’t like short-circuiting that process by leading myself towards a solution I saw when I was leaving the code. Anyway, in this case, it was clear where we needed to go, and the failing test got us right back to it.

Mad Mimi has grown organically without any traditional marketing or advertising efforts. That is not to say that there aren’t a lot of users and a lot of data. There are a few database tables that are quite large, and optimizations have been put into place in order for the system to remain responsive. Optimizations are usually going to make a system more complex from a code standpoint. The common advice to avoid premature optimizations is valid exactly because of this. In addition, you’re almost always going to be wrong about where the bottlenecks will occur in your application. If you were to do some premature optimization, you’ll likely find yourself with overly complex code that is still slow. Mimi has been optimized only as needed, and the code base is better for it. One of the optimizations that has been made is limited use of stored procedures.

Stored procedures are not easy to test. The feature we were working on required us to pass an additional parameter into the existing stored procedure. Once we dropped into stored procedure land, we lost the safety net of our tests. So we approached the problem stepwise, in a way “test driving” the stored procedure from the user interface. Fortunately, the stored procedure isn’t overly complex, and executing a couple manual test cases made us confident that the change was correct.

After we finished the feature, it was time to deploy so the customer could test and provide feedback. The deployment process for this project is different than just about every other project I’ve ever been on. Dave has taught the customer, who is not a programmer, how to update from Subversion, run data migrations, start/restart his local web server and BackgroudRB services, etc.. With just a little help, the customer has the system running in development mode on his Mac! Not only that, the customer does the design work for the site. We just added the appropriate view files while implementing the feature with a note for the customer to come through and style the HTML and provide the correct content. The customer is heavily involved in the process, and clearly cares very much about the product. Dave is extremely lucky to have this kind of customer for this project.

Craftsman Swap Day 3

by: jim | April 16th, 2009 | 0 comments »

I spent my day pairing with Dave Hoover on Mad Mimi. The first thing I noticed during our pairing session is that Dave has many more responsibilities within Obtiva than just coding. The opportunities for distractions seem to increase exponentially the closer you are to the details of running a business. The context switching involved in handling interruptions while coding is something that I really struggle with, but Dave is quite adept at it. Having a pair helps with ignoring these distractions, for better or for worse. I’ve been using the Pomodoro technique for the past couple months with some success to try to help stay focused and deal with distractions, but I’ve found that the best way to avoid distractions is to pair program. Dave “thanked” me at the end of the day for helping him ignore his growing list of unread emails, which he would have to catch up on later. The upshot of this is that we got some concentrated work done without a ton of distractions taking our attention away from the task.

At the start of the day, we picked up a new Mad Mimi feature and started discussing it. As is usually the case when beginning to dig into a feature, we quickly came up with some questions for which we would need the customer’s input. Unfortunately, the customer wasn’t available; after making note of the questions, we started talking about a change that will be rolled out sometime in the near future, but should not be added just yet. Dave accurately identified the need to create a branch for the feature. I’ve recently had a similar need for this kind of feature branch, and I’ve done this a couple times in the past few months. Dave hadn’t created a branch in Subversion before, so here was a chance to teach him something.

There are a few different reasons why you might want to use this technique, but this is the situation I’ve been running into lately. There are (at least) two different types of branches: bug fix / release, and feature. When releasing a new version of the system, a release branch can be created in order to allow bug fixes to be quickly and safely developed and deployed. A feature branch, on the other hand, comes in handy in a number of situations. One situation is when you want to develop a new feature that needs to be deployed as an update to the release. If you were to develop the feature on the release branch, you would run the risk of making deploying the branch at a moment’s notice difficult or impossible. By developing on a feature branch, you can develop and test the feature in isolation, then merge the changes back to the release branch (and/or the trunk). In Dave’s case, he releases from the trunk, but he wanted this particular feature to not be deployed until he’s ready. A feature branch works great in this case, and he’ll only have to merge back to the trunk since there isn’t a need for a release branch. Once that merge is done, the branch can (and should) be killed; the key to keeping your branches manageable is to limit the number of branches that you ever need to think about. The goal should be for each branch to have the shortest lifetime as possible. For a decent branching strategy, see this article.

After Dave successfully created his branch (and played around with merging to understand how that would work), we went ahead and started implementing this new feature on the branch. Of course, we soon were able to get the information we needed from the customer to continue on the original (higher priority) feature. Since we were working on the branch, we didn’t need to abandon our work in order to start on the other feature. We just opened up the trunk’s code in our editor and away we went. This is another advantage of working in a feature branch: it’s simple and cheap to jump around. We spent the rest of the day working on this feature, though we ended the day without completing it. We will finish it up on day 4.

Craftsman Swap Day 2

by: jim | April 15th, 2009 | 0 comments »

Hackfest

Every week, Obtiva sets aside time for what they call Hackfest (I believe this grew out of Geekfest, which is what I’d describe as a Lunch ‘n Learn). Everyone is encouraged to take some time over lunch to work on some non-client code, and the emphasis is on “doing” instead of just talking. I really like the idea of HackFest. By encouraging employees to spend time on side projects, the company (and employee) can only benefit. Client-work is necessary in order for us to get paid, but the passion for the craft cannot flourish if the only projects one is working on is for someone else. There is something selfish about software development, and that isn’t a bad thing. In order for you to enjoy your job, I believe that you have to get satisfaction out of what you’re doing every day. I think that’s why I’m such a fan of Test Driven Development. There is always a goal, usually only a maximum of a couple minutes out: either get the current test to pass, or write a failing test (don’t forget to refactor). This constant flow is encouraging because every time you get your tests to green, there is a feeling of accomplishment.

So for Hackfest, I joined Andy Maleh on his project, which is in the really early concept phase. We worked through some mockups and designs for a social website that he has in the works. Basically, we designed and drew up paper mockups of a critical feature. Paper prototyping is intended to help developers create a user experience that meets the user’s needs. One possible mistake that you can make, as I certainly have, is to forget that you have AJAX effects at your disposal in your web application, and that your prototypes should be built with that in mind. Instead of every user input resulting in a new (paper) page being put down in front of the user, consider simulating the slide effect that would occur when you click an “add” button which dynamically inserts a new form into the page. By just replacing the entire page in front of the user, you’re really missing the user experience improvements that AJAX can give you. Andy’s mockups did this well, and I think that they will result in more successful user testing.

Afternoon Pairing

I paired with Nate Jackson for the good part of the rest of the afternoon. Nate was Obtiva’s third apprentice and is now a consultant. We were working on a really cool iPhone application, but mainly I just slowed Nate down. One thing that bothers me about developing for the iPhone is how difficult it is to test the code that touches the framework; in particular, all of the delegates in the controllers. I would like to gain a better understanding of how the framework really works so that maybe I can find some better seams for testing purposes. As a result of this inherent difficulty, we didn’t test drive the code that was written, and I noticed that the rhythm of the pairing session was distinctly different from the ping-pong sessions that I’ve grown accustomed to. Without the failing test/passing test rhythm, there aren’t distinct break points where the keyboard naturally gets passed. So though the pairing session was successful, it definitely felt different.

Craftsman Swap Day 1

by: jim | April 14th, 2009 | 2 comments »

My initial impression of the Obtiva office is the relaxed atmosphere. It consists of a big, open work area with lots of pairing stations. At the beginning of the day, I jumped right into an internal stand up meeting with a few of the Obtiva folks. It was short, sweet and to the point. One interesting difference between this and the way I’m used to doing stand ups is items that would normally be handled as followups were discussed during the individual updates. The discussions never wandered far, so this worked quite well. I was paired with Tom Kersten most of the day on some client work.

While working with Tom, I was introduced to a few tools that I hadn’t used before.

• Fluid, a Site Specific Browser that basically allows you to sandbox a web application in a dedicated browser process. You can Command-Tab to an icon that you assign, and if (or more accurately, when) your browser crashes, Fluid does not.
• GNU Screen, a window manager that removes the latency from remote pairing. Of course, you need to use an editor like vi for it to work for you.
• Text Expander, which does exactly what it says: you specify shortcuts, e.g. brb, and it will expand it to the full text, e.g. Be right back.
• Rak, a Ruby replacement for grep. It gives you the line number of the matched text, which regular grep can do too but it always takes me 5 minutes to figure out the right option to pass to get it to work.

Tom’s editor of choice (even for Rails development, which is what we were working on) is VI. I was a little worried at first, but I picked up a few tricks and it didn’t slow me down quite to a crawl like I had anticipated. We were also using Cucumber to test-drive the features we were working on; this was Acceptance Test Driven Development (ATDD) in that the test represents the behavior that the software should have. I have been test-driving my Rails code at a lower level (think model and controller), and I think that there is a ton of value in moving up to a higher level to define the behavior.

As we were implementing a feature, the following problem presented itself. We’re using Webrat in the step definitions of the Cucumber tests. The way Webrat makes you click on buttons/links is slightly problematic. You can use the text or the id of the link to tell it to click. The text is probably the least permanent part of the entire link, so by relying on the text your tests are inherently fragile. By adding an id for all the links in your application, you are cluttering up the DOM. Adding an id to all your elements is a valid solution, and one that have fallen back to in the past. But this seemed backwards; the testing is forcing us to clutter up our HTML. The testing framework should be working for us, making it easier to write valid, uncluttered HTML. Perhaps we could use the href attribute of the anchor tag to click a button? Unfortunately, Webrat doesn’t support that, but it is open-source so I ended up forking and adding this feature. However, after more discussion, I’m not convinced that this approach is indeed better than using the id approach.

Ethical approach to Software Bugs

by: paul | April 8th, 2009 | 8 comments »

Software bugs are errors or omissions in the work we create. They are our mistakes as software developers. I am going to leave defining and dealing with bugs to a blog post I wrote last summer. I would like to take a closer look at software bugs, using an ethics metaphor to examine some of the rationale. For the sake of this blog, we fall into three camps: Software Utility, Software Relativism, and Software Craftsmanship.

Software Utility

“Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it.” -- Joel Spolsky

This is the camp of software utilitarianism. I understand applying this rubric in terms of return on investment might have J.S. Mill turning over in his grave, but there is a strong correlation here. According to wikipedia, utilitarianism “is the idea that the moral worth of an action is determined solely by its contribution to overall utility.”

Let’s take an example using Mr. Spolsky’s argument. We need to be able to quantify in dollars the value of Bug X. It is worth $1,000 to the company, because the ramifications of not fixing it means we only lose 2% of our user base. The cost of fixing this bug is $3,000 worth of development time. According to Software Utility, this is a no-brainer. Let the bug go, find something more important and more financially inviting to work on.

The problem here is there are so many unquantifiable variables in the equation. How do you put a dollar amount on instability? When someone tries to reuse the code that has a bug in it, you are spreading the bug throughout the system, literally, like a disease. You can deal with smaller known bugs now, or you can have them bubble up as diseases later on, where the price of fixing them will grow much higher. The software craftsmanship approach means you don’t have to get into the tricky business of quantifying everything.

Software Relativism

I have heard that, “my team doesn’t test drive their code, and so I don’t.” This is software relativism. Famous moral relativist J. L. Mackie “argu[ed] against the objective existence of right and wrong as intrinsically normative entities on fundamental grounds unsure what kinds of things such entities would be, if they existed.” In software, this is saying that whatever works, works.

Or, “We try to keep the bug list low.” Specific practices will be chosen due to their ease or convenience, rather than due to their inherent worth. If I join a team that is making money writing software without testing it, I shouldn’t judge, but do the same. There are no objective rights and wrongs, just a series of things that will work for specific circumstances.

One of the problems is when you get into a negative feedback loop. When everyone is sprinting for the finish line and there are no objective standards, you are going to end up with junk at the other end. We need a threshold of quality we will not fall below. Otherwise you will end up with a system of piecemeal quality, with parts that are stable and parts that are not stable. This is arguably worse than an unstable system. Either way, if becomes costly to maintain or just plain unmaintainable. The software craftsmanship approach avoids this problem of relativity by placing minimum objective standards.

Software Craftsmanship

I am calling the third section software craftsmanship because it fits conveniently in line with the software craftsmanship movement. It is based on the ethics of Immanuel Kant, specifically his first formulation of moral theory. It stated, “Always act according to that maxim whose universality as a law you can at the same time will.” The classic example is dealing with lying. Can lying for the sake of some other good be considered moral? Kant says to ask yourself: “If everyone lied, would the maxim still hold?” No, our society functions based on a presumption of honesty. Well, if everyone overlooked bugs or shipped with known bugs would the maxim still hold? No, software functions based on the presumption of quality. The user expects the software to work. To me, this means as an aspiring software craftsman, I can not ship with any known bugs. If you make lying acceptable, your neighbor will start to lock their doors. I am afraid that many software users have already locked their doors. So, a software craftsman can not live with bugs in their system.

I ship with no known bugs. As Thomas Jefferson says, “In matters of principle, stand like a rock; in matters of taste, swim with the current.” Shipping with no bugs and cleaning up my own messes is a matter of pride and principle. It can’t always be done with ease or convenience. Sometimes it means fixing some obscure feature you are sure no one will use.

Material Consciousness in Software

by: paul | March 30th, 2009 | 1 comments »

The following excerpt is from Richard Sennett’s, The Craftsman. All craftsmen have [material consciousness], even those who practice the most arcane art. The painter Edgar Degas is once supposed to have remarked to Stéhane Mallarmé, “I have a wonderful idea for a poem but I can’t seem to work it out,” whereupon Mallarmé replied, “My dear Edgar, poems are not made with ideas, they are made with words.”

In this same vein, software is not made with designs and ideas, but with code. Code is the raw material. Code is the only means we have to create anything. The ideas we have are only as good as the code we can write to implement them. So, the code is the object of all a software craftsman’s material consciousness. Material consciousness for the software craftsman becomes a fancy way to say that we are aware of the code at all times.

The code being the object of our craft is an important distinction, because it provides a rationale for never being too far from the code in our practices. The farther you are from the code itself, the farther you are from being able to produce an actual object of work.

When I learned eXtreme programming, this was taught to me in a series of practices. For example, using evolutionary design rather than designing an entire system before you write the code. When you design something before you write the code, you add a level of removal from thinking about the code itself. You are thinking about abstractions. An alternative, evolutionary design, tells me to write a test, then do the simplest thing I can possibly do to make that test pass. Through looking at the code, I get a feel for what the design should be. This feel lets me refactor to a better design. This design technique allows my material consciousness to not be obstructed. I get to think critically about the design of my code, but I do it in a combination of abstractions and examples, rather than just designing in the abstract.

Another example of material consciousness in crafting software is developing in vertical slices. A vertical slice is when you develop the whole set of requirements for a specific feature before moving on to another feature. When you develop in vertical slices, you are never far from changing the code and seeing the feedback in the application. You can change some code and look at the user interface, instead of having to imagine what the front end will look like. Or if you are coding the front end first, trying to visual what the entire API should look like. This idea resonates with the famous  William Carlos Williams quote, there are "no ideas but in things."

It is important for me as a software craftsman to know what the material I need to be aware of is, so I don’t remove my thought too far from it. During the software craftsmanship summit in Chicago, Brian Marick said we need to treat the code as an end in itself, not just the means. To me, this captures the idea of thinking in code.

Software Journeyman program

by: paul | March 19th, 2009 | 0 comments »

8th Light and Obtiva have partnered up to provide a journeyman program. Traditionally, a journeyman program is when a master craftsman hires a journeyman for a specific project. This journeyman lives and works with the master, learning from her/his experience and helping the master produce craftwork. A lot has changed since this type of journeyman program was prevalent.

We are going to have to alter the journeyman idea to fit into the way that both companies do business.

Our program is the first software journeyman program that I know of. It consists of sending a craftsman to the another company for a specific amount of time. It is exciting to have the opportunity to travel to another workshop and gain new experiences. Being the first of its kind, it is hard to set hard goals. I hope among them are the ability to see how a different style and thought process goes into software craftsmanship at different workshop. As a journeyman, I think it is important to be very diverse in skills and techniques, so you can use the ones which best fit your coding style and problem sets.

Our solidarity with Obtiva on the topic of craftsmanship provided a willingness to work together to make the program work in today's business environment.

So, how did this happen? Corey Haines has been traveling the countryside on his own journeyman tour, dropping apple seeds. One of those seeds was getting 8th Light and Obtiva together in a room to hammer out solutions to all the obstacles involved in starting a cooperative journeyman program. I am very thankful to Corey for being proactive in putting it together.

History of the Software Craftsmanship Manifesto

by: paul | March 11th, 2009 | 0 comments »

I would like to prelude this with an assurance that this is not the history of the software craftsmanship. I know a little of that history, as far back as Pete McBreen's book Software Craftsmanship: the new imperative and Uncle Bob's Software Craftsmanship articles. No, this is just a brief history of the document hosted here.

It started when Uncle Bob's keynote speech last year at "Agile 2008." Uncle Bob proposed an amendment to the Agile Manifesto of "Software Craftsmanship over Crap." Now, the manifesto, to my knowledge, was never changed. However, the software craftsmanship community started to become more active.

The actual manifesto started with a summit on Software Craftsmanship in Chicago, on December 13, 2008. There we discussed what it means to be a craftsman and an apprentice and so forth. We spent the afternoon discussing who the document would be written for, what the contents of it would be, if the document already existed, and if it needed to exist at all. The attendees deserve a lot of credit on getting these ideas started, and they are listed below.

On a whiteboard, we wrote the first version of the manifesto and all the attendees signed it. For a few months afterwards, we talked about it on the google group, discussing the various ideas put forth at the summit. Then, in February, Doug Bradbury wrote an email called "The new Left Side" which started to get the values and wording which was refined into the actual Software Craftsmanship Manifesto. There was a debate about how the agile manifesto and the software craftsmanship manifesto that was instrumental in moving forward with the manifesto. You can read these threads at http://groups.google.com/group/software_craftsmanship. They start with "The new left side" by Doug Bradbury and "Right side, revisited" by Scott Pfister. It was a fascinating conversation, which spawned the final language of the manifesto.

So, the question that was asked on the software craftsmanship mailing list and in the twitterverse, is "Why a software craftsmanship manifesto?" Well, if you will permit me to give an existential answer, it is because the list has 1771 signatories as of this writing. That many people now know each other as craftsmen in some context. They know they can talk as craftsmen, and hopefully move forward in our industry as craftsmen.

Let me use some other answers to the question to give another perspective.

"As of today, there are over 1500 signatures on the Manifesto. 1500 people are fighting against "crap code". Those who have been fighting "crap code" now know that they are not alone in their fight. Those who write "crap code" now know that there are 1500 people fighting against them." -- Micah Martin

"By becoming a vocal community, publishing a manifesto, beginning work on establishing principles and concrete schools of thought, we are creating a light that new developers can see. Those who are really interested can more easily find us, talk to us about apprenticeships, meet companies that actively engage in craftsmanship activities (apprenticeships, journeymen programs, etc.). In some cases, this will introduce them sooner to these ideas, hopefully saving some from the frustrations they can face in a different situation." -- Corey Haines

• Dean Wampler
• Matt Segvich
• Dave Hoover
• Joseph Leddy
• Jake Scruggs
• Robert Martin
• Micah Martin
• Paul Pagel
• Brian Marick
• Eric Smith
• Doug Bradbury
• Jim Suchy
• Craig Demyanovich
• Raymond Hightower
• Corey Haines
• David Chelimsky
• Scott Pfister
• Eric Meyer
• Denny Abraham
• Matt Blodgett
• Zach Dennis
• John Hwang
• Mark Van Holstyn
• Scott Roth

Observing a Craftsman

by: paul | November 17th, 2008 | 1 comments »

“Knowledge can be communicated, but not wisdom. One can find it, live it, be fortified by it, do wonders through it, but once cannot communicate and teach it.” –Hermann Hesse, from Sidhartha

My path in becoming a craftsman was not through conventional academics. I did get a Bachelor degree in Computer Science. During those years of learning, I was taught a lot about how to learn and how to communicate, but I learned nothing about how to practice my craft of software. I learned how TCP/IP works, how registers are able to do math . All of this is interesting and some of it is useful for a broader view of computer interactions as a whole. None, however, taught me about developing software as a craft. I did some programming, which is a prerequisite for any kind of software development.

My real learning began after school. Learning software as a craft was not done in books. It took being around journeymen and master craftsmen to learn the way they think. Observing their idiosyncrasies and approach to a problem is part of the learning. Much of the wisdom is tacit. For me it is watching the way my mentor approaches a story. The way a craftsman sees a problem and digests it, without hurry, and finds a satisfactory solution. Then they write code, introducing faults and fallacies the original solution could not have predicted. Finally, a meticulous approach to improve each fault in the code. The whole time demanding perfection, without ever hitting it. This is the good code I strive to write. I can’t learn that by looking at the solution though.

These are observations of behavior and intent, not of actions. For example, I have read about Test Driven Development, and it has made my job easier. For awhile after I learned it, I wrote a lot of simple assertions, almost reverse engineering my production code in my head to figure out what the test code would look like. However, the practice itself became ten times more valuable when I saw my mentor use the tests to design their API. They would say things like “what do I want this to do” or “that doesn’t feel right, lets rename the method to this”. Those insights into the thought process provide me with the experiential learning it takes to further improve my craft. When I started thinking about TDD in a similar manner, it allows me to clean up my code and know it still works, refactor my code into easily extendable solutions, and it gives me the confidence to experiment with the aesthetics of my code. I couldn’t fully learn that from books alone.

This is why it is so important to apprentice as a software developer. There are many things about development that I only learned through watching the behaviors and actions of the craftsmen I admire. To me, these are the things that open up the software world to gain wisdom. For example, to be a better developer is not to learn a new language, but to have the wisdom to learn and understand any computer language, which requires you to learn new languages all the time.

Kata: Langston's Ant in Ruby

by: micah | November 13th, 2008 | 3 comments »

I’ve recorded my Langston’s Ant kata for all to see.

This particular kata, with slight variations, has been in front of an audience twice before. Once at a Software Craftsmanship group SCG meeting and again at RubyConf2007.

On both occasions I asked the audience to evaluate my performance on a scale of 0-10, 0 being the worst kata you can imagine, and 10 being the best. At the SCG, my performance was longer than the screencast because I didn’t use the instance_eval trick and wrote multiple case/when statements. It resulted in much more code as well. Honestly, I felt the kata dragged on a bit too long which is why I shortened in subsequent performances. Despite this, the SCG audience gave me an average score of 8. At RubyConf, the kata was almost exactly like the screencast and it earned me an average score of 7.

Now coming from an audience of dedicated Ruby developers, I’m quite pleased with my score. Here’s some of the feedback I got…

• Use of instance_eval: -1
• First test, going from compile error to passing tests: -1
• Refactoring on with red bar: -1 (not repeated in the screencast)
• Non-idiomatic is_black?: -0.5 (fixed in screencast)
• Steps are too big in between tests: -1
• …

I find this feedback immensely valuable and thank those who took the time to provide me with it.

In martial arts, the techniques performed in kata are not always by the book. There is an aspect of art, creativity, and entertainment. At several points in my Langston’s Ant kata I intentionally decided to bend the rules to enhance artistic and entertainment values. I leave it up to you whether I made the right compromise or not.

After watching the kata, leave a comment with your rating and any feedback you have for me. I thank you in advanced.

Ruby Battleship Sparring Tournament

by: micah | November 8th, 2008 | 0 comments »

Yesterday in my talk at RubyConf2008, I announced the commencement of the Ruby Battleship Sparring Tournament.

This is an open tournament. All are welcome to participate.

Agile in Buenos Aires

by: micah | October 29th, 2008 | 0 comments »

Last week I attended Agiles2008 in Buenos Aires, Argentina. It was a fun, high energy conference. The highlight was a heated panel discussion at the closing of the conference. On the Panel was Matt Gelbwaks, myself, Tom and Marry Poppdieck, Dave Nicolette, and Tobias Mayer. Tobias has already posted a blog about the event. So that my opinion is not misconstrued, I'll share it with you here.

The future of Agile is Software Craftsmanship.

Software is a young industry and we're still discovering more about it every day. Yet, it has it's origins in electrical engineering. So it's seems that, at it's inception, people assumed software was a form of engineering. And to build software systems should be no different from engineering any other creation. Take a bridge for example. Before building a bridge, you have to analyze the bridge requirements. How long will it be? How much weight must it hold? etc... Once the requirements are understood, you design a solution. Build to-scale models that you can push and stress to make sure the design hold up. Then, once you have a solid design, can you begin construction of the bridge.

It's waterfall. Waterfall worked for engineering so waterfall was applied to software. We know now that waterfall doesn't work. Agile, is a realization that software is not a form of engineering. Agile is a realization that software is a craft.

I have been to every North American Agile conference since the very first, and I have noticed a trend. In the first conference in Charlotte NC, laptops were open on every table, around every corner, with someone or a pair of people writing code. In many of the sessions, people were writing code or talking about it. This is the conference where people were bragging about their Ward number (0 if you paired with Ward Cunningham. n + 1 if you pared with someone with a Ward number of n.) and desperately trying to improve it. It was truly a conference about software. Over the years, less and less coding could be found at the conferences. This last year, at the conference in Toronto, it was abysmal. Although there was some good content, I felt like the conference had been taken over by Scrum Masters. It was no longer a conference about software development. It had become a conference about project management, people management, and Scrum. This makes me sad.

In middle ages, if you were a lord and you wanted to build a cathedral, you found a master craftsman. The master craftsman recruited other craftsmen and together they constructed amazing buildings that still stand today. These craftsman were passionate about their work and cared about creating great buildings. That is what made it work. They didn't have scrum masters telling them what to do or cheering them on. The great work they did is a tribute to their craftsmanship.

The future of Agile is Software Craftsmanship. Developers out there need to realize that software is a craft. As such, developers should strive to become craftsmen; strive to learn more about software; strive to write better code; strive to build the best software possible. The software you get from a team of true craftsmen will be unrivaled. It is the goal and quality within that drives a team of craftsmen. They'll find a way to overcome any obstacles and adapt to any changes.

Software Craftsmanship Group

by: micah | October 2nd, 2008 | 0 comments »

I'm pleased to announce the inception of the Software Craftsmanship Group. http://groups.softwarecraftsmanship.org The first meeting is October 13th at 7pm in 8th Light's office. Hope to see you there.

Customer Interaction

by: | September 23rd, 2008 | 0 comments »

At 8th Light, they follow a practice of training people through an apprenticeship period. As it is nearing the end of my apprenticeship, my mentor has asked me to write a blog talking about one thing I have learned during the course of my apprenticeship. For me, the one skill that I learned the most about was the one skill that needed the most work in the first place. The main thing I learned was that I was writing software for others. Similar to that idea came the need for increased customer interaction and learning how to interact with people in general.

Prior to working at 8th Light, almost all the programming I had ever done was either for myself, or for school projects. In the first case, I was my own user, so there was never any issue in communication there. And for the second case, the requirements were almost always very clearly drawn out(and not likely to change). Again, not much room for error. Once I came to 8th Light, I was forced to write code both specified and to be used by someone that was not myself. This was something new to deal with. For at least the first month or so, my thought process was for myself. It wasn't until I came to that realization that I was able to change my thought process. There was not one single event that made me learn this, but it was something learned over time. When starting a story, once the requirements have been approved, I don't try to change the story. Even if I don't agree with the desired functionality, it is what the customer wanted, and that's all that matters. And now, when I finish a story, I take the time review the requirements and make sure it completes all the requirements that the customer specified.

In order to provide a high quality product for another person, you must maintain a high level of collaboration with them. Without talking to them, you will never be able to guess what they want. So, in going along with the first lesson, I also learned that a lot of customer interaction is important and any issues that arise should be addressed quickly. One event in particular occurred that helped me realize this was the week leading up to one of our releases. It was around this point that the customer decided to begin some testing of the system and uncovered a number of bugs. There was some concern as to whether or not all the bugs were being kept track of in some way, and this added stress to both the development team and the customer. It wasn't the bugs that taught me anything, but the manner in which Micah handled them. After our iteration meeting, he called attention to the problem. He didn't blame anybody, but just said that something needed to be done to fix the problem and even proposed some possible solutions. It was the high level of communication between the development team and the customers that was valuable to me. This made me realize that you have to address problems quickly, and it helps to offer multiple solutions to a problem. The customer also seemed to appreciate that we brought the issue up, and partly because of this week of bugs, we introduced a new bug tracking tool to our process.

I also began to learn that if you have a question about how something is supposed to work, sometimes the best solution is to just ask the customer. At one of our recent iteration meetings, the customer mentioned functionality that they expected to be in a completed story that had never been discussed. We realized that there was not enough feedback gained from the requirements, so we altered our process to account for that. Now, after determining the requirements, we bring them to the customer and discuss them in person. This is something we just began, but it already has shown signs of success. The customer has actually come to us to discuss the requirements for some of the stories. It is because our team values communication that we were able to improve our process.

Learning these things has already helped me work more productively. If I have a question, instead of trying to spend too much time reasoning it out my own, it can be much faster to either go to the requirements or directly to the customer. During the course of my apprenticeship, I also learned a lot about coding but nothing was as important as what I learned about human interaction. This is a lesson that has definitely changed my mentality towards coding and will hopefully improve my skills as a professional software craftsman.

Definition of Software Craftsman

by: micah | September 21st, 2008 | 5 comments »

Craftsman Clarification

There has been some discrepancy in the use of the term “software craftsman”. Rather than going into details about various uses of the term, I’ll just clarify what I believe it means.

software craftsman n. A man who practices the software craft.

There are a few points to make about this definition.

1. “software craft”

A craftsman believes that software is a craft. This is important because not everyone believes this. A craftsman takes pride in his work an strives to do the best job he can. He believes that writing good software requires skill and careful attention. That software is not something that can be manufactured nor can it be delivered faster by merely adding more bodies.

2. “practices”

A craftsman practices his craft, always striving to become more skillful, to produce better software.

There are traditionally 3 stages of craftsmanship:

1. Apprentice
2. Journeyman
3. Master

No matter which stage one may be in, as long as he practices software as a craft, he is a craftsman.

3. “A man”

Technically the term “craftsman” is gender specific. Women are just as capable of software craftsmanship. Indeed, I’d like to see more software craftswomen out there. In an effort not to alienate anyone we should use the term “software craftsperson” more liberally.

Update: There’s a movement afoot to make the term “software craftsman” gender neutral. Feel free to comment below.

I’ve checked with the book “Software Craftsmanship” by Pete McBreen to see if it conflicts with my definition. Although, he uses the term “software craftsman” ambiguously at times, he is careful to use the term “master craftsman” when referring to craftsmen at the height of his craft. This is in line with my definition.

I hope this serves as a reference for my use of the term. People should not think me presumptuous when I call myself or my colleagues craftsmen. I mean only what I describe above.

Own Your Tools

by: doug | September 15th, 2008 | 2 comments »

I spent a lot of time with my grandpa growing up. He has spent much of his retirement ‘fooling around’ in a workshop he built on his slice of Pike County, Illinois farmland. From a very early age I spent a lot of weekends and entire weeks of the summer as Grandpa’s little helper. I’d work on the things he was working on while helping and learning. When I was about 7 years old, I was helping Grandpa refinish a dresser. I had a flat paint scraper in my little hands and was trying to dig into the layers of flaking paint that gripped the dresser. I really didn’t have the strength to get under the paint with that big blade, so I turned the tool on edge and started scratching deeply into the wood. I was making progress now, but tearing the heck out of the surface. Now in Grandpa’s version of this story, he says that when he saw what I was doing he corrected me too harshly and sharply and later found me teared up in a corner of the workshop sorry for what I’d done. I honestly don’t remember being that hurt by his rebuke, but I do know how to use a paint scraper and dozens of other tools properly because of that time I spent ‘helping’ grandpa in his shop.

As software crafts-people our tools are other bits of software. We spend every minute of every day using software. Our editors, compilers, interpreters, source code repositories, IDEs, debuggers, and test frameworks enable every stage of our work. Everything we do to create and add value to a software project requires some other software tool to make it happen.

At many of the places I’ve worked, the developers have a laundry list of complaints about their software tools. Often, teams develop elaborate rituals and incantations to dance around the shortcomings of their tools. “Before you check in, copy this file over there then add a note to that file then spin around in your chair three times and your check-in should succeed.” Now I agree that there are lots of poorly designed tools out there. Some tools do things that just don’t make sense and others crash all the time, but I have a challenge for us as software crafts-people: Own your tools. Tools are software, you are a software crafts-person. You can find or make a tool to do anything you need.

Groups decide to invest in a tool, often at great cost, but very few people end up understanding or even using the tool. The tools usually gets blamed for its shortcomings before anyone has really made the effort to get them to work. They give up on it far to early. Own your tools. Understand everything it can do, and if it isn’t enough, find a way to make it do what you want.

One of the cool things that happens is that investing time in your tools may give you the chance to explore a new language. One of our goals as craftsmen at 8th Light is to learn a new language every year, but often its hard to justify the time spent in a new language when you are heads-down in a project. Using a new language to create a tool for yourself may give you just the excuse you need to spread out a bit and learn something new.

Is it really worth it? Can the time spent writing “non-production” code really be justified? Let’s take a task, say the creation of a new class in C++. Most people when creating a new class, will open up the last class they worked on, copy the entire thing, paste it into a new file, delete all the methods and data, then do a find/replace on the class name. There are probably a few comments that need editing, the revision history needs to be cleaned out and maybe there is a comment header or footer that needs to be updated. This entire process could take maybe 2 minutes. It hardly seems like it’s worth automating. Except … Wait! It won’t compile, because you mistakenly didn’t remove the parameters from the constructor and the compiler can’t resolve the dependencies. This is a manual process, so it’s error prone. So you spend maybe another 3 minutes getting the thing to compile. Then we need a test harness so you do the same copy, paste, delete, find / replace process. 8 minutes later we have a new class and test harness and we are ready to start working. The hour or so investment to build a tool for yourself will surely be worth it now. If you share your work with the rest of your team and suddenly everyone is saving 8 minutes every time a new class is generated, you might have your hour back by the end of the week.

Some IDEs and editors have some class generation utilities for you. This may get you part of the way there, but it probably won’t put your company’s header on the top or put in your source control keywords. It may not make your destructor virtual or create a private copy constructor to start like I like to do. The tool doesn’t do exactly what you want. Own your tool. You are a software craftsmen. You can create software that generates a class for yourself. If you are in an editor that supports macros or bundles, you may be able to implement the tool in the editor’s macro language.

In this spirit, the craftsmen at 8th light have contributed to open source software tool projects for several years. Micah is the author of the widely used Fitnesse acceptance test framework and Eric has taken over the management of Selenium on Rails. Micah’s also been working on a whole new development framework called LimeLight. We love open source tools because they let anyone own the tool.

Grandpa used to make things out of sliced walnuts. He’d glue together little baskets or crosses and fill the walnut cavities with colorful beads. As you can imagine, a walnut is a pretty difficult thing to slice. At the very least it’s awfully dangerous to get your fingers that close to a band saw. Grandpa showed me a while ago the tool that he made to save his lower digits. It’s a pretty simple block of wood with a half-walnut sized divot carved out of it. It was a woodworker using his woodworking skills to create (and own) a tool for woodworking.

If you’d like my class generator, you can have it here. Chances are, it won’t do exactly what you need it to do, so … own your tool.

Maturing the Manifesto

by: doug | August 27th, 2008 | 1 comments »

There has been an interesting discussion happening about adding a 5th value statement to the Agile Manifesto. Uncle Bob Martin proposed this addition earlier this month at Agile 2008. The proposal has centered around the idea of craftsmanship or professionalism. In his keynote, Uncle Bob proposed that we value “Craftsmanship over Crap” and in a later blog post suggested “Craftsmanship over Execution.” I strongly agree with the call for more professionalism and craftsmanship amongst software developers.

The original value statements are comparative. The things on the right still have value, but the things on the left are valued more. “We value working software over comprehensive documentation.” I think what has happened is that we have found something we value MORE than “working software.” We value well-crafted software over working software. It’s very important that the software works, but even more important is that the code is clean, that it is easy to read and therefore easy to change.

I’ve been reading “The Craftsman” by Richard Sennett. I’ve found a great definition of craftsmanship. “They are dedicated to good work for its own sake” (Sennett 20). A craftsman is driven by quality. Quality software is software that both does what is is supposed to (works) and is clean and easy to continue to work with.

This has me wondering about the other 3 value statements in the manifesto. Are there things that we value more than those things on the left hand side? We are learning day by day better ways of doing software, so what have we learned since 2001? We have a good idea about how Craftsmanship shapes the way we think about ‘working software.’ How can the idea of Craftsmanship change how we think about ‘responding to change’, ‘individuals and interactions’, and ‘customer collaboration’?

Sennett, Richard. The Craftsman. Yale University Press. New Haven and London. 2008

That's not Agile, Live

by: doug | July 26th, 2008 | 0 comments »

About a year ago, I wrote That’s not Agile. The idea has grown a bit since then and I will be presenting it as a workshop at Agile 2008. If you are coming to Toronto, please consider coming to check out the workshop. It all happens Thursday morning (8/7) at 8:30 am.

In this workshop we’ll be looking at the differences between the practices of Agile and the values/beliefs in Agile. We’ll explore questions like “What makes a practice Agile?” “Is it your practices that make you Agile or you beliefs?”

I’m especially hoping to find some people in the room who have been on a team that has struggled in transitioning to Agile.

See you in Toronto!

No Tag Backs

by: eric | July 3rd, 2008 | -2 comments »

Well Micah tagged me, and if I look at these XML request/responses for another hour without a break I’m going to pass out into my keyboard. Here goes.

How old were you when you started programming.

I had a Texas Instruments computer thingy that I got for my 6th or 7th birthday, somewhere in there. It played these educational games, but I noticed one day that if I didn’t put a cartridge in it a blue screen came up with a cursor. It had an instruction book and I would basically type in the programs verbatim, then do little things with it like change a color or a line. Later I had an Atari XE and it did the same thing, so I made the same little guessing game in it just like the one I made on the TI. Realistically I didn’t write anything of use until high school though.

Interestingly, perhaps only to me, my version of Hello World for the iPhone SDK was a guessing game.

How did you get started programming.

I guess that was the real answer. I played with my dad’s computers all the time but didn’t consider it as a career until I was about 16 or 17, when I realized I could probably get paid for it. Up until then I wanted to be a sports journalist. So I went to school so I could found my own game company.

What was the first real program you wrote?

What counts as “real”? The guessing game? Making horizontal lines appear on the screen? I wrote a bunch in Basic and Pascal for homework assignments, and like Micah had one of those TI calculators. The first specific one I can recall was a text-based adventure game I made for a homework assignment my freshman year. It was based on the Haymarket Bombing

What languages have you used since you started programming?

Pascal, C, C++, C#, COBOL, Assembly, Perl (but I won’t admit it), Java, Objective-C, Ruby, Javascript, Lisp, VB, Erlang, and I just wrote Hello World in Smalltalk (Squeak).

I too doubt I could write Hello World in most of those languages, and wouldn’t put them all on my resume. It’s funny because I probably would have when I came out of school, since I didn’t know the difference between “familiar with” and “able to write some code with”.

What was your first professional programming gig?

I started a web design company in college, which employed me and myself. I had two clients, one of whom paid me in Kung Fu lessons.

If there is one thing you learned along the way that you would tell new developers, what would it be?

Find great people to work with. If you’re the smartest person in the room, you need a new room, because if you’re not growing you’re dying. This is tricky when you’re new, since you don’t know a great developer from a tree stump, but take a look at Micah’s tag list. It looks like the list of authors in my library.

I would also tell them they should come to work for me as my apprentice, unless they weren’t any good. Then they can work for Jim.

What’s the most fun you’ve ever had programming?

Working with the team I work with now is fantastic. I also had a great time working Agile 2007 as part of RailsFest, and I’m looking forward to doing the same thing on the Live Aid stage this year.

Up Next

Sadly I don’t know many developer’s who keep blogs, so I’ll just echo Micah’s list and tell Paul, Jim, Doug and Matt they’re next.

Apprenticeship month one report

by: paul | June 30th, 2008 | 0 comments »

8th Light has an apprenticeship program whereby an 8th Light craftsman will mentor an individual for three months. During that time, the craftsperson becomes responsible for a single apprentice. I am one month into a mentorship with an apprentice. This blog is about observations I have made about myself as a mentor.

Curiosity

He asks me questions that I wouldn’t ask myself. I had him do an exercise about Law of Demeter , to find Law of Demeter violations in my code base. He found something like:

Law of Demeter

“Ted Williams”.to_s.strip.upcase

He was counting the periods, which is what I explained is often good measurement of Law of Demeter violations. Yet this is not a Law of Demeter violation. Each one of those methods returns itself (a string) in a changed state. It is not a string of implementation details- this example is just changing a single object. The pivotal piece of information is that all of these methods on string return the string itself. Also, is anything inside of Ruby core language capable of Law of Demeter? It is unlikely to change, and is there a problem being coupled tightly to your language?

I sometimes get desensitized to the original premises of good development. When I first learn something, I remember the example of the rule more than the value of the rule. The value of learning about Demeter is rooted in encapsulating logic in such a way to hide implementations from an object’s clients. When I first learned about Demeter, all I could do was point out violations. The more I developed, the more it was internalized as a guide for a higher development idea. I want to keep my modules as decoupled as possible. However, that notion only came with development experience. Now I don’t think in terms of violations or non-violations of Demeter when I read a piece of code. It is just ingrained in my developmental context that I should develop my modules in such a way that they are autonomous. This weeds out most Law of Demeter violations by itself. Bringing these premises back up in my development as a craftsman gets my curiosity started. Like a good song or piece of writing, every time I come back to it, I take something different from it, because I am in a state of constant change.

Teaching

Sometimes I forget how important teaching is to the craftsmanship model, because I am still an extreme novice at it. It is one of the steps involved with internalizing development skills. When I pair with my mentor, I am constantly amazed at how he skips steps in the development rational process. Instead of following a linear thought pattern to a solution, it seems there is a giant shortcut in the rational processes I go through. That gap is a lookup table of solutions in his head. It appears so easy and effortless. Teaching is part of a formula that has given him a development context that is superior to mine. The more I am able to teach, the more I internalize the ideas about development.

There is a baseball story from about a year ago. Greg Maddux was warming up before a game and his catcher exclaimed to the pitching coach, “I bet I could catch him with my eyes closed.” Well, after much effort, they convinced Maddux to give it a shot. The catcher was going to call his pitch, then close his eyes. When the ball was about to hit his mitt, the pitching coach with his eyes open was going to yell “now”, whereupon the catcher would squeeze his glove on the ball. Well, on the third try, the catcher caught the ball. The degree of difficulty of the exercise is incredible, but Greg Maddux had spent so many years internalizing the mechanics of his craft that he could effortlessly hit the catcher’s mitt. There probably are only a few pitchers in the long history of baseball who could match that exercise. I am not anywhere near that kind of skill in development, but that is my goal. When you get the mechanics of your craft to be intuition, it frees your mind to think about and solve larger problems. I have been fortunate to spend time with enough great developers to see this mastery in action.

Communication

For me, what is special about teaching is the commitment of thoughts to sound. Forcing something outside of my internal monologue always changes it, even if it is a small change. When I explain something, I often have to explain it multiple ways (this is telling of my communication skills, not of my apprentice’s learning skills). So, the more I am forced to answer questions on the spot, the better I get at quickly thinking through a question and giving a good answer. This dialogue is another one of the mental exercises which translates into my everyday development. It makes me a better pair programmer, better presenter, and better writer. Being able to accurately explain a problem and a solution using the language of software development is a very important tool in being a successful craftsman, and a tool that I fight uphill to improve upon. When I go to a talk at a conference and the presenter hits the problem and solution perfectly, it is a wonderful experience. The same is true when a team member can explain a solution in such intuitive terms that everyone gets it immediately.

Apprenticeship for me is as much about internalizing and expanding my own skill set as it is about expanding my apprentice’s.

Some Thoughts On Software Defects

by: paul | June 24th, 2008 | 2 comments »

Software defects are a part of software. This is a negative subject, but I don’t want to seem like the software I write is full of defects and bugs. This blog is addressing how I have seen teams turn a roadblock into a success. I have read and heard at conferences about teams who take small failures and create a culture of failure around it. Following are some examples of small failures I have seen and great successes built around them. Sometimes I see small failures as a path to larger positive culture changes.

I think it is safe to say all software that is used and sufficiently complex has defects. There are many reasons for the defects. Here are a few of the defect situations I have been in and how our team solved them.

I think the important part I learned after evaluating these is that resolution of these situation needs to be fast and high quality. They need to make the project better off at the end of their resolution. Success for the customer is the only true result of a project, and defects may not be the most ideal path, but they must lead there.

The speed is important, but it doesn’t mean I should rush a solution and throw it in as soon as possible. To me it means giving the defect the red carpet treatment. I am trying to capture craftsmanship in the face of adversity. Every project has its ups and its downs, and a craftsman will take pride in success through any obstacles. Instead of making defects a slippery slope downhill, they are one step back and we take two steps forward.

Bugs

Bugs are a part of every piece of software I have written. That statement sounds a lot worse than it is. I have worked on systems where the requirements are dramatically changed week to week (which can be pretty exciting). There are situations I didn’t take into account, or some behavior I didn’t imagine until a real user started hitting the system. Now, as a developer, I do more mental exercises and think thoroughly through my solutions as I get more experience. This has never made my code bug free. For that reason, my team needs to know how to deal with bugs (I am fairly certain I am not the only creator of bugs).

Here is a line from the Pragmatic Programmer book, “It doesn’t matter whether the bug is your fault or someone else’s. It is still your problem.”

So, the team has a bug list. We list out the bugs as a todo list in basecamp, so they are not so formal they can be forgotten about. Then we try to address them and work on new stories. This worked well enough until there was a big release coming up and our customer came back to us with a big list of bugs. We put them on the list and continued to fix them, as well as work on stories. They were getting completed, but there was never an empty bug list. Then, the customer (who can directly add/edit the bug list) started writing priorities to the bugs. This one is HIGH priority. This one is CRITICAL. This one is IMMEDIATE. I make the suggestion “We need some real tool to manage our bug list,” because I can’t fit all this in my head. There isn’t that much room up there and I need to use it wisely. One of my team members suggested maybe it wasn’t the craftsmanship way to have ANY bugs shipped. I was trying to solve the wrong end of the equation. So, the team lead put forth a no bugs policy that we all agreed with.

You can not pick up a new story unless the bug list is empty.

This made sense to me, but I had reservations about a small/insignificant bug taking priority over a story that is important. To date, this has not happened, and the bug list has stayed near no bugs. That doesn’t mean less bugs are found, it just means they are fixed, and the code is refactored to prevent a future occurrence. Most importantly, some tool to track bugs never made it into our system. That was an idea which would have desensitized the team mentality to bugs, whereas with our policy now we are very sensitive to the issue of bugs. Challenging the craftsmanship of the team members that buggy code is something you should take personally was the right choice. Bugs got a first class ticket to termination in our system.

Now, the definition of a bug versus a small feature enhancement is a fine line. I know I have failed to define it well, and that might contribute to what gets called a “bug”. Often times, the urgency in the customer takes up more mental space than me thinking through it, looking up the acceptance criteria for the story where it was implemented, and going back to the customer and saying, “No, that was clearly not a defined scenario, we are going to need a story to turn that button green.” Now the next time, it is more than turning a button green, but the precedent has already been set. All I have been able to do is to strike a balance based upon how much effort it would take to make the bug/feature enhancement work. If it is a lot of effort, I will double check the bug to make sure it is a bug. If it is, I fix it. If not, I will push back to the customer to write a story card.

Production Support

Once a system goes into production, support begins. Following along with one of Paul Graham’s ideas, we have the developers doing the production support. We are the ones who wrote the system and know the system the best. When I look at a production support request, I can not only solve it, but make sure it doesn’t happen again. Or if it does, make sure it is easy to correct.

So, during our first deployment of a system, a single team member stepped up as the “production support” developer. I don’t know if he embraced it or was cornered to it, but as a craftsman, he took the responsibility and ran with it. As further systems were released, he would sometimes be doing an entire day of production support. Production support can be a lot of debugging and fixing data, which can be fun, but more times than not is tedious and rhythmic. Often times when I saw a production support email, I would look to the “production support guy,” who could fix it in about half the time I could. This seems a lot like a silo to me. Everyone should be able to do production support on any system. I should have to, because it is a perspective of the system that is important to have.

In response to this, we came up with a system of triage. Each day of the week is assigned to a specific developer. If a support item comes up, it is the job of the triage developer to respond to the client/customer we are working on it. If it addressed to a specific person, they will inform them. Otherwise it is on the triage developer’s shoulders to fix the support request before they continue their work for the day. This ensures the client always has an open line of communication with a developer. An email never slips through and doesn’t get addressed. There is clear responsibility to who should be addressing the support item. I know the “production support” developer is in favor of this system. As well as the customer, they ask who the triage is for the day and have no qualms about interrupting their work, as they should.

Communication and Managing Expectations

Recently, I did some integration work with a third party vendor. They were developing their side of the integration at the same time as us. Not wanting to slow development and wait for their functionality, we decided to write a mock server and integrate with the host according to the spec from the third party vendor. We received a story from the customer for that and proceeded to make the client for the third party system calls. We finished our story. In the demo portion of the iteration planning meeting, we could only demo against our mock server. This caused some nervousness in the customer (rightly so). I replied, “Once their side of the system is done, we should be able to send our calls across.” Then we received three more similar stories, but different system calls. We did them, removed the duplication and felt really good about the job we did. The came their test server.

Nothing worked! There were all sorts of communication problems, questions about who implemented the system to what spec, and political questions. Despite us thinking we were in the right, the stories were signed and the customer said, “Well, you said this would work.” At first, I tried to communicate the reason why it didn’t work, and how we can move forward. We came to spend a lot of time on this, and the team felt the integration should be its own story. The customer pushed back, “Well, you said this would work.” There was some tension, because both sides were right. We didn’t believe it was our fault it didn’t work (neither did the customer), but we told them it would. Rather than let out the righteous indignation I was feeling, one of the team members mentioned.

“We should not have assured you it would work.”

That one line brought the real problem to the front for both sides. We didn’t know whether it would work or not, just that we wrote the right code to the specification we had at the time. That code by itself has no value to the customer without it working, though. Once that line was said, everyone in the room sat for a second, then understood. The expectation over defect versus behavior was out of sync. A little ownership over the defect was all we needed to ease the tension and move forward. It is unproductive to get stuck in a stalemate of expectations. When in doubt, the customer is always right.

Promises Promises

by: eric | May 17th, 2008 | 0 comments »

“Under Promise, Over Deliver” (origin unknown)

“How are you going to get a reputation as a miracle worker if you tell the Captain the actual amount of time it will take?!?!” Scotty on Star Trek

I used to think the first statement was a just a more cynical restatement of the second, which is just a con job. Tell the boss you can’t have it done until Tuesday, finish on Friday, play golf Monday morning and deliver Monday afternoon. Everybody wins right? Except it’s fundamentally dishonest. Lately I’ve come to realize I do the first one every day, and I hope never do the second.

I have three step-children and I rarely promise them anything. It’s not because I’m a horrible father, but because a promise is a fundamentally special thing. I promised my wife I’d stay with her until the end of time, now that’s a promise. If I promise I know damn well I will do what I said, and I can’t have excuses. Now I’m naturally a very busy and easily distracted person so I know that if I promise too much, I’ll deliver a lot of disappointment. Instead I say “maybe” because it’s the honest answer. There is a huge difference between “I promise” and “I’ll try”, and I doubt “I’ll do my best” would have been an acceptable answer on my wedding day.

So what the heck does this have to do with development? I was thinking about iterations, and how the stories taken on are really a promise to the customer, but we don’t always treat them that way. A lot of teams, including at times our own unfortunately, instead Over Promise and Under Deliver. It’s usually done with the best of intentions because the customer wants more stuff done. You know what? My kids want to go to Dunkin Dounuts tomorrow, but I don’t know if I can take them so I won’t make a promise. We should look at our iterations the same way. I’m not talking about padding estimates like Scotty does, but what I’m talking about is avoid the traps of wishful-thinking when estimating stories. Specifically three things I see all the time.

• The Talk Down

The talk down usually happens when one or two team-members are out of sync with the rest of the group on the high side, but can also happen when the team’s points cover a range from small to large. Higher estimates mean higher risk and yet the lower estimates usually win this “battle.” There are two kinds of ways team members (and sometimes customers) encourage other developers down from their estimates, one good and one bad. I’ll illustrate with two stories where I was out of step with the group.

Right after I joined 8th Light we had a store that involved converting text to base64. I was inexperienced with Ruby and hadn’t done this before, so my estimate was higher than the others. At some point somebody said, “Eric that’s a method that’s built into ruby, it’s one method” and I sheepishly shrank my estimate. Hey I used to be a C++ programmer, cut me some slack! The point is this time being talked down made perfect sense. I didn’t know something, somebody told me the answer, and we fixed it.

Much more recently we had a story that involved showing the difference between two objects in the database. In this case I was again much higher than the group. I explained I had no idea how we would do this in a way that would satisfy the customer, but the team thought using the Unix diff tool on the already existing XML Output would be fine. With something feeling wrong in my gut I reluctantly brought down my estimate. A few minutes later Micah and I started on development, and discovered the problem. A few small changes to a product resulted in four pages of indecipherable XML differences. The story was scrapped, fortunately quickly before any time was invested in it.

Now what was different between the two times? In the first there was a concrete and clear way that my estimate was wrong. Yea! In the second there was still an icky feeling in my gut, yet I budged. Why? Because I don’t want to hold up my team, I don’t want to look stupid, and most importantly I failed to articulate my concerns with the approach given. You see for years I worked with InstallShield Developer, and for a while now they’ve saved their file format for projects as XML. But when two people attempted to work on the same file, then merge, it was almost always a nightmare, and this was with tools that just did diffing like Araxis Merge. Our quickly done tool to solve an immediate business need had little chance of success, but I was uncomfortable saying so. The moral: Don’t let yourself be talked down unless you really feel talked down. The team wasn’t wrong for stating how they felt, I was wrong for failing to articulate the issues I had.

• The extra points

Occasionally as a team you really want to impress the customer, and they’re in a hurry. So maybe you take on a few extra points. I don’t feel this needs much explanation, don’t “hope” you can get it all done. Use your velocity, trust your estimates, and KNOW you’ll get it all done.

• The “Ambitious” Iteration

Sometimes your iteration feels just…off. You’ve taken on the same number of points as the previous iteration, but it feels in your gut like it’s too much. Now this is where the promise kicks in. Would you promise your loved ones something that in your gut you just didn’t feel like you could deilver? Than don’t do it to your customer. When the iteration feels ambitious try to put it in concrete terms, maybe you’ve been the victim of the “talk down.”

Remember a promise is a very important, even sacred, thing. It should not be taken on unless you are absolutely sure you can do it. Try saying to yourself before an iteration, “We promise to get all this done.” If that causes a shiver to go down your spine there’s a good chance you really hope you’ll get it all done, and maybe should take a bit off the board rather than be proven right later.

Agile Production Support: Final brush strokes

by: paul | February 18th, 2008 | 3 comments »

There is no perfect software. At least I have never seen it. Bugs and minor feature changes are indications people are using your software. Real users hit a system in ways that no control group can, and on non-critical applications, this is the best way to test your software. Let people use it and see what happens. This is goes in line with the agile philosophy of release early and often. Get your application out there as fast as you can, so you can mold the finishing touches around the real users experience rather than a faux-environment.

There is some conversation about what is and what is not a “bug” in the software world. That is not a conversation I would like to partake in here, so lets call both bugs, integration items, minor feature enhancements, and things that fall through the cracks of development tweaks. It doesn’t matter what the nature of origin is, these are all things that MUST get done.

After the release of one of our products, a load of tweaks came in from the customer. As proud craftsman, we decided tweaks were our responsibility, and we would take them on in addition to our normal iteration. So we started to do them, to the detriment of our iteration. We accomplished only about half of our iteration’s velocity.

The next iteration, much to our surprise, we were twice as busy with production support. This is about the time that a developer looses a little faith. What did we miss? Is this high quality software we are writing? So we lost even more velocity when it came to iteration 2 after the release. Also, the customers were now unable to accurately plan new features moving forward due to an unstable velocity.

It is so hard to predict or estimate production support and tweaks. However, we needed to be able to so that the production support didn’t leave such a footprint in the project. It felt and looked like we were not getting very much done, even though we were working harder than usual. It was the time being put into a vacuum and being unaccounted for that was troubling the project. It also had a negative effect on the morale of the team.

We came up with a card, we call the “Production Support Card.” The amount of the iteration’s velocity this card took up was calculated by the amount of time we spent on production support the previous iteration averaged with the amount of time allocated for that iteration(sound like a familiar formula?). It is added as a card to the next iteration. If the developers only spend 6 of the 10 points on production support, it is expected that they will complete 4 points worth of stories, which are automatically entered in the iteration. For the first iteration where it becomes apparent that we need a production support card, we set the point value of the card at 0 and track how much time we spend, bumping out of the iteration the least important stories if needed.

So, what does this tracking buy you, if you have to spend the same amount of time on tweaks? First, it allows transparency to the customer about what you are working on that week. When they see your normal velocity of 20 points turn into 5 points, they have a right to be worried. When you say, in a defeated voice “we were fixing bugs,” they also have a right to worry about the stability of the code you have been writing, even though this spike in minor changes to the application is a part of the normal process.

Second, it raises the moral of the team, because they are working towards a specific goal, to remove the production support cards from the iteration. Also, we get the satisfaction of maintaining a velocity in points, which is something we know so well it is hard to work without.

It takes a few iterations, and the team squeezes the life out of the production support card, putting you back on track. After those iterations, the footprint goes from sasquatch to mini-me.

It also helps the customer plan around production support. Their time lines and release dates are made from a projection of feature difficulty to development’s velocity. Over a long period of time, the velocity normalizes, and it hurts the projections to have hiccups. If you have production support data, you can predict about how much time around a release you will loose on the initial release of brand new development.

Peer Pressure

by: paul | January 18th, 2008 | 1 comments »

One of the famous studies on peer pressure was the Stanford prison experiment. A group of average people were selected to play either a prisoner or prisoner guard. As the participant became engrossed in the role, the peer pressure from other participants quickly degraded their moral compass. The small negative actions lead the groups to quickly fall into patterns of behavior which were unlike their own.

I see peer pressure work in the same manner for good all the time. Since software is written by teams, the software is often a reflection of how well the team works together more so than individual skills of the developers. When you have a group of developers who entice each other to do good work, the outcome can be great work.

Creating a culture of positive peer pressure is about doing lots of little things. Small positive actions will lead the team to create positive patterns of behavior.

Here are different techniques which have worked for different teams I have been a member.

1. Name your team, not just your project. This gives me as a developer some self-identity as part of a team.

2. Greet your team mates each day. We shake hands to show respect each day for each team member. We generally start and finish each day with a handshake. This can alleviate tense situations by itself, as personal contact often does. No chance to avoid a team member.

3. Do some activity everyone enjoys. Anything from eating lunch together to playing a competitive game as a team. We have played basketball together. Being competitive with my team gives me pride in the team, win or loose. Get to know your team members.

4. We keep a good supply of coffee, tea, snacks, and gum for each other as gifts. This act of giving to the team promotes the selflessness any team needs from its members top succeed. There are different levels of skill on a team, but each team member is important. It is difficult to write software for any project of magnitude without the full contribution of each member of the team.

5. Switch pairs pairs often. When you work with everyone on the team, you feel closer to everyone on the team.

6. Talk while you pair. Reading someone’s mind takes more effort than talking. Talking aloud also is a great way of brainstorming. Pair communication starts when words become sound waves.

These small things can improve the accountability and creativity to make a well functioning team. A happier team will become a creative and productive team. A team that has a strong sense of togetherness will lift each other up when needed. I find myself more willing to step up to daily challenges with the support of the team on my side. There is no place for apathy and complacency in a team which has pressure to succeed.

When the team succeeds, as positive teams often do, it becomes a group success and brings the entire team great pride. A team which pressures each other to do better can turn an average developer into a great developer.

That's Not Agile!

by: doug | August 5th, 2007 | 4 comments »

Removing the religion from software development

I had feared those words. I’d often been tempted to use them myself, but something told me I shouldn’t. As I sat in a planning game on a previous job, I heard the words. They still make me cringe. “We can’t do it that way. That’s not Agile.”

I’m a big fan of agile. I’ve long been convinced that the agile movement truly is uncovering ways to do software better. It’s revolutionizing the way that companies approach software. At 8th Light we’re using Agile to help us deliver the highest quality software possible to our clients. I wonder though, how exactly something can be classified as un-agile?

What is Agile anyway? Can it be measured? Can one thing really be more agile than another? If I had a yardstick and I was going to measure Agile, what would the markings be along the stick? What units would I use? ‘Points’ has already been taken, so maybe I should invent a new unit. I’ll call it the Agl. For every hour of pair programming an organization does it gets 10 Agls. Unit tests are worth 1 Agl each. Acceptance tests get 100 Agls. I’d use negative values too. For every page of documentation written, an organization looses 40 Agls, but the group running in iterations gets 1000 Agls. One week iterations are worth 2000.

The problem is that as a development organization adopts Agile and buys into various processes and practices, the temptation quickly grows to covert that development process into religion. “We can’t do code reviews, that’s not Agile!” “We don’t write documents, that not Agile!” What may start as genuine excitement and passion can quickly become religious dogma when those involved in the process lose sight of why they do what they do. Let me say that while I am a religious guy, I hate religion. Religion, to me, means action without thought: doing or saying something because that is the thing that you are supposed to say or do. I’d rather call what I have faith. Faith comes from beliefs or values held and turned into day-to-day living.

Since we are talking about religion, I thought I story from the Bible might be appropriate. Jesus and some friends were sitting down to eat when some super-religious folks showed up and started berating Jesus for letting his friends eat with dirty hands. These religious-types had established an elaborate ceremony for washing hands that had very little to do with removing bacteria. Jesus comes down hard on these guys for exchanging true principles for religious dogma. He responds by handing them the principle that does really matter. “Nothing outside a man can make him ‘unclean’ by going into him. Rather, it is what comes out of a man that makes him ‘unclean.’ ” (1) Here one of the most well-known religious leaders of all time shows his followers that it is the true principles that matter, not the religious practices or rules.

In software planning situations and day to day development we are faced with hundreds of little decisions about how to do our work. Should we throw this code out and start building the whole thing from scratch? Should we iteratively improve the code and slowly arrive at a better design? Do I write a test for this code? Should I pair with someone or just write this myself? When making these decisions we need guidance, something to help us understand if one thing is better than another. “Agile” is not that thing. Agile is just the label put on a whole spectrum of practices. Those guiding lights we need are principles. Principles are the domain-specific set of beliefs that an organization has adopted. They reflect what the organization values. I think it’s possible that many organizations get swept up in the excitement and freedom of agile practices that they skip this critical step of establishing the their principles. Kent Beck lays out a set of principles for extreme programming. Baby Steps, Failure, Quality, Redundancy, Opportunity, Flow, Reflections, Diversity, Improvement, Self-Similarity, Mutual Benefit, Economics, and Humanity(2) help direct an organization when it is trying to figure out the how of software development. Whenever I’ve heard Kent speak, he always comes back to the principles and values behind the practices in extreme programming. UncleBob has established a great set of principles that help us discuss and qualify designs. The Single Responsibility Principle, the Open-Closed Principle, the Don’t Repeat Yourself Principle(3), and others are guiding lights for design decisions. These give teams concrete evaluators that keep design discussions productive and prevent them from deteriorating into contests of dogma. Alistair Cockburn writes about 7 properties in Crystal Clear that can be translated into principles: Frequent Delivery, Reflective Improvement, Osmotic Communication, Personal Safety, Focus, East Access to Expert Users, Automated Tests, Configuration Management, and Frequent Integration (4). I don’t want to delve too deeply into these principles here, but an organization in the process of adopting agile should. Each of these manifesto-signing authors have explained these principles wonderfully in their books.

At issue in my planning meeting was whether or not to require a certain feature in a third party library for which we are shopping. At the time, we didn’t have a need for this feature, but we anticipated that it may show up an upcoming story. The person who spoke up saying “That’s Not Agile”” was really referencing the XP value of simplicity. “Solve today’s problems today and tomorrow’s problems tomorrow.”(2) This would suggest that one shouldn’t take on additional complexity until it is needed. However, when purchasing a third party library, perhaps the principle of Economics might suggest that paying a little more for this library today will save a lot of time and money later and potentially avoid purchasing the library twice. Which is the right decision? I don’t know, but after having agreed on the principles that guide our decisions, we can have the conversations around those principles and pick a way forward.

An organization transitioning to some flavor of agile ought to first clarify what its organization’s principles are. Read Beck or Martin or Cockburn or your favorite Agile author and choose the principles that you want to live by. Second, make the principles visible. Put them up on a wall. Have meetings where team members present a principle. Refer to them as you pair. Write about them, read about them, explore them. At 8th Light, we’ve put them on our website. Revisit them when starting a new project. If you are working with a consultant, ask them to take you through a values and principles exercise. If you are a consultant, please don’t miss this critical part of transitioning to Agile. Making your principles part of the every day vernacular of your organization will take you to a place where design and planning discussions stay productive and you’ll hopefully never hear “That’s not Agile!” again.

End Notes:
1) Mark 7:1-16
2) Beck, Kent. Extreme Programming Explained: Embrace Change (2nd Edition). Addison-Wesley Professional. 2004.
3) Martin, Robert C. Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. 2002.
4) Cockburn, Alistar. Crystal Clear: A Human-Powered Methodology for Small Teams Addison-Wesley Professional. 2004.

Shake Things Up

by: doug | July 19th, 2007 | 0 comments »

The most widespread and common greeting in the American culture is the handshake. Handshakes are shared between anyone meeting for the first time, to finalize a business deal, and to end a conversation. I spend a good deal of time around 2nd and 3rd generation Korean-Americans. In Korean culture, like many Asian cultures, the handshake is replaced by bowing. In these transitional immigrant generations, the bow and the handshake have been merged into one awkward action. I was recently walking through the reception line at the wedding of 2 second generation Korean-Americans and I went to greet the 1st generation parents. I was going to try to be respectful and offer a bow instead of a handshake, but just as I began to bend, a large hand was thrust out in front of me. I felt myself lucky that I didn’t end up with the guys finger in my nose.

One of the things I immediately noticed as I began working with the craftsmen at 8th Light is that everyday I walked into the office, every member of the team shook my hand. As each team member left for the day, he shook the hand of everyone who was left. I expect this on the first day, as you always shake hands with everyone on your first day. On the second day, I thought maybe they had all forgotten that they met me yesterday. As I realized that this would continue, It really made me start thinking.

As I went to work with another team for a little while I came to really miss the handshakes. I’d walk in the morning and maybe get an eyebrow flash from my teammates. A “Hello” would come if I was really lucky. I decided enough was enough, so I just started shaking hands. At first, I got some really weird looks and was left hanging a few times. The looks seem to ask “Why are you shaking my hand, we see each other every day.” But slowly it started to catch on. My teammates began to expect a handshake from me at the start and end of each day.

Here’s what I think these bookend handshakes do for a team. First, believe it or not, a handshake becomes an intimate gesture. It communicates genuine care and concern for each other. To me it’s a physical expression of the XP value of Humanity.

Second, it communicates respect. Sometimes design and project discussion can get very heated, especially if you are working with a passionate group of people. If your days begin and end with a handshake, everyday is bookended by a statement of mutual respect. There is a proverb that exhorts people to “Not let the sun go down on your anger.” That handshake is a way to let go any residual anger from the day and commit the next to dealing with each other with respect.

Third, It’s an honest statement about the hours you are working and the time you are putting in on the project. In a handshake-free environment, if I’ve had to leave the office early, I’d usually try to sneak out without anyone noticing. At the time I was in an office culture that promoted flexible hours, but you always felt like people were watching you to make sure you were still putting in your hours. I always put my time in, but because I sometimes played with my schedule quite a bit, I was always afraid that someone would perceive my time poorly. When an handshake begins and ends your day, you are being direct and up front about your time. You are communicating at the start of the day “I’m here, I’m ready to work” and at the end of the day “I’m gone, my day is over.” There are no apologies, no sneaking in or out, and no elaborate time-tracking system. Your teammates trust that you are working as much as you should be and you are not likely to try and cheat you company or your team out of your time week-to-week.

Try it in your team. It’s a morale boosting behavior that will cost a team nothing to implement, but will be one baby step to improving the strength and productivity of the team.

Something new, every day

by: eric | June 26th, 2007 | 0 comments »

Last December I went to to StarEast in Orlando because my fiancee is a tester and I well, I like sun. While there I picked up the book Practices of an Agile Developer and was particularly struck by the practice to keep a “Solutions Log.” The way a solutions log works is simple. Every time you find a solution to a problem you write it down, and later when you are confronted by a similar problem you have a reference. “Gee Whiz what a great idea!” I thought to myself, because I think to myself like Beaver Cleaver, “this way when Jim asks me about that bug I solved two weeks ago, I’ll know exactly what to tell him, instead of saying “uhhh, err, yeah I sorta kinda remember…” It really was an amazing revelation, seeing as how I hadn’t met Jim yet.

Then I got home and subscribed to Venkat’s blog where he recommended TiddlyWiki for keeping this list. If you’re unfamiliar with TiddlyWiki it’s an extremely cool browser-based personal note-taking tool that works entirely via JavaScript and CSS. You fire up your personal version of the html file, double click, and viola! there you have a note saved into the very document. Best of all it’s searchable even via regular expressions and plain text. With this tool I was gonna be a solution mastermind! People will ask me for that bug I fixed 14 years ago and I’ll be right there with my genius hat on and everything. You do have a genius hat don’t you?

How did it work out? Roughly 18 months later I have a whopping… 16 solutions, most of them written in the first week. You know what I learned from this? I suck at keeping a solutions list. The thing is I have no idea something is a solution to a recurring problem, until I come upon it a second time! What I need is a way to psychically determine what the solutions I’m going to need in the future are, and identify them. Um….

I’ve decided on a different option, which I think fits in well with the craftsmanship approach of perpetual learning. Since joining 8th Light I’ve been lucky enough to learn enormous amounts in a short amount of time, with more on the way, but of course none of this is in my solutions list. So instead of catching the realization that something is a solution, I’m going to write it all down. I’ve created a new list, and instead of calling it a Solutions List, it’s my LearnANewThingEveryDay list. Every day I’m obligated to write a new note with something I’d learned that day. If a day goes by and I haven’t learned something, I have to go learn something. I’ll read a book, find a great blog posting, try out a coding exercise, whatever. For example today I have written down some things I didn’t know about routing in rails. Mundane stuff that people more experienced with routing already new such as the :path_prefix parameter. What would be an otherwise fruitless day debugging now has a few little things I’ve learned from it. Will I ever search for that item? I don’t know - but the point is I can, so when Jim asks me how to get eric/is/the/coolest/blogger in front of all his links, I won’t stand there scratching my head.

Pair Me Up

by: paul | June 14th, 2007 | 15 comments »

I am a better pair than solo developer. For me, software is a collaborative art from the start to the end. Starting from the beginning of a project, where the developers need to collaborate with the customer s and stakeholders of the project to learn about the business domain. Then working with the project manager for sorting priorities and deadlines to make the business goals realizable in the fastest amount of time. Also development is collaboration, via pair programming, to produce a dialog between the developers on their vision of the implementation of this code. The last part, pair programming, is what I would like to focus on.

Having a pair has the traditional advantages of keeping disciplined and sharing the knowledge base. That is a starting point, but pairing is quintessentially important to my process due to the diversity it provides. A diversity of approach and implementation provide me with enough to perform at a highly creative and expressive manner.

Since you are not driving the keyboard and control of the computer, there is more time for contemplating code you wrote and direction you are moving. Most of my good ideas come from the time when someone else is typing. Since I was just working on the practical, I have my head wrapped around the code, and since I am not responsible for typing, I can reflect in the abstract.

I have heard many places that a benefit of test driven development is that the tests force you to design the API of the objects you are using as someone would use them. Well, pair programming, in compliment with programming ping-pong, forces your code to be clean. When you write a test, it isn’t you that makes it pass, so you have to think with expression and intent in mind. So, you end up writing the test FOR your pair. It becomes a form of writing, not just coding.

Sometimes, the test needs to be explained. While explaining something to a pair, your test must hold up your own arguments. Often times when I come to explain something I just wrote, I think of a better way to do it. Explanation is the best form of validating you understand where you are going well.

Also, pairing is how I learned most of my developer personality. Taking bits and pieces of the traits of my pairs through years of pairing. My style is a composite of pairing with various mentors and peers of mine. It has shown me how people approach this craft.

Lost in Portland, and Thinking

by: eric | May 20th, 2007 | 0 comments »

Did I say I was tired yesterday? That wasn’t tired, this is tired. I’m currently training for the marathon, and today I was scheduled for a 13 mile run. Sadly marathon training does not wait for RailsConf so I was up at five this morning, viewing the fair city of Portland. Say what you will about running, but it’s a great way to see a new city.

It’s also a great way to get lost. I used the great website at USA track and field where people post their runs in order to find a place to go and promptly wrote down a street name incorrectly. I ended up wandering around Portland’s lovely Willamette river, which fortunately provides a great landmark for a poor lost tourist. This led to running, and running, and running…and finally a Runners High.

Runners High is a phenomenon cause by your brain releasing endorphins, as a defense mechanism against the way your body feels. When I run my brain feels extremely active, and jumps from topic to topic making associations, breaking down problems, etc. It’s not unheard of for me to fix a bug I’d been struggling with while on a run, in a sudden burst of insight. Today, when I wasn’t wondering where the hell I was, I started thinking about quite a few things one of which is related to the new IDE’s being developed and the barrier to entry on Rails. Bear with me because this is a little out there, and I haven’t quite figured out how to articulate the concepts.

Right now Ruby and Rails are still strange and unusual things to most developers. When introduced to the language they want an IDE, and upon hearing there is no visual debugger or that they have to use Textmate, Eclipse or god-forbid emacs they turn away. They stick with Java or C++ and wizards and comfortable development, and will wait until they need to use Ruby.

Then one day their boss hears about Rails. They tell the developer, ‘you should be using this!’ and so he goes and he gets an IDE, real slick one with lot’s of bells and whistles. He goes to generate a model - only he doesn’t use script/generate. He uses a wizard, he sees he can add his methods and data members right there, so he does. Test? What test? Then he goes to the controller and has his controller manipulate the data all day, and develops a view in a WYSIWYG editor. He spends all day in the debugger, and his methods get bigger and bigger. Of course that’s no big deal, because he uses cold folding to hide their size. Then testers write Test::Unit code to test his code, and he’s done, because developers don’t test. Meanwhile we’ve all left Ruby because, “so much of the code is crap.” Haven’t we done this cycle before?

Chad Fowler described us as arrogant in the introduction, and clearly if you look above we are. I say we because nobody reading this had a problem with my rant, so you’re just as arrogant as I am. Caught you. We think we’re smarter than everybody else don’t we? Actually I don’t and most of you probably don’t either. I just know that there is a right and wrong way to do things, and so does Rails. That’s why it’s so opinionated. An attendee, Jack Canty, put it better than I can by saying “Rails is opinionated, and this takes away those opinions.”

So how do we fix it? Well let me steal some of Micah’s DSL thunder by using an analogy I thought of while running. It’s morning, and you want a coffee. So you go to a certain ubiquitous chain and say, “I’d like a big coffee please,” only said ubiquitous chain doesn’t have big. They have Tall, Grande and Venti. If you do this there will be a noticeable pause while the guy behind the counter takes a second to think about what you just said. He’s not a moron, take off his green smock and he knows what a big coffee is, but he’s got to translate it. What’s big - is it grande? Venti? That’s because you’re not speaking his language. You eventually do get your coffee, because he can figure out what you mean, but it takes just a little bit longer. While you wait in line you hear other people say, “I’ll have a grande half-caf no-foam latte,” and the guy behind the counter immediately repeats it. Eventually you learn the language they speak, and you get your coffee just a little bit faster. You’ve adapted to the idioms of the coffee shop, and you’ve been rewarded for it.

So what the heck does that have to do with code? I kind of gave it away by using the phrase idioms, didn’t I? Well let’s say you’re a C++ programmer and you start on Ruby. You don’t write Unit Tests, which despite what we sometimes think most developers do NOT do, and you sit down to iterate through an array. So you write:

1. index = 0
2. while index < array.length do
3. puts index
4. end

Much like ordering a big coffee at the Green Angel, that will work, but it’s completely incorrect. It’s not speaking Ruby even if it’s in the Ruby language, and unfortunately I believe that if we do not work hard to enforce and teach the best practices of the Rails and Ruby ways, we will witness this kind of thing propagated. I’ve done the C++ without test thing and lived in the debugger, and it drove me nuts. Unfortunately many developers don’t think anything is wrong with that. If they did they’d be here already. That’s what programming is to them. The good news is that we are the early adopters, and when they come around they will adapt to our rules but only if we make them. Remember what I said about the pause at Starbucks? Well the code above won’t pause. Ruby will execute it just as nicely as anything else, and maybe it shouldn’t, I’m not sure. What I do know is that the IDE’s now being created should not be catering to the developer that wants to do the things the way they’ve always done them. Instead of opening ‘choices’ up and making things ‘easier’, our IDEs should enforce the opinions of Rails. You see the late adopters aren’t lazy, or stupid, they’re just being rewarded improperly. If it’s easy to make a model without tests, they’ll make one, even if they are hurt by it later on. They’ll even stay until 1 AM to debug it, and their boss will think ‘gosh this Rails thing isn’t so great after all, thank God my programmers are so dedicated.’ Fortunately we control this. There’s a reason the IDE makers are here, and that’s because they know that late adopters ask the early adopters what they use. Tell the IDE makers that you want an IDE that does not allow bad habits. I want an IDE that is integrated with subversion, but I also want it to yell at me if I have untested code, and run ZenTest. If it gives me a wizard the first question it should ask is “what is the name of the test?.” Instead of code folding to hide bad code, it should identify refactoring opportunities. Finally, I’m not sure I even want a debugger. Debugging sucks, and it’s a crutch. I can test behavior rather than step through it and look at it. I realize people do want debuggers, I just worry for the day when Rails code can’t be properly understood without stepping through it.

Tell the IDE developers that you want an IDE that helps create good code, not easy code. If they don’t do that, then when developers ask you what you use say emacs. If the developer still turns away, we probably aren’t losing much.

Hello from RailsConf

by: eric | May 17th, 2007 | 0 comments »

Of course if you’re reading this you’re probably at RailsConf so hello from here. I’m right next to you actually, to your right. Yep that’s me, hi. There’s a coffee stain on your shirt.

I plan to blog as much as possible from here, and hopefully bring a little of the experience back home to those of you that couldn’t make it. I just came out of my first tutorial, “your first day on JRuby on Rails”, and found it quite enjoyable. Admittedly we’ve been playing with JRuby for a little while know here at 8th Light, so much of it was stuff I already knew, but it was great to talk to Charles Nutter and get some of my questions answered directly. Some highlights:

• Deployment with JRuby on Rails is a snap, assuming you’ve already got some sort of existing Java Enterprise setup. Using the GoldSpike plug-in creates a deployable WAR file. While I don’t see a reason for doing this on any current projects, for those of you out there using servers that might be resistant to setting up Apache/Mongrel this was a nice alternative. Install plug-in, run rake task and you have a deployable WAR file.

• NetBeans for Ruby fairly stole the show. I’m a big TextMate fan, especially because I no longer debug with anything other than puts statements, so I don’t need a fully fledged IDE for Rails. That said the features they demonstrated for Ruby were great, including code completion, jumping to methods, and my personal favorite clicking a method call and jumping to it’s source code even if it was in a Gem. I’ve done a lot of hunting in Gems and this would be enormously helpful. Rudimentary refactoring support is expected as well, including support for rename method. I asked how this would work in Ruby and the plan is to show places where the rename could take place and leave the ultimate decision up to the user. I didn’t get to see this in action, and I’d like to because I fail to see how that is better than just using find. I’d be hard-pressed to switch from TextMate, I’m writing this post in it, but I could be convinced if NetBeans could be the “editor you live in.”

In other news the Portland Conference center is really nice, with pretty good wireless network connections. One thing I’d ask for would be more tables outside the ballrooms, as there are only about 6 and a lot of people have their Macs open on the floor. Speaking of which I’ve never been anywhere that the Mac so dominated. 80-90% of the people here are carrying MacBooks.

Now if you’ll excuse me, I’m hungry.

Clean as You Code

by: micah | January 29th, 2007 | 0 comments »

In my younger days I was a Line Cook at the Olive Garden. In case you’ve never worked in the food industry, Line Cooks are the guys putting meals together as fast as customers order them. At times, it’s nearly impossible to keep up.

Among the most fundamental of the Line Cook’s principles was Clean as you go. I can remember clearly the manager walking regally down the line chanting, “Clean as you go Javier. Clean as you go Micah. Clean as you go Brian.” Cooks would remind each other from time to time too, “Clean as you go!”.

As you’re realizing, it’s import to keep your station clean when you’re a cook. Keeping things clean is not easy. Food gets EVERYWHERE when you’re putting together hundreds of meals an hour. Why is it important to keep it clean? Simple. When your station is dirty, the system breaks down and it slows you down. Utensils are dirty or missing, ingredients get mixed together, cooking surfaces are soiled… Combine this with all the fire, boiling water, and sharp knives, it’s dangerous too! Worse, other cooks are not able to help out. Uncleanliness on the line is a vicious cycle with positive feedback. Every experienced cook keeps their station spotless at all times and unexperienced cooks learn fast.

Dirtiness is a sign of trouble too. Let’s say that it’s the middle of a dinner rush. You look down the line and notice that Javier’s station is becoming cluttered. It’s near certainty that in five minutes Javier’s system will break down. Food will be burnt, orders will get lost, and servers will get vocal. Don’t get servers mad! Line Cooks work as a team though. So when you see that Javier’s station is getting cluttered, you jump over and give Javier a hand every moment you can spare.

This principle, “Clean as you go”, is well applied to software, “Clean as you code”. The analogy is fairly straight forward. Although I’ve applied the principle to software for years, it was only recently that I recalled the mantra “Clean as you go”. I’m sure my teammates will soon grow tired of hearing me chant… “Clean as you code!”

Craftsmen are like Babelfish

by: micah | October 2nd, 2006 | 2 comments »

Show me a software craftsmen and I’ll show you someone who can program in any language if they had to.

From time to time I meet developers who define themselves by the one and only programming language they know…. “I’m a Java developer”, “I’m a .NET developer”. It’s deplorable. I suspect such people don’t care much for their career.

Better are developers who can whip up code in multiple languages. Web developers, for example, often have to code in javascript in addition to the primary language whether it be Ruby, Java, or .NET. That’s respectable. Yet, many of these developers are intimidated by the notion of programming in some other language like C or C++. It’s a shame. There’s lot’s to learn from unfamiliar languages.

A Craftsman will not shy away from using the right language for the job. They understand that the act of programming is fundamentally the same despite the language being used. A craftsman is not intimidated by unfamiliar languages. When they’re confronted with a new language, they’ll learn it. After all, new programming languages are easy to learn.

Software Apprenticeship

by: micah | September 7th, 2006 | 0 comments »

David Hoover asked me a few questions about my experiences as a software apprentice. I was happy to answer his questions and pleased to hear that he’s writing a book on the topic.

What is Software Apprenticeship?

Software apprenticeship is path for learning to become a quality software engineer. A software apprentice learns to write code by working with people people who already know how to write code and are good at it.

It’s also an attitude. People who practice the software craft are on a journey of continual learning. There is no piece of paper that deems a craftsman worthy. A craftsman qualifies himself by demonstrating his skills.

I’d argue that any great software developer has been through an apprenticeship stage at one point or another.

How did I hear about Software Apprenticeship?

I saw my father reading a book titled Software Craftsmanship by Pete McBreen. This was shortly after I finished an unsatisfying 5 years in college. I was also knee deep in my apprenticeship, though I didn’t call it that at the time. I read the book and fell in love with the idea that software is a craft. For several years of my life I practiced martial arts and the model for growth in Jujitsu is very similar to that of software craftsmanship. So the concepts were not new to me but seeing software in this light clarified a few things…

No wonder I was so unsettled with my college education… That’s not how you’re supposed to learn software. Of the dozens of classes I took in earning my Computer Science degree, only 3 classes involved writing code. Crazy huh? And even though I could write programs after I graduated, I didn’t know the first thing about writing real software. A lot of good college did me! It was working with the great people at Object Mentor, especially my father, that truly taught me to code.

Not long after I read Pete’s book, Ken Aurer invited me to a Software Apprenticeship summit. There, several pioneers in the software craftsmanship movement got together to share experiences. I learned a great deal but what I took away from that summit was the comfort that there were lots of people who believed in the craftsmanship model. It was only a matter of time before the rest of the industry caught on.

Where am I in my journey?

For those new to the craftsmanship model there are three stages: apprentice, journeyman, and master craftsman. I’m well on my journey as a journeyman. I work on a variety of software projects, I teach, I consult, and I learn more about software every day. And to take this entry full circle, I help other budding software apprentices get started on their journey by leading Object Mentor’s apprenticeship program every summer.

---

Wed, 22 Jun 2005 21:53:29, David Chelimsky, hands on I had the good fortune to attend a graduation at which Deborah Meier spoke. Ms. Meier is an innovator and educator who founded a grade school at which kids of varying ages/grades work in the same classroom. She described the inspiration for this, talking about how schools USED to be when we (in the US) were a more agrarian society. There were two comments she made that seem relevant in the context of this discussion. One was that you would never choose to take a tennis class in which students sat around talking about tennis and then, one special day, the teacher brought in an actual tennis ball and passed it around so everyone could hold it and see what it felt like.

The other was the fact that in days of school gone by there were many experts and a few novices. The 7 year olds helped the 6 year olds. The 8 year olds helped the 7 and the 6 year olds. Etc, etc. Many experts and few novices - not one expert responsible for 30 novices. This made me think of the blacksmith analogy that permeates the Craftsmanship book.

---

Wed, 22 Jun 2005 01:53:36, KelleyHarris, ?Finding mentors for mid-career people? Great article Micah. Any suggestions for mid-career people looking to find mentors, full-time, part-time, or remote? Seems like there is room for a service connecting people. There is also room for a service providing object mentoring post OM courses.

There is no piece of paper that deems a craftsman worthy. A craftsman qualifies himself by demonstrating his skills. As people look for new jobs, what would be some good ways of demonstrating skills, at the resume & interview stage?

Any suggestions on open-source projects with great OO TDD code?

---

Mon, 20 Jun 2005 08:51:34, George Jensen, My Story I guess my story would be different from Micah’s in that, Higher Ed was good for a few seasons, but by no means did I expect to begin learning a craft there. If the above statement were a microcosm for Liberal Arts experience, we might assume it a bankrupt philosophy. This is the impression Micah might give off. After spending a week with Uncle Bob with Java immersion (2002), I can say I was one of those “Masters Level” students who knew nothing of good programming practices. I studied History in undergrad, and Information Science in Post-grad; but I continue to be pulled by the curious efforts Uncle Bob uses to hown the craft of programming, and his old-factory style of learning programming as a “craftmanship”.

I ask daily: With all the altruistic spirits of academia stuffed down our modern minds, why is it so refreshing to hear the obscure rant of Uncle Bob (and others) toting this old-factory campaign about “craftmanship” as a life goal?

---

Fri, 17 Jun 2005 10:02:01, Uncle Bob, Things have indeed changed. Keith, Things have indeed changed; at least in some sectors. A couple of years ago I brought in an intern who was in a CS masters program. This inidividual simply could not write code, nor had they been taught to write code. I was flabbergasted. I’ve poked around a bit since and have found that, at least at some schools, it is possible to acquire a BSCS, and even an MSCS, without ever having to write a line of code. Incredible!

---

Thu, 16 Jun 2005 11:22:16, Patrick Morrison, Things were different, but not necessarily better I must’ve gone to college around the same time Keith Ray did, as I can’t think of a CS course I took that didn’t involve at least some programming. But, with one exception (Principles of Software Engineering), every single course required the student to work alone… this is the antithesis of the craftsmanship model, and I’m sure it stunted my growth as a practicioner.

---

Thu, 16 Jun 2005 09:50:09, keith ray, things have changed When I went to college and got a computer science degree, just about every computer science class required writing code. The only one that didn’t was the one where we designed a CPU. Those who were in computer engineering rather than computer science had a sequel to that course: they had to implement their cpu design.

We programmed in FORTRAN, Pascal, C, 68000 assembler, and COBOL, and the “survey of computer languages” course had us writing short programs in APL, LISP, SNOBOL, and other some other languages.

##################################################