My former colleague Greg Gigon has written an interesting blog post where he talks about the pain that we cause ourselves by multi-tasking, a point which Kevin Fox also makes on the Theory of Constraints blog.

I think the overall point that he makes is very true:

We can switch our attention quickly from one task to another. But … is it good for our brain? Is it good for the work we are doing? Are we really more productive?

I've often found that when I try and switch between multiple different tasks I end up finishing none of them and it's certainly true that twitter, facebook and emails can be amazingly distracting.

Hopefully those types of distractions are less of an issue when working on a software development team, particularly if the team are pair programming.

Project influenced context switching

While I agree with Greg that it's good to try and make sure that we're only working on one task at a time, I think that to an extent there is always going to be some context switching involved if we have a group of people working together.

Greg touches on this briefly in his post:

When we are in a despair and need answers we are not worrying about anyone else. The goal is to ask or tell to achieve whatever we are after. We are not taking into consideration that we might be disturbing someone else Flow.

To me it seems that focusing on the flow of an individual individual/pair is a bit of a local optimisation when we're talking about software teams.

For example if a pair are working on a piece of functionality orthogonal to what another pair are working on then should they interrupt that pair if they need to talk about something?

Interrupting them possible would break their 'flow' but it might give one or both pairs an insight into the problem which they wouldn't have otherwise had.

From my experience pairs interrupting each other often helps reduce the amount of time that we spend building the wrong thing.

An alternative way to still gain this knowledge without interrupting people straight away would be to delay the conversation until a later time but perhaps the best moment for gaining that knowledge has now gone?

Counter productive context switching

The only time when interrupting a pair does seem counter productive is if you're doing so to ask a question whose answer could easily be found out with a quick bit of Googling.

In that case I completely agree with Greg that we should first think about the impact our interruption will have on our colleagues.

Overall

The topic of flow/context switching is an interesting one but I think we need to be careful about having it as our main goal on software delivery teams.

I wrote about pair flow a while ago where I described some ways to achieve more 'flow' within a pair but my current line of thinking is that we'll still have some interruption between pairs and that's not necessarily a bad thing.

An approach to ponder…

Mike Wagg once suggested that pairs should work in 25 minute pomodoros and only be interruptible when they're on a break from one.

This seems like an interesting idea but communication would end up being much more structured/time boxed/weird?!

One of the most common discussions that I have with my colleagues is around designing bits of code in the simplest way possible.

I've never quite been able to put my finger on exactly what makes a design simple and there is frequently disagreement about what is even considered simple.

On the last project I worked on we had an interesting problem where we wanted to partially update different parts of an object from different pages of the application.

We had access to the id of the object from the URL so my initial thought was that when we submitted each page we could load the full object from the database and update it with the values that had just been submitted from that page.

The problem with that solution was that it meant we needed to make another database call without any real benefit from doing so.

We had already created objects representing the data submitted from these pages so Christian suggested that an alternative approach would be to create NHibernate mappings for those objects instead so that we could just map the updated values straight to the database.

We had bit of duplication in our objects as we had one object representing every bit of data the user had provided so far and then two smaller objects just representing the data provided for each of the pages.

public class TheObject
{
	public string Page1Property { get; set; }
	public string Page2Property { get; set; }
}

public class PartialObject1
{
	public string Page1Property { get; set; }
}

public class PartialObject2
{
	public string Page2Property { get; set; }
}

We then created NHibernate mappings for each of those objects:

public class TheObjectMapping : ClassMap<TheObject>
{
	Map(x => x.Page1Property);
	Map(x => x.Page2Property);
}

