Mark Needham

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.

Dave Astels mentions in his BDD paper that the way we use language influences the way that we write code, quoting the Sapir-Whorf hypothesis

“there is a systematic relationship between the grammatical categories of the language a
person speaks and how that person both understands the world and behaves in it.”

In a similar way, something which I didn't fully appreciate until the last project I worked on is how much the tools and techniques that you use can influence the way that you work.

Distributed Source Control

Christian persuaded the client to allow us to use Mercurial for the project and it was interesting to see how we almost instinctively moved to a style of development which involved checking in much more frequently than we would have had we used Subversion.

There were still times when we'd end up working on something locally for too long but it seemed to become much more visible when this was happening and the endless ribbing that a pair got when they hadn't checked in for a while ensured that it didn't last for long.

I'm sure there are ways that we could have used Mercurial even more effectively than we did and my current thinking is that by default we'd want to use a distributed source control tool over any other.

Incremental refactoring

Incremental refactoring is a concept that Dave Cameron introduced me to about a year ago and it's been talked about recently by Kent Beck and Joshua Kerievsky.

The underlying idea is that we know we want to drive our code in a certain direction but we want to do so in a way that doesn't leave our code base in a broken state while we're working towards that.

The techniques these two describe help to remove the fear and paralysis that we can often feel when we want to change a significant part of the code but know that we don't have the time to do that all at once.

Not copying and pasting tests

I've previously mentioned a post Ian Cartwright wrote a while ago where he suggested that we should treat test code the same way that we treat production code, along the way pointing out that this meant copy/pasting tests was not the way to go.

I gave the non copy/paste approach a try last year and an interesting thing that I noticed is that when you have to type out the same types of things repeatedly you become much more aware of the duplication that you're creating and since it's costing time doing so you quickly look for ways to improve the situation.

Once we've got our tests cut down to the stage where removing any more duplication would also remove the intent of the test it doesn't seem too bad to copy the outline of tests and then change the details.

We probably can move slightly faster by using copy/paste at this stage rather than writing everything out but the amount of time saved as a total of all development effort is minimal.

I think avoiding copy/paste puts us in a much more resourceful mindset and allows us to see improvements that we otherwise wouldn't see and this it the real benefit of this technique.

Alan Skorkin has a cool post from a few months ago where he talks about the benefit of thinking about the code we're writing rather than just going into auto pilot which covers similar ground.

Living prototypes

This is an idea that we used on my last project whereby we had a prototype of the website being developed alongside the real version.

This approach was necessary for this particular client but I really like the idea of having the real UI being developed alongside the code as it meant that whenever we showcased what we'd done to the client it was actually exactly what the final product would look like.

On previous projects we've often driven out the back end code and then styled it later which leads to a lot of questions about the UI when showcasing which may not actually be relevant when it's properly skinned.

It also helped avoid the redundancy of showcasing something twice – once early on with just the functionality and then later on after the styling has been applied.

As I mentioned in my previous post about parsing an XML file in Objective C I'm a novice on the Dreyfus Model when it comes to this type of development and I've found it interesting that I've dropped back into habits from my PHP days when I was first learning how to program.

The big picture

My first instinct after I'd created a project in XCode was to try and understand how an iPad application fits together.

While this approach has worked fairly well for me in languages that I'm familiar with I found that I ended up shaving multiple yaks all at once.

I know too little about all of the individual components such that when I start reading how they all work together I end up veering off track and reading about how each of the components work on their own.

For the moment I've put the big picture to one side and I'm just trying to understand the ins and outs of the language by hacking bits of code together.

Copy/Paste/Change/Comment

Talking about hacking code, I've found myself copying and pasting example code that people have posted and then tweaking it bit by bit, re-running the code each time to check I haven't broken anything.

Eventually I'll need to learn how to write the code from scratch but at the moment I make way too many mistakes that the copy/paste approach gives me quicker feedback about how the language works.

When the code stops working I find myself commenting out code until I get it back into a working state because I'm not yet able to intuitively narrow in on where the problem might be.

Limit the hours a day

Perhaps due to the frustration of everything being a struggle I find that I'm quite mentally fatigued after coding for a few hours.

On the days when things work more frequently than not I find that I can code for longer but at the moment I'm finding it more beneficial to stop coding when I'm getting too frustrated and then pick it up later.

Quite frequently I'll work out how to do something that I was really struggling with after leaving it for a while.

TDD…

Despite being a big fan of Test Driven Development I haven't written a single test in Objective C yet.

While that will probably be the most effective way to develop code, as I've previously suggested, I don't necessarily think it's the most effective way to learn a new language.

The feedback loop is slowed down as you first try and setup a testing framework and because you don't know the syntax that well it'll probably be a bit of a struggle to get a test setup.

Writing a bit of code and then compiling and running it provides a feedback loop which is working fine for me at the moment although I'm sure at some stage I'll drift back towards my TDD roots.