I’m part of a study group and right now we are reading Uncle Bob’s Agile Principles, Patterns and Practices book. The first chapter was a refresher on Agile and so I thought I’d write down what Agile meant to me. Thought I would post it here for posterity …

The key themes of agile, IMHO are as follows:

1. Communication - lack of communication will kill any benefits gained from the rest of the practices/tools. Good and regular communication is the best way to ensure that ideas, knowledge, instructions and caveats are shared amongst not just the team, but the clients as well.
2. Adaptability - only by knowing exactly where you are can you assess the impact of where you need to go next. Clean, well thought out, quality code helps you to turn on a sixpence when changes come in.
3. Deliver early, deliver often - the longer the period of time between the team working on code and the client reviewing it, the harder it will be to correct any misunderstandings or affect any changes. Also, the longer an iteration, the more likely it is to slip its due date.
4. Good people are _essential_ to an agile team, and not just as individuals. The whole team must also work well together. Also, the larger a team becomes, the harder it becomes to communicate and therefore the less likely it is for good quality software to be created. Personally I think between 4-7 on a team is plenty.

Feel free to tell me I’m speaking shite, as long as you do so constructively and back up your argument. ;)

The app that I spend much of my day working on is, for one reason or another, still on Rails 2.3.5. I’d been avoiding doing the updates to RubyGems specifically because of this. However, a recent refresh of my MacBook meant that I took the plunge and upgraded.

The first issue I hit was the “uninitialized constant ActiveSupport::Dependencies::Mutex (NameError)” one. This was easily fixed by chucking the following at the top of config/boot.rb: -

require "thread"

- thanks to this StackOverflow post for the info :)

The next issue was the “undefined local variable or method ‘version_requirements’ (NameError)” one, which was equally easily fixed by adding the following into environment.rb between the bootstrapper and the initializer (sic): -

if Gem::VERSION >= "1.3.6"
  module Rails
    class GemDependency
      def requirement
        r = super
        (r == Gem::Requirement.default) ? nil : r
      end
    end
  end
end

- thanks to Martin Straub for the info on this one.

Last weekend I was down in Edinburgh for the Scottish Ruby Conference. I’ll be gathering my thoughts and blogging about that at the weekend, but this particular post deserves to go out sooner …

The final keynote on Friday was given by Chad Fowler and IMHO was worth the price of admission alone. There were many points that Chad covered and I’ll go into them in more detail later, but the point that stuck in my head was that we should stop being so negative all the time. In other words, if something annoys you or angers you, rather than going and shouting about it on teh interwebz, go do something about it. Fix the issue, submit a patch, take a positive action.

Looking back over the weekend I was suddenly aware of the amount of time I’d spent bitching about stuff. About things I thought were wrong with Rails, about things I wished were better, about … well pretty much everything. Looking back even further to the run up to the conference I remembered the number of hours spent moaning at work and at home. I started to see myself in a pretty poor light. Did I spend _all_ my time complaining and moaning?

On the train on the way up the road I started digging into some issues with the PayPal feature that we’re working on and posted the following to Twitter:

“On a completely unrelated note … I am really starting to despise Paypal (especially their buggy-as-hell sandbox)”

If you follow me on Twitter (and why shouldn’t you) you will know that that is a fairly typical example of my output. So I decided, right after I hit send that I wasn’t going to do that anymore … well not until May at any rate. ;)

I remembered that Corey Haines had arranged an unofficial “let’s be positive” thing last November called Postivember. So I decided to try a smaller version until the end of April and, in the spirit of these kind of things, decided to name it Yay-pril.

Now, I’m Scottish, self-deprecation and cynicism are pretty much national sports here. Most of our humour is based around knocking ourselves or others down. So I’m not going to suddenly become Mr Sunshine and Rainbows overnight and I’ll try not to go all Care Bear on you. ;)

What I do want to do though, is to start looking for solutions rather than complaining about the problems. To help people rather than slagging them off. To look for ways to help rather than hanging back and waiting for someone else to take the impetus.

Want to join me? All you need to do is take a positive outlook for the rest of the month. You don’t have to make it a Hallmark moment, but if you do something or think of something positive as a result, it would be great if you could tweet it with the hashtag #yaypril so the rest of us can see.

Happy #yaypril folks :)

I feel like a total zombie this morning. Why? Because I tried to fit too much into my head last night. In the space of time between finishing my tea and going to bed I managed to: -

1. Install and test a tool for making my new Magic Mouse easier to use.
2. Do some typing lessons.
3. Try my hand at a Ruby Quiz.
4. Try to code in Vim rather than TextMate.
5. Read a few more Apprenticeship Patterns.
6. Fire off some emails.

I achieved, in any real sense of the word, frak all. I did too little of too much. In other words I wasted a night and, at this point in my life, nights spent in front of the computer are a precious commodity.

So, I spent my shower time (hey, the internet is all about over-sharing) putting together a schedule for learning. Mainly so that I can get the most out of the time I do spend at the keyboard, but also so I don’t burn out before Cleatus the Fetus makes his/her grand entrance.

I’ve decided to split it out as follows: -