public class PartialObject1Mapping : ClassMap<PartialObject1>
{
	Map(x => x.Page1Property);

public class PartialObject2Mapping : ClassMap<PartialObject2>
{
	Map(x => x.Page2Property);

When loading the object from the database onto the page we used 'TheObject' and its associated mappings and when updating the object from the individual pages we could use the partial object mappings.

I think this was quite a neat approach as it allowed us to reduce the complexity of our controller code when updating an object as well as removing the need for one trip to the database.

The trade off was that we ended up writing more mapping code but that seemed to be a reasonable trade off to make.

I've been playing around with Objective C over the last month or so and although my knowledge of the language is still very much limited I thought it'd be interesting to describe some of the things about the language that I think are quite interesting and others that keep catching me out.

Protocols

I touched on protocols a bit in my first post but they seem like an interesting middle ground between interfaces and duck typing.

I like the fact that protocols can define optional methods so that if we're not interested in some parts of the protocol we can just ignore those parts.

From the documentation page:

Protocols free method declarations from dependency on the class hierarchy, so they can be used in ways that classes and categories cannot. Protocols list methods that are (or may be) implemented somewhere, but the identity of the class that implements them is not of interest. What is of interest is whether or not a particular class conforms to the protocol

Smalltalkish style method names

We played with Smalltalk in a coding dojo a bit last year and the first thing that I noticed with Objective C is that the method names are very similar to those in Smalltalk.

I think this influences the way that we define the method name and its parameters as you try and define those in such a way that when you call the method it will read better.

For example I created the following method:

UILabel *aLabel	= [self createLabelFrom:project withXCoordinate:x withYCoordinate:y];

If I didn't have to name the parameters when calling the method I doubt I would have used such descriptive names. I would have just used 'x' and 'y' as the names!

All methods are public/Defining methods in header files

As I understand it all the methods defined on an object are available to any other object to call i.e. all the methods are public

I've read about others using categories to simulate the idea of having non public methods but I haven't tried anything myself yet.

Interestingly we get a compiler warning when trying to call methods on an object if those methods haven't been defined in the appropriate header file although the code still seems to execute fine at run time.

Messages not method calls

One other thing that I sometimes forget is that we're dealing with messages rather than method calls.

We still need to send the message to 'self' even if it's a message being sent to another method on the same object.

Last week we were trying to make use of Rails' 'form_for' helper to populate a dropdown list with the values of a collection that we'd set to an instance variable in our controller.

My colleague pointed out that we'd need to use 'collection_select' in order to do this.

We want to put the values in the 'foos' collection onto the page. 'foos' is a hash which defines some display values and their corresponding values like so:

class FooController < ActionController::Base
	def index
		# @mainFoo defined with some value irrelevant to this example
		@foos = { "value1" => 1, "value2" => 2 }
	end
end

The code we need to do this looks like this:

<%form_for @mainFoo, :html => { :name=> "ourForm", :id=> "ourForm" },:url => {:controller => "foo", :action => :bar} do | mainFoo |%>
 
<%= foo.collection_select :foo_id, {"Please select"=>""}.merge!(@foos), :last, :first, { :selected => "Please select" }, {:name => "foo", :id => "foo"} %>

The method signature that we're passing those parameters to reads like this:

def collection_select(method, collection, value_method, text_method, options = {}, html_options = {})

In this case we want the selected value to always be 'Please select' so we need to specify that in the 'options' hash. If 'selected' wasn't specified in the hash then the code would try to make the selected value @mainFoo.foo_id which in this case has no value anyway.

The other thing which I thought was quite neat is the way that you need to provided the 'value_method' and 'text_method' as parameters so that the dropdown list can be constructed with the appropriate labels and values.

In this case we have the display values as the keys in the hash and the values as the values in the hash so we can retrieve those entries from the collection by using the ':last' and ':first' methods.

We end up in the following method:

      def options_from_collection_for_select(collection, value_method, text_method, selected = nil)
        options = collection.map do |element|
          [element.send(text_method), element.send(value_method)]
        end

This creates an array of arrays which is used later on.

In our case the values passing through this method would read like this:

        collection = { "value1" => 1, "value2" => 2 }
 
        options = collection.map do |element|
          [element.send(text_method), element.send(value_method)]
        end

 => [["value1", 1], ["value2", 2]]

I was initially a bit confused about how we were able to call the 'collection_select' method on 'mainFoo' but a quick browse of the ActionPack code showed that 'mainFoo' actually represents a wrapper around that object rather than the object itself.

One of the earliest rules of thumb that I was taught by my colleagues is the idea that we should try and avoid mutating/changing values passed into a function as a parameter.

The underlying reason as I understand it is that if you're just skimming through the code you wouldn't necessarily expect the values of incoming parameters to be different depending where in the function they're used.

I think the most dangerous example of this is when we completely change the value of a parameter, like so:

public class SomeClass
{
	public BigDecimal doSomeCalculationsOn(BigDecimal value) {   
		value = value.divide(new BigDecimal("3.2"));
		// some other calculation  on value...
		// and we keep on re-assigning value until we return the value
		return value;  
	}
}

In this case the function is really small so maybe it doesn't make that much difference readability wise but I still think it would be better if we didn't reassign the result of the calculation to 'value' but instead used a new variable name.

It wouldn't require a very big change to do that:

public class SomeClass
{
	public BigDecimal doSomeCalculationsOn(BigDecimal value) {   
		BigDecimal newValue = value.divide(new BigDecimal("3.2"));
		// some other calculation  on newValue...
		// and we keep on re-assigning newValue until we return the newValue
		return newValue;  
	}
}

Unless the function in question is the identity function I find it very weird when I read code which seems to return the same value that's been passed into the function.

The other way that function parameters get changed is when we mutate the values directly. The collecting parameter pattern is a good example of this.

That seems to be a more common pattern and since the function names normally reveal intent better it's normally less confusing.

It does become more problematic if we're mutating an object in loads of places based on conditional statements because we can lose track of how many times it's been changed.

Interestingly some of the code for ActionPack makes use of both of these approaches in the same function!

form_options_helper.rb

564
565
566
567
568
569
570
571

      def to_collection_select_tag(collection, value_method, text_method, options, html_options)
        html_options = html_options.stringify_keys
        add_default_name_and_id(html_options)
        ...
        content_tag(
          "select", add_options(options_from_collection_for_select(collection, value_method, text_method, :selected => selected_value, :disabled => disabled_value), options, value), html_options
        )
      end

form_helper.rb

        def add_default_name_and_id(options)
          if options.has_key?("index")
            options["name"] ||= tag_name_with_index(options["index"])
          # and so on
          end
        end

I'm not sure how exactly I'd change that function so that it didn't mutate 'html_options' but I'm thinking perhaps something like this:

	def create_html_options_with_default_name_and_id(html_options)
          options = html_options.stringify_keys
          if options.has_key?("index")
            options["name"] ||= tag_name_with_index(options["index"])
          # and so on
	end

And we could then change the other method to call it like so:

      def to_collection_select_tag(collection, value_method, text_method, options, html_options)
	   html_options_with_defaults = create_html_options_with_default_name_and_id(html_options)
        ...
        content_tag(
          "select", add_options(options_from_collection_for_select(collection, value_method, text_method, :selected => selected_value, :disabled => disabled_value), options, value), html_options_with_defaults
        )
      end

I guess you could argue that the new function is doing more than one thing but I don't think it's too bad.

Looking back on these code examples after writing about them I'm not as confident that mutating parameters is as confusing as I originally thought…!

Another library that we're using on my project is ActionMailer and before reading through the documentation I was confused for quite a while with respect to how it actually worked.

We have something similar to the following piece of code…

Emailer.deliver_some_email

…which when you click its definition in RubyMine takes you to this class definition:

class Emailer < ActionMailer::Base
	def some_email
		recipients "some@email.com"
		from "some_other_email@whatever.com"
		# and so on
	end
end

I initially thought that method was called 'deliver_some_mail' but having realised that it wasn't I was led to the 'magic' that is 'method_missing' on 'ActionMailer::Base' which is defined as follows:

module ActionMailer
...
	class Base
		def method_missing(method_symbol, *parameters) #:nodoc:
        		if match = matches_dynamic_method?(method_symbol)
          		case match[1]
            			when 'create'  then new(match[2], *parameters).mail
            			when 'deliver' then new(match[2], *parameters).deliver!
            			when 'new'     then nil
            			else super
          		end
        		else
				super
        		end
		end
	end
end

The 'matches_dynamic_method?' function allows us to extract 'some_email' from the 'method_symbol'. That value is then passed into the object's initializer method and is eventually called executing all the code inside that method.

        def matches_dynamic_method?(method_name) #:nodoc:
          method_name = method_name.to_s
          /^(create|deliver)_([_a-z]\w*)/.match(method_name) || /^(new)$/.match(method_name)
        end

Reading through the documentation, the author gives the following reasons for having separate 'create' and 'deliver' methods:

ApplicationMailer.create_signed_up("david@loudthinking.com")  # => tmail object for testing
ApplicationMailer.deliver_signed_up("david@loudthinking.com") # sends the email
ApplicationMailer.new.signed_up("david@loudthinking.com")     # won't work!

In C# or Java I think we'd probably use another object to build up the message and then pass that to the 'Emailer' to deliver it so it's quite interesting that both these responsibilities are in the same class.

It also takes care of rendering templates and from what I can tell the trade off for having this much complexity in one class is that it makes it quite easy for the library's clients – we just have to extend 'ActionMailer::Base' and we have access to everything that we need.

One of the reasons I wanted to come and work for ThoughtWorks in India is that I wanted to see how a distributed agile project is run and see the ways in which it differs to one which is done co-located.

I worked on a project which was distributed between Sydney and Melbourne in 2008/2009 and while some of the challenges seem to be quite similar to the ones we faced there, some are completely different.

Emails

Emails become much more prevalent when there are people in different locations and one thing that I learnt from the distributed project in Australia is that we have to be quite careful about the way that we phrase what we write.

It tends to work much better if we write in quite a defensive way using phrases like 'I think that' or 'it seems that' since it's very easy to misinterpret what's being said as we don't have the chance to understand a person's body language or tone.

A colleague pointed out to me that it's equally important to change the way that you read emails to give the other person the benefit of the doubt otherwise everything that you read may come across as being sarcastic and attacking.

Conference calls

As well as emails a lot of the communication between the people in Pune and Chicago is done through conference calls.

We also used this approach on the project I worked on in Australia and while it was still not as effective as face to face communication, the calls were always relatively smooth.

We seem to have more trouble on this project and people's voices often breakup so that you can't understand them at all. This leads to a bit of repetition in conversations and I can easily see how this would become an area of severe frustration.

I also learnt that I need to speak much more slowly on these calls or noone can understand what I'm saying!

Time zones

The time zone difference between Chicago and Pune at the moment is 10.5 hours so there is no overlap in the working days in the two locations which means we need to create an artificial overlap.

A normal working day for projects I've worked on in the UK/Australia would be around 9am – 6pm:

• 9am in Pune is 10.30pm the previous day in Chicago
• 6pm in Pune is 7.30am in Chicago

As a result the people in Chicago are asleep for nearly all of our working day and since the client is there as well the feedback cycle is a bit slower than it would be in the client was in the same building.

There does seem to be more scope to go down the wrong path when building a piece of functionality but as long as the client doesn't change their mind too drastically overnight or have their intent misunderstood then it seems relatively manageable.

A couple of years ago I saw a talk by the former Managing Director of ThoughtWorks India, Sitaraman, in which he outlined some of the challenges of offshore and I wondered whether the concepts of successful delivery both on and offshore were the same.

I'm still of a similar opinion but by being part of a distributed agile team for a few days I can see how much more tricky it is to achieve this than it would be in a co-located environment.

I'm sure there are many more things I will notice that are different as times goes on!

I've spent a little time browsing through some of the libraries used by my project and one thing which I noticed in ActiveSupport is that fields don't seem to be accessed directly but rather are accessed through a method which effectively encapsulates them inside the object.

For example the following function is defined in 'inheritable_attributes.rb'