1. Night 1 - Tools. Currently keyboard and Vim, but there are plenty of other tools that I use that I need to go deep on.
2. Night 2 - Coding practice and soft skills. Basically koans, katas and other exercises.
3. Every 2nd Friday - I work a compressed working week, which is HR speak for getting every 2nd Friday off. I’ll use this day (for as long as I can) to work on portfolio projects.

Why am I telling you all this? Well partly because I need to find stuff to write about ;) but mostly because I find it easier to stick to something if I’ve told people about it. In other words, it makes the cost of failure higher. There’s always the temptation to procrastinate, get sidetracked or just generally bugger about. So, in order to try and counteract this, I’ll post at least one thing that I learn from each of these sessions.

Hopefully this will mean that I can manage my learning outside of work without turning into the walking dead. Brrrrrraaaaaaaaiiiiiiiinnnnnnnnsssssss!!!!!!!!!

The title of this post was the reply Enrique Riepenhausen gave when I asked him and Joe O’Brien, amongst others, how you sold Software Craftsmanship to your clients. I had been wondering for a while how you explained the advantages of software craftsmanship to a non-technical client. How do you differentiate yourself from the the competition in a manner that a non-developer could appreciate and understand?

As a developer, and one that has seen (and to my shame, participated in) his fair share of corner-cutting, I understand the need for craftsmanship. I really get the need for the principles laid out first of all in the Agile Manifesto and latterly in the Software Craftsmanship Manifesto. I understand how they make for better software and better relationships, not just within teams but also with the clients those teams create value for. However, I just couldn’t see how you explained that to prospective clients, nor could I see how you could translate it into something that they were willing to pay extra for (at least in the short term). As Enrique correctly pointed out though, you don’t sell craftsmanship. At the time I thought, “Great! Excellent! That’s the point I’ve been missing.” However, afterward, the more I thought about it, the more confused I got. If you don’t sell your craftsmanship credentials, how _do_ you differentiate yourself from the competition? This week I had an experience that not only gave me the answer, it showed me that I was asking the wrong question!

This month I changed my car insurance from Insurer A to Insurer B. I’d been happily insured by Insurer A for the last two years and was always impressed with their service. The documentation that accompanied their insurance was well laid out and easy to understand, their staff friendly, well-informed and helpful, and the price (whilst not the cheapest on offer) was very competitive. This year, they put the cost of insurance up quite steeply and so I went to look for another insurer. Insurer B were a *lot* cheaper. In fact, they were cheapest insurer that I had heard of on the comparison site. I decided that I would go with having extra money in my pocket rather than sticking with the insurer I knew, and so I moved.

And so it came to pass that my insurance documents came through from Insurer B. So I got on the phone to Insurer A to let them know that I was canceling. They could not have been more helpful. Within a couple of minutes I had canceled my existing insurance, been forwarded proof of my no claims discount and informed of everything I needed to know as we went along. Insurer B, on the other hand, called me at work, tried to sell me features that I’d already explicitly declined on sign up and then tried to sell me various other products that they happened to have.

Now, the point here (and this is crucial) is _not_ that the cheaper insurer turned out to be the worst. The reason I moved to Insurer A in the first place was because my previous insurer had been more expensive. That previous insurer had also tried it on with the “trying to sell me things I’d already declined” shenanigans. The point here is that, even though I was canceling my insurance with them, Insurer A still went above and beyond to help me. Their focus was on me as a customer, even though they were about to lose my custom. That impressed me to the point where I will be taking my insurance out with them again next year, despite the extra cost.

So far, so very “Thought For The Day”. How does this relate to my software craftsmanship question? First of all, it showed me that I was asking the wrong question. I was approaching software craftsmanship from the point of view of selling it. Making more money because you were crafting a better product. This is, I now believe, the _wrong_ way to look at it. We are craftsmen because we want to build better software, because we want to have good relationships with our customers and because we want to further the state of the art in our chosen profession, not because we want to get paid more. Secondly, Enrique is right. We don’t sell craftsmanship to our clients. They come to us because they have heard that we are great at what we do, or they have seen examples of our previous work. Like my experience with Insurer A, those we do business with will sing our praises because we always put them (or at least their best interests) first and foremost. More than that, they will come to _trust_ us. Once that happens the money will follow, only by that point it will be a bonus over the true reward of craftsmanship. The pride of a job well done.

In the spirit of refactoring to keep things clean, I’ve decided to move the book list from the original post to here. This should hopefully make it easier to use. Please add any new recommendations to this list.

Agile Software Development: Principles, Practices and Patterns (aka PPP)

Apprenticeship Patterns (if you’re thinking of reading Apprenticeship Patterns, Hashrocket are covering it in their Bookclub)

Clean Code

Mastering Regular Expressions

Object Thinking

Smalltalk Best Practice Patterns

Software Craftsmanship

The Art of Unix Programming

The K & R Book

The MIT SICP course (aka The Wizard Book)

The Passionate Programmer

The Pragmatic Programmer

The Refactoring book (original) (Ruby)

Working Effectively with Legacy Code

Any book by W. Richard Stevens but Advanced Programming in the Unix Environment and the Unix Network Programming Volumes in particular.

Finally, some great advice given to read through the man pages on your system. This also applies to reading the code for any application/plugin/gem etc. that you use. You can learn a lot from other people’s code/documentation.