  def write_inheritable_attribute(key, value)
    if inheritable_attributes.equal?(EMPTY_INHERITABLE_ATTRIBUTES)
      @inheritable_attributes = {}
    end
    inheritable_attributes[key] = value
  end

  def inheritable_attributes
    @inheritable_attributes ||= EMPTY_INHERITABLE_ATTRIBUTES
  end

EMPTY_INHERITABLE_ATTRIBUTES = {}.freeze unless const_defined?(:EMPTY_INHERITABLE_ATTRIBUTES)

If we were using C# we'd have instantiated '@inheritable_attributes' at the field definition with 'EMPTY_INHERITABLE_ATTRIBUTES' like so…

public class SomeClass {
	private Dictionary<string, object> inheritableAttributes = new Dictionary<string, object>();
}

…but we can't do that in Ruby because we don't need to explicitly define all our fields, we just start using them.

I'm assuming this is quite a common pattern in Ruby and in a way it's quite neat because it restricts the number of direct field references which will make it easier to change the underlying implementation. Kerievsky's narrowed change refactoring suddenly becomes less necessary!

For that reason I wonder whether it would be a useful pattern in C#/Java or if it would be overkill.

In Continuous Delivery the authors talk about the danger of ultimate configurability…

Configurable software is not always the cheaper solution it appears to be. It’s almost always better to focus on delivering the high-value functionality with little configuration and then add configuration options later when necessary

…and from my experience when you take this over configurability to its logical conclusion you end up developing a framework that can hopefully just be 'configured' for any number of 'front ends'.

This seems to be quite a common thing to do across organisations and typically the decision about what needs to go into the framework is made before there's been much/any development on the applications which will make use of said framework.

In addition the framework is typically built by a different team to the ones who are going to be working on the applications which make use of it.

As a result it's very difficult for that team to know exactly what they should be building so we'll typically end up with something that is overcomplicated for the situations it's actually required for.

In my mind the problem that we create for ourselves is the same as when we try to write a massive piece of code all in one go instead of driving it out through examples.

We try to imagine how the code might be used rather than knowing how it will actually be used.

Udi Dahan talks about favouring use over reuse and I think this is the ultimate example of not doing that.

A more effective approach would be to develop those websites/front ends individually and then let the shared 'framework' evolve from there.

That way we know that we've extracted some shared ideas because we needed to rather than because we thought we might need to.

Even then we need to be careful about what we share between applications because often it might be best to just accept a bit of duplication to avoid the implicit dependency created between teams.

Seth Godin recently wrote a post about 'the fear tax' which he describes as a 'tax' that we pay when we do something in order to try and calm our fear about something else but don't necessarily end up calming those fears.

We pay the fear tax every time we spend time or money seeking reassurance. We pay it twice when the act of seeking that reassurance actually makes us more anxious, not less.

I think one common example of a time we fall into this trap when developing software is around the security of financial systems.

Due to legal requirements that firms operating in that domain operate under we can often end up with a very complicated security solution which is unnecessary for allowing us to achieve what we want to.

On one system we worked on had a requirement to write some Javascript code to encrypt the data sent from the browser which was then sent securely through SSL to the web server.

Once it reached the web server we then had to send it in a SOAP message to a backend server where it could be unencrypted through the use of a private key.

Since one end point was in Java and one .NET there were slight incompatibilities in the way they handled security so it ended up taking a lot of time to actually get it working properly.

We had this extra security around the messages on the backend to protect against an unauthorised server trying to send messages to that server.

This despite the fact that the backend server was behind a firewall which would not accept any requests that came from servers outside the specified IP addresses of servers known to be in the DMZ.

In other words in order to remain compliant we were paying a significant fear tax in terms of increased complexity of our code base and the time taken to get all the code working in the first place.

Another simpler example of this that is often found in code is checking whether an object being passed around the code is null.

I've worked on code bases where we've ended up checking whether a particular object is null 2 or 3 times.

Alternatively we can use a pattern to take this problem away and then we don't have to worry about it again.

Seth's closing advice is as follows:

Instead of forgetting about the wasted anxiety after the fact, perhaps we ought to keep a log of how often we needlessly pay the fear tax.

Instead of over-staffing, over-planning, over-meeting and over-analyzing, perhaps organizations should take lower-cost steps and actually ship.

Think about how much you could get done if you didn't have to pay a tax to amplify or mollify your fear…

I've been flicking through Continuous Deployment and one section early on about changing configuration information in our applications particularly caught my eye:

In our experience, it is an enduring myth that configuration information is somehow less risky to change than source code. Our bet is that, given access to both, we can stop your system at least as easily by changing the configuration as by changing the source code.

In many organisations where I've worked this is generally adhered to except when it comes to configuration which is controlled from the database!

If there was a change to be made to source code or configuration on the file system then the application would go through a series of regression tests (often manual) to ensure that the application would still work after the change.

If it was a database change then that just be made and there would be no such process.

Making a change to database configuration is pretty much the same as making any other change and if we don't treat it the same way then we can run into all kinds of trouble as the authors point out:

If we change the source code, there are a variety of ways in which we are protected from ourselves; the compiler will rule out nonsense, and automated tests should catch most other errors. On the other hand, most configuration information is free-form and untested.

Alex recently wrote about his use of deployment smoke tests – another suggestion of the authors – to ensure that we don't break our application by making configuration changes.

Organisations often have painful processes for releasing software but I think it makes more sense to try and fix those rather than circumnavigating them and potentially making our application behave unexpectedly in production.

As I've mentioned previously I think the Kindle application on the iPad is the best one for reading books and as a result of that I wanted to be able to read some books which I'd bought from the PragProg store onto it.

The first step is to download the '.mobi' version of the book and use iPhoneExplorer to drag the file into the 'Kindle/Documents/eBook' folder on the iPad.

This works fine but if you add more than one book in this way they all have the same cover image when viewed on the iPad which is quite annoying when trying to work out which book is which.

I went on a yak shaving mission to try and figure out how to solve that problem and came across a post by GRiker where he described how to set a custom cover image.

His instructions were as follows:

For example, let's say you want to sideload WarOfTheWorlds.MOBI with its cover WarOfTheWorlds.JPG into the Kindle for iPad app:

• Modify WarOfTheWorlds.MOBI (using Mobi2Mobi, for example), adding or modifying the ASIN field (in the EXTH block) with the name of the cover jpg, WarOfTheWorlds.JPG. (Since your sideloaded book didn't come from Amazon, you don't need a real ASIN.)
• Copy the modified WarOfTheWorlds.MOBI to Kindle/Documents/eBooks (using iPhone Explorer)
• Copy WarOfTheWorlds.JPG to Kindle/Documents/LibraryCovers (using iPhone Explorer)

I first loaded the mobi files into Calibre so that I could get the cover image by doing the following:

• Click on the icon in the top left hand corner which looks like a book with a + sign on it
• Add books from a single directory
• Find the .mobi file you want to import
• Right click on the book
• Open containing folder

After I'd done that I needed to install 'mobi2mobi' in order to update the 'ASIN' number of the book. The Kindle application looks for a file with the same name as the ASIN number in the 'LibraryCovers' folder and uses that as the cover image for the book.

There are a crazy number of instructions to follow on the mobileread wiki in order to install this.

I followed these but was getting the following error when I tried to run the command:

Can't locate GD.pm in @INC (@INC contains: /Users/mneedham/eBooks/tools /Library/Perl/Updates/5.10.0/darwin-thread-multi-2level /Library/Perl/Updates/5.10.0 /System/Library/Perl/5.10.0/darwin-thread-multi-2level /System/Library/Perl/5.10.0 /Library/Perl/5.10.0/darwin-thread-multi-2level /Library/Perl/5.10.0 /Network/Library/Perl/5.10.0/darwin-thread-multi-2level /Network/Library/Perl/5.10.0 /Network/Library/Perl /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level /System/Library/Perl/Extras/5.10.0 .) at /Users/mneedham/eBooks/tools/MobiPerl/Util.pm line 23.
BEGIN failed--compilation aborted at /Users/mneedham/eBooks/tools/MobiPerl/Util.pm line 23.

I came across the following thread where pilotbob described a way to fix this:

I got it working on Snow Leopard. Here is what I did.

1. Install MacPorts… this will make it a whole lot easier. http://www.macports.org

2. Once you get ports installed use macports to install the gd lib stuff:
sudo port install gd2

This will also install perl 5.8.9… perl 5.10 comes with Snow Leopard. Not sure it any mac stuff requires that… but you can always go back, macports puts stuff in a separate location.

I also installed the following macports:

p5-gd
p5-palm
p5-timedate
p5-getopt-mixed
p5-image-size
p5-xml-parser-lite-tree
p5-encode

Then, I use CPAN to install the following… there didn't seem to be any macports for them:

HTML::TreeBuilder
Image::BMP

After that mobi2mobi ran… well it gave me the command line options. I didn't actually try it. But, it doesn't seem to run unless all the dependencies are there.

I tried to install all of those dependencies as he suggests although not all of them worked for me.

After I'd done that I went back to the mobileread wiki and re-ran the following commands:

sudo perl -MCPAN -e shell
 
install Palm::PDB
install XML::Parser::Lite::Tree
install GD
install Image::BMP
install Image::Size
 
install HTML::TreeBuilder
install Getopt::Mixed
install Date::Parse
install Date::Format

And after all that I was finally able to run 'mobi2mobi' to change the 'ASIN' of the file which can be done by executing the following command:

mobi2mobi my.mobi --outfile my.mobi --exthtype asin --exthdata "mycoverimage.jpg"

To get the Kindle application to pick up the new image I needed to be connected to the internet for some reason but all my books are showing with the correct covers now.

Jonas Boner recently linked to a really cool (and short) presentation by John Cleese about creativity which I think is very applicable to software development.

Cleese describes some observations he's made about creativity from his experiences working in comedy. These were some of the key ideas:

Plan to throw one away?

Cleese describes a situation where he wrote a script for Fawlty Towers and then lost it. He decided to rewrite it from memory and after he'd done that he found the original.

He was surprised to see that the rewritten version was actually an improvement over the original even though he'd written it much more quickly the second time and concludes that his unconscious mind must have still been working on the script even after he'd stopped writing it.

This seems to be similar to the ground that Fred Brooks was covering when he suggested that we should plan to throw one away because we will anyway.

It would be really interesting to see how much more quickly we'd be able to write a software system assuming all other things stay the same and we're able to build on the mistakes and things we learnt from the first attempt.

Sleeping on a problem

While discussing sketch writing Cleese points out that when he got stuck while writing at night and couldn't think what to write next he would just go to bed.

He found that when he woke up the next day and went back to the problem the solution was immediately obvious and he couldn't remember why he'd got stuck in the first place.

This is something that Andy Hunt talks about in Pragmatic Thinking and Learning as a useful technique for ensuring that we get our right brain involved in the problem solving process and I've written previously about the advantages of stepping away from a problem when we get stuck.

Creating a tortoise enclosure

Cleese suggests that we need to restrict both time and space in order to be creative.

We need to ensure that we set a restricted period of time during which we won't be disrupted and use that time to think.

The closest thing I can think of in the agile world is the idea of not context switching but it seems to go beyond that.

I like the underlying idea that we need to create some constraints in order for creativity to happen. It often seems like really good ideas come from someone being put in a situation where they can't do what they'd normally do and therefore need to innovate in order to 'survive'

Jez recently linked to a post written by Timothy Fitz about a year ago where he talks about the way his team use continuous delivery which means that every change made to the code base goes into production immediately as long as it passes their test suite.

I've become fairly convinced recently that it should always be possible to deploy to production frequently but we recently came across a situation where it seemed like doing that wouldn't make much sense.

The project involved replacing an existing website but rebranding it at the same time. One of the key goals of the project was to create a consistent brand across the whole site.

Therefore it seemed that if we chose to incrementally deploy to production then we'd need to spend some time updating the old website so that the look and feel was the same across both versions of the site.

The overall time to finish the project would therefore be higher and the value that we'd get from actually get from putting something into production early probably wouldn't justify the extra effort that it'd take to do so.

In this situation the most effective strategy seems to be to still deploy as frequently as possible to a production like environment internally but only deploy to live when the whole thing is done.

If we're replacing the backend of an old system and the end user won't see anything different then an incremental deployment approach is certainly worthwhile but when brand consistency is the most important thing I'm not sure that it still makes sense.

As always I'd be keen to hear if anyone's done anything similar and if there are any ways around this.

A mistake I've made more than a few times while declaring headers in Objective C is forgetting to explicitly import the classes used in the interface definition.

I've been refactoring some of the code I wrote earlier in the week and wanted to create a 'LabelFactory'. I had the following code:

LabelFactory.h

#import <UIKit/UIKit.h>
 
@interface LabelFactory : NSObject {
}
 
+ (UILabel*)createLabelFrom:(Project *)project withXCoordinate:(NSInteger)x withYCoordinate:(NSInteger)y;
 
@end

Which gives this error on compilation:

/Users/mneedham/SandBox/iPad/CIMon/LabelFactory.h:9:0 /Users/mneedham/SandBox/iPad/CIMon/LabelFactory.h:9: error: expected ')' before 'Project'

I've been wondering what that error message actually means for a while and more by accident than design I re-read the section of Apple's documentation on 'referring to other classes'

An interface file declares a class and, by importing its superclass, implicitly contains declarations for all inherited classes, from NSObject on down through its superclass. If the interface mentions classes not in this hierarchy, it must import them explicitly or declare them with the @class directive:

Declaring 'Project' with the '@class' directive just above '@interface' helps fix that problem:

...
@class Project;
 
@interface LabelFactory : NSObject {
 
}
...

The original error message I was getting is still slightly mystifying to me…

I spent a bit of time working through the first Micro Testing album of the Industrial Logic eLearning suite a few weeks ago and there's an interesting piece of advice towards the end of the album:

Microtesting is not a formula. It's a technique. When microtesting rigorously, you will be called constantly to make judgments like these, between one set of names and another, and their corresponding approaches.
Remember the judgment premise.

Don't let any technique or recommendation or rule of thumb become an excuse for not exercising your judgment.

While I think this is good advice I thought it was interesting that it seems to goes against the rules of thumb approach that I described in a blog post towards the end of last year.

It seems like Kerievksy and co are encouraging us to 'get out of the shu box', as Alistair Cockburn would put it, and into the reflective 'Ha' stage of the 'Shu Ha Ri' learning model.

• Shu, the student copies techniques without adapting them.
• Ha, the student reflects on what has been learned and breaks free from traditions.
• Ri, the student is now a practitioner extending the art.

I've previously written about my own learning style which seems to favour a strong adherence to practices without too much questioning while I get used to them although I appreciate that others seem to reach the reflection stage quicker than I do.

Talking with a colleague about the value of pair programming he described one team he'd seen that had decided that it was an unnecessary practice to follow even though they hadn't spent very long using it.

As a result the team had become very siloed with each team member becoming an expert in one area of the code base, eventually leading to a situation where it was impossible to rotate anyone on the team.

From my experience we end up with the same situation if we try to make a judgement call on when and when not to follow a practice without having sufficient experience to work out how we might need to vary its use in different circumstances.

The last paragraph of Rachel Davies' post also points this out:

Learning new ways of working takes time. As Ron Jeffries once said "They're called practices for a reason".."You have to have done them. Practice makes perfect."

It's certainly useful to get into the habit of reflecting on what we're doing but I think we also need to be aware that we may not yet have the experience to make every judgement.

One thing I noticed while pairing with some of the ThoughtWorks University guys a few weeks ago is that I had an almost overwhelming urge to show them all sorts of coding techniques that I've learned, probably to the point where it'd be more confusing than helpful.

JK pointed out that it's more effective to bite your tongue and just focus on one idea at a time which is something that the authors of Agile Coaching touch on briefly at the beginning of the book:

You're probably itching to get started, but where do you get started? There's no right place. The simplest approach is to pick one thing and jump in.

For example one story I joined involved adding a new feature which touched all layers of the application from the view through the service layer and to the database.

My favoured approach is to start from the UI and work out what we actually need to develop by starting from what the user will actually see i.e. outside in development.

The approach that had been taken on the story meant that the API of one of the services was being driven out straight from a service test rather than coming for a need for that method from the controller.

The reason I prefer to drive out a story from the outside in is that we don't have to try and imagine the way someone might want to use an object – we already know because we've written the consumer code for that method already.

While learning how to drive from the outside in is a useful skill, in this case the main skill that we were trying to encourage was test driven development and getting the grads used to the red – green – refactor cycle and so on.

Although it would have made our lives easier to stop and go and write the code for the controller which needed the service first, I think it would have been quite confusing to leave the service in a half completed state and move off to work on something else.

We therefore kept on working on the service code while trying to imagine exactly how it would be used by the controller.

While this wasn't the optimal way to develop this piece of code and perhaps took longer overall I think it was a more useful approach to take in this situation and is one I'd take again given similar circumstances.

One of the things that I've noticed as we've started writing more client side code is that I'm much more likely to look for a library which solves a problem than I would be with server side code.

A requirement that we've had on at least the last 3 or 4 projects I've worked on is to do client side validation on the values entered into a form by the user.

The jQuery.validate plugin is quite a good fit for this problem and as long as the validation is just on a field by field basis then it works fine.

On the last project I worked on, however, we had validation rules which had field interdependencies and suddenly we ended up writing a lot of custom code to handle that on top of what jQuery.validate already did.

Eventually we got to the stage where the code had become a complete mess and we decided to rewrite the validation code server side and only fire the validation when the user submitted the form.

In this situation that was an acceptable trade off to make but in another we may have needed to write our own Javascript code to handle the various validation rules.

In that case we'd probably want to write our own code to handle the inter field dependencies but still use jQuery.validate to handle individual field validation.

While thinking about this I was reminded of a post written by Michael Feathers back in 2003 where he discusses 'stunting a framework':

[...]let's think about great frameworks… erm.. there aren't many are there? In fact, even the good ones are a pain in the ass, aren't they? There was that time when we downloaded framework X and it took quite a bit of time to learn how to use it, and that other time when we thought it would be useful if only it did that, but we spent the next week trying to force it and…"

Framework use is hard, yet we keep trying. Why do we do it? Mainly because we want to [...] leverage the work of others. If we use someone's else framework, we may save some time. Moreover, we've benefited from someone's "crystalized thought," thought in the form of working code. The code shows a proven way of doing things and if it's well-designed it can accommodate our thoughts and we can roll them back to the community.

Although the majority of the article is talking about frameworks from the angle of avoiding the temptation to create frameworks, I think it's interesting to consider whether we always need to use a framework.

One other area where I've noticed we instinctively turn to a framework is when we have to interact with a database. The instinct is to straight away use Hibernate/NHibernate/ActiveRecord when frequently the initial use case doesn't really require their use.

However, if we don't make that decision up front then we need to be quite vigilant about observing the point at which we're actually just reinventing the wheel rather than making a pragmatic decision not to use an ORM tool.

There are certainly other considerations to make when deciding whether to use a library or not such as our familiarity with it and its reputation/reliability in the community but it is still a decision point and one that I've frequently not recognised as being one and just gone straight for the library option.

Sumeet recently blogged about the new style ThoughtWorks University that he and the other trainers have introduced and although I only got to see it in action for a few days it seemed clear to me that it was an improvement on the original version.

The questions being asked, discussions being had and situations that were coming up were pretty much the same as I've seen on any software project that I've worked on.

One particularly interesting thing which came up a few times was that there was a 'them vs us' feeling between the analysts and developers.

This is certainly an example of a situation which didn't come up on the project when I participated in ThoughtWorks University 4 years ago where we only had a one week simulation.

It is however a situation that does come up and on the projects I've worked on it certainly can feel like you're fighting the analysts. They're trying to balance the wishes of the client as well as those of the developers and to developers it can often seem that the analyst is just being difficult for the sake of it.

The cool thing was that the grads then came up with different potential solutions to this problem and they were pretty much the same solutions that we've used on projects I've worked on.

While discussing a different topic with Dave Cameron he pointed me to the Wikipedia entry for 'situated cognition' which "posits that knowing is inseparable from doing by arguing that all knowledge is situated in activity bound to social, cultural and physical contexts".

The following quotes seem to explain why, in my experience at least, I learn way more effectively when working with colleagues on projects than I could ever do on an out of context training course:

Knowing emerges as individuals develop intentions through goal-directed activities within cultural contexts which may in turn have larger goals and claims of truth.

Knowing is expressed in the agent's ability to act as an increasingly competent participant in a community of practice.

Learning must involve more than the transmission of knowledge but must instead encourage the expression of effectivities and the development of attention and intention that reflect real life learning processes

I think this new style TWU gives grads an even better start to their ThoughtWorks lives and I hope to take part as a trainer for one of the terms later in the year.

As I mentioned in a post I wrote last week I've been writing a little iPad application to parse a cctray feed and then display the status of the various builds on the screen.

The way I've been doing this is by dynamically adding labels to the view and colouring the background of those labels red or green depending on the build status.

FirstViewController.h

@interface FirstViewController : UIViewController {
	...
	NSMutableArray *dynamicallyAddedFields;
}

FirstViewController.m

@implementation FirstViewController
 
- (void)viewDidLoad {
	...
	// parse xml and put projects into 'theDelegate.projects
 
	NSInteger x = 30;
	NSInteger y = 0;
	NSInteger column1 = true;
 
	dynamicallyAddedFields = [[NSMutableArray alloc] init];
 
	for(Project *project in theDelegate.projects) {		
		if(column1) {
			x = 30;
			y = y + 110;
			column1 = false;
		} else {
			x = 290;
			column1 = true;
		}
 
		UILabel *aLabel	= [self createLabelFrom:project withXCoordinate:x withYCoordinate:y];
 
		[dynamicallyAddedFields addObject:aLabel];
		[self.view addSubview:aLabel];	
	}
}

-(UILabel*) createLabelFrom:(Project *)project withXCoordinate:(NSInteger)x withYCoordinate:(NSInteger)y  {
	// code to create a label
}

The full code is on github and this is what the application looks like when launched in the simulator:

I'm storing each of the labels inside 'dynamicallyAddedFields' so that I can easily remove them and then redraw new ones with the new feed url when the user clicks on the 'Go' button. I saw a similar idea suggested in an iPhone Dev SDK article.

The 'Touch Up Inside' event of the 'Go' button is hooked up to the 'changedFeedUrl' method inside my view controller as described in Brandon Treb's blog.

The code to handle the button being pressed is as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

- (IBAction) changedFeedUrl:(id) sender {		
	for (id item in dynamicallyAddedFields) {
		[item removeFromSuperview];
	}
	[dynamicallyAddedFields removeAllObjects];	
 
	// parse xml and put projects into 'theDelegate.projects
 
	NSInteger x = 30;
	NSInteger y = 0;
	NSInteger column1 = true;
	for(Project *project in theDelegate.projects) {		
		if(column1) {
			x = 30;
			y = y + 110;
			column1 = false;
		} else {
			x = 290;
			column1 = true;
		}
 
		UILabel *aLabel	= [self createLabelFrom:project withXCoordinate:x withYCoordinate:y];
		[dynamicallyAddedFields addObject:aLabel];
		[self.view addSubview: aLabel];
 
	}	
}

In order to redraw all the labels I had to first remove them all from their super view (line 3).

We then have the same code as in the 'loadView' method – copy and pasted for now – to add the new labels to the screen.

Although this code does what I want it is very hacky so I'd be grateful for any tips on how I can achieve the same thing in a cleaner way.