Flexible Diamond

What’s the point of all this mockery?

jamesk — Wed, 19 Aug 2009 21:53:28 +0000

I’ve jumped in with both feet, without pausing to explain why I’m doing it – so, where do mock objects fit into my daily testing behaviours?

when the system under test relies on an expensive resource
when the system under test relies on a live resource
when the system under test relies on a resource that doesn’t yet exist
when I want to ensure that the system under test uses the resource correctly

I had to build a couple of client applications recently (twitter and flickr, since you ask – talk about re-inventing the wheel …), which interacted with what I consider expensive resources – firstly, I was contacting the remote flickr servers and awaiting their response each time I tested; secondly, the twitter API puts limits on how often it’s called, which means that I could run out of calls pretty quickly if every test made at least one call, and all tests were run each time I compiled the movie.

A couple of years ago, we built a googlemaps-stylee flash app for a certain weekend-break company to allow users to choose chalets (/lodges/huts/accommodation units – bizarrely ‘accommodation units’ was the official term) online. The units’ availability was updated in real time, so the app had to query the server for the latest data. The only problem with this was that the server application was still under design – it didn’t yet exist.

I’ve also worked with database developers who haven’t yet finalised their DB structure, and who keep dropping and re-building the database, which means deleting all the data that my test scripts rely on.

You only need to experience difficulties such as these a couple of times to realise that it’s imperative to have control of the remote/live/non-existent/under-development resource in order for the tests to be of any use.

The good news is that – in most cases – it’s possible to define an API for communication with the resource even before it exists, and that’s what makes mock objects so useful – they can honour the API, thus enabling the code we build against the tests to work against the resource when it’s ready.

Strikes me an example might be useful. Twitter suit you?

I have a TwitterView object, which takes a TwitterProxy which in turn communicates with the Twitter servers. I know it’s terrible – aren’t these chaps supposed to be cleanly separated? The TwitterView receives an event when the proxy has done all its loading, and then can populate the relevant TextFields. Easy, innit.

public class TwitterView extends Sprite {
private var title:TextField;
private var tweets:TextField;
private var proxy:ITwitterProxy;
public function TwitterView(proxy:ITwitterProxy = null) {
this.proxy = proxy;
initView();
setTitle("Hello World!");
}
public function getTitle():String {
return title.text;
}
public function setTitle(title:String):void {
this.title.text = title;
}
public function setTweets(tweets:Array):void {
this.tweets.htmlText = tweets.join("\n\n");
}
override public function toString():String {
return "[TwitterView]";
}
public function init():void {
if(proxy == null) {
proxy = new TwitterProxy();
}
proxy.addEventListener(TwitterLoadEvent.TWITTER_LOADED, onTwitterLoaded);
proxy.init();
}
private function initView():void {
title = new TextField();
title.autoSize = TextFieldAutoSize.LEFT;
addChild(title);
tweets = new TextField;
tweets.width = 500;
tweets.autoSize = TextFieldAutoSize.LEFT;
tweets.wordWrap = true;
tweets.y = title.y + title.height + 10;
addChild(tweets);
}
public function onTwitterLoaded(event:TwitterLoadEvent):void {
setTitle(event.proxy.getTitle());
setTweets(event.proxy.getTweets());
}
}

In the onTwitterLoaded function, you can see the two most important calls that we need to make on the TwitterProxy: getTitle() and getTweets(). I put these in the ITwitterProxy interface.

public interface ITwitterProxy extends IEventDispatcher {
function getTweets():Array;
function getTitle():String;
function init():void;
}

So now we have a fairly basic view, which expects its data from the proxy.

Let’s see it in action, courtesy of TwitterApp. Yep, not much happening:

public class TwitterApp extends Sprite {
public function TwitterApp() {
init();
}
private function init():void {
var view:TwitterView = new TwitterView();
addChild(view);
view.init();
}
}

We want to practise test-driven development – write a failing test > code until it passes > write another test > refactor – so we want to write a unit test that will check the view’s title and tweets, but (a) we can’t rely on the live twitter data as it will change over time, and (b) we don’t want to run up against the limit of API calls that we can make. Time for a mock object, methinks.

Firstly, I’m using ASUnit rather than FlexUnit, so if you’re following along, you’ll need to grab that and the ASUnitMockitoTestCase bridging class that I published one or two articles ago. Let’s start with a skeleton testcase:

public class TwitterTest extends ASUnitMockitoTestCase {
public function TwitterTest(testMethod:String = null) {
super([], testMethod);
}
public function testBasic():void {
assertTrue("failing test", 1 + 1 == 5);
}
}

Notice that we have a basic test that will show up as a fail in ASUnit, so that we can be sure that we’ve hooked everything together successfully. As soon as you see the fail, you can delete it. Note also that the call to super() starts with an empty Array – in time we’ll populate with the classes that we wish to set up as mocks.

Now, let’s pause for a think about what we want to test here – the View relies on the proxy for its data, so we want to check that the view gets its data successfully from the proxy without hitting the live Twitter servers. Oh, and the proxy doesn’t exist yet, just an interface.

I’m going to start really slowly here, forgive me – adding the assert that checks the view’s title.

public class TwitterTest extends ASUnitMockitoTestCase {
public function TwitterTest(testMethod:String = null) {
super([], testMethod);
}
public function testViewGetTitle():void {
assertEquals("Twitter updates", view.getTitle());
}
}

Immediate compile error, since we haven’t declared view, so let’s add another line:

var view:TwitterView = new TwitterView();
assertEquals("Twitter updates", view.getTitle());

Still no success, because the TwitterView cannot be instantiated without a ITwitterProxy, which we don’t have, so let’s mock that (note that I’ve also added ITwitterProxy to the super() in the TwitterTest() constructor).

public class TwitterTest extends ASUnitMockitoTestCase {
public function TwitterTest(testMethod:String = null) {
super([ITwitterProxy], testMethod);
}
public function testViewGetTitle():void {
var mockProxy:ITwitterProxy = mock(ITwitterProxy) as ITwitterProxy;
var view:TwitterView = new TwitterView(mockProxy);
view.init();
assertEquals("Twitter updates", view.getTitle());
}
}

Huzzah – the movie compiles and we get our failing test For the record, mock() takes the interface and builds an object based on it that will record all calls made on its methods – it’s very, very clever.

First thing, let’s set the mockProxy up to give us the title string that we expect – add this line above the creation of the view:

given(mockProxy.getTitle()).willReturn("Twitter updates");

This beautiful line of code says: if someone calls getTitle() on the mockProxy, the mockProxy will return “Twitter updates”. Isn’t that cool? Of course, that doesn’t help pass the test just yet.

The view is expecting to receive a TwitterLoadEvent from the proxy, triggering onTwitterLoaded(), so our mock object needs to have IEventDispatcher functionality. However, because the mockObject does so much weird stuff behind the scenes that I don’t have (and don’t want to have) a clue about, I’m going to attack this another way.

given(mockProxy.addEventListener(any(), any())).will(fireImmediateLoadEvent);

When mockProxy.addEventListener() is called, it will fire an immediate load event – this is mocking the request/response communication with the Twitter server. So what’s fireImmediateLoadEvent?

It’s a GenericAnswer object, which just holds a function that will be called when addEventListener() is called; in this case I want it to be like this:

var fireImmediateLoadEvent:Answer = new GenericAnswer(
function():void {
// record the event and eventHandler somehow
// then immediately fire the event with the required data
}
);

Of course, in the real world, the proxy will be doing this as part of its work, but because we’re using a mock proxy, we have to work around it a bit. I’ve come up with this:

var d:EventDispatcher = new EventDispatcher({} as IEventDispatcher);
var fireImmediateLoadEvent:Answer = new GenericAnswer(
function():void {
// record the event and eventHandler somehow
d.addEventListener(TwitterLoadEvent.TWITTER_LOADED, view.onTwitterLoaded);
// then immediately fire the event with the required data
d.dispatchEvent(new TwitterLoadEvent(mockProxy));
}
);

So now the test looks like this:

public function testViewGetTitle():void {
// create an EventDispatcher that can be used as the dispatching functionality for
// the mock ITwitterClient
var d:EventDispatcher = new EventDispatcher({} as IEventDispatcher);
var mockProxy:ITwitterProxy = mock(ITwitterProxy) as ITwitterProxy;
given(mockProxy.getTitle()).willReturn("Twitter updates");
given(mockProxy.getTweets()).willReturn(["Tweet#1", "Tweet#2", "Tweet#3"]);
var view:TwitterView = new TwitterView(mockProxy);
var fireImmediateLoadEvent:Answer = new GenericAnswer(
function():void {
// add the listening class
d.addEventListener(TwitterLoadEvent.TWITTER_LOADED, view.onTwitterLoaded);
// then immediately fire the event – this mocks the XML-loading that really occurs
d.dispatchEvent(new TwitterLoadEvent(mockProxy));
}
);
given(mockProxy.addEventListener(any(), any())).will(fireImmediateLoadEvent);
view.init();
assertEquals("Twitter updates", view.getTitle());
}

For completeness, here’s TwitterLoadEvent:

public class TwitterLoadEvent extends Event {
public static const TWITTER_LOADED:String = "onTwitterLoaded";
private var _proxy:ITwitterProxy;
public function TwitterLoadEvent(proxy:ITwitterProxy) {
super(TWITTER_LOADED, false, false);
_proxy = proxy;
}
public function get proxy():ITwitterProxy {
return _proxy;
}
}

Readers who viewed this page also viewed:

About Us

Mocking slavery

jamesk — Thu, 30 Jul 2009 17:50:41 +0000

New to the idea of such mockery, I was very lucky to find a tutorial using the Java version which I could convert as I worked through it.

Now I’m converted – it’s a very neat and fast way of stubbing out the behaviours that I wish to code.

This morning, however, I came across a slightly trickier case to mock – at least, a case that required trial and error, as it hasn’t been documented that fully.

I have a slave interface:

public interface ISlave {
function doSthg():String;
function order(command:String):void;
function answer():String;
}

And the behaviour I want is that when a slave is ordered to “doSthg!”, it should answer() and doSthg() pretty sharpish. So the test looks like this:

slave.order("doSthg!");
verify().that(slave.answer());
verify().that(slave.doSthg());

To verify().that(slave.answer()) means to verify that slave.answer was called once.

First off, I needed to define the doSthg() and answer() methods, having created a mock slave from the interface (both return a String object):

var slave:ISlave = mock(ISlave) as ISlave;
given(slave.doSthg()).willReturn("done!");
given(slave.answer()).willReturn("yessir!");

And then I came to the tricky bit – since I’m creating this object out of an Interface definition how can I define the behaviour of slave.order()?

Well, thankfully the GenericAnswer object literally holds the answer to that question – it is instantiated with a function thus and given to the mock slave.order (if the call parameter is correct!):

var answer:Answer = new GenericAnswer(
function():void {
trace(slave.answer());
trace(slave.doSthg());
}
);
given(slave.order(eq("doSthg!"))).will(answer);

So now I have created an ISlave interface with three public methods, and defined how the methods interact, and precisely what parameter in order() will trigger the correct interaction. In full it looks like this:

var slave:ISlave = mock(ISlave) as ISlave;
given(slave.doSthg()).willReturn("done!");
given(slave.answer()).willReturn("yessir!");
var answer:Answer = new GenericAnswer(
function():void {
trace(slave.answer());
trace(slave.doSthg());
}
);
given(slave.order(eq("doSthg!"))).will(answer);
slave.order("doSthg!");
verify().that(slave.answer());
verify().that(slave.doSthg());

P.S. Obviously, the slave should not have a order() method – that’s the responsibility of the master (e.g. master.order(slave, “doSthg!”)), but it serves to make this example work, so forgive me!

Readers who viewed this page also viewed:

What’s the point of all this mockery?

Mockito-Flex meets ASUnit

jamesk — Thu, 30 Jul 2009 17:50:20 +0000

Well, that’s not a catchy headline, but it does pretty much sum it up. I’ve been playing with Mockito-Flex, a mock object framework for Actionscript 3. It’s great, and made vastly easier to pick up by a Mockito-FlexUnit bridge in the form of a MockitoTestCase that does the hard work of reporting the mocking results and validations in a way that FlexUnit can display.

Of course, FlexUnit does require the Flex framework, which bulks up the whole thing. Oh, and I’m used to using ASUnit. So I’ve written the following class that does the same job as MockitoTestCase, but for ASUnit:

/**
* The MIT License
*
* Copyright (c) 2009 Mockito contributors
*
* Permission is hereby granted, free of charge, to any person obtaining a copy of this software
* and associated documentation files (the "Software"), to deal in the Software without restriction,
* including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so,
* subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
* INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE
* AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
* DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
package org.mockito {
import asunit.framework.TestCase;
import org.mockito.api.Matcher;
import org.mockito.api.MethodSelector;
import org.mockito.api.MockCreator;
import org.mockito.api.Stubber;
import org.mockito.api.Verifier;
public class ASUnitMockitoTestCase extends TestCase {
private var _mockClasses:Array;
protected var mockito:Mockito;
public function ASUnitMockitoTestCase(mockClasses:Array, testMethod:String = null)
{
_mockClasses = mockClasses;
super(testMethod);
}
/**
* Due to the asynchronous nature of the class generation
* a test needs to execute from a callback function
*/
public override function run():void
{
if (mockito == null && _mockClasses)
{
mockito = new Mockito();
var superRun:Function = super.run;
mockito.prepareClasses(_mockClasses, repositoryPreparedHandler);
function repositoryPreparedHandler():void
{
superRun();
}
}
else
{
super.run();
}
}
/**
* Constructs mock object
* @param clazz a class of the mock object
* @param constructorArgs constructor arguments required to create mock instance
* @param name a name used in various output
* @return a mocked object
*/
public function mock(classToMock:Class, name:String = null, constructorArgs:Array = null):Object
{
return mockito.mock(classToMock, name, constructorArgs);
}
/**
* A starter function for verification of executions
* If you dont specify the verifier, an equivalent of times(1) is used.
* @param verifier object responsible for verification of the following execution
*/
public function verify(verifier:Verifier = null):MethodSelector
{
return mockito.verify(verifier);
}
/**
* A starter function for stubbing
* @param methodCallToStub call a method to stub as an argument
* @return an object providing stubbing options
*/
public function given(methodCallToStub:*):Stubber
{
return mockito.given(methodCallToStub);
}
/**
* @private
*/
protected function get mockCreator():MockCreator
{
return mockito;
}
/**
* Matches any argument including null
*/
public function any():*
{
return mockito.any();
}
/**
* Equality matcher
* Example:
*
* verify(never()).that(system.login(eq("root")));
*
*/
public function eq(expected:*):*
{
return mockito.eq(expected);
}
/**
* A fluent interface for making sure call hasn't happened
* Example:
*
* verify(never()).that(operator.execute());
*
*/
public function never():Verifier
{
return mockito.never();
}
/**
* A fluent interface for counting calls
* Example:
*
* verify(times(2)).that(operator.execute());
*
*/
public function times(expectedCallsCount:int):Verifier
{
return mockito.times(expectedCallsCount);
}
/**
* A fluent interface for custom matcher
* Example:
*
* verify().that(system.login(argThat(new HashOnlyCapitalLettersMatcher())));
*
*
* A good practice is to create a matcher recording function somewhere and name it
* after the matcher. It's important to return a wildcard from the function to let it
* work with any arugment of the function
*
* function hasOnlyCapitalLetters():*
* {
* argThat(new HashOnlyCapitalLettersMatcher());
* }
*
*/
public function argThat(matcher:Matcher):*
{
return mockito.argThat(matcher);
}
}
}

I’ve built this against ASUnit3, and it appears to be running fine. As you can see, it’s release under the MIT license, as is Mockito-Flex. I’d appreciate any feedback that’s going, so have a play and let me know …

Readers who viewed this page also viewed:

Testing Proxies in PureMVC

Rocks into Gold

jamesk — Sun, 21 Dec 2008 23:25:23 +0000

Clarke Ching – whose work I’ve been reading for a while, is preparing to publish a short parable for these troubled times. Get in touch with him via this post, and grab a copy, after all the more weapons in our armoury, the better chance we have of winning the inevitable battles.

Wacky agile zealots are at it again

jamesk — Sat, 22 Nov 2008 23:11:26 +0000

This post reminded me of a long drive around Eastern Scotland at the start of this weekend.

I had a printout of the route from Aberdeen to Boat-Of-Garten from the AA website. Matt had his TomTom. Rather than shuffling papers, I agreed to use the gadget, so Matt tapped in Boat Of Garten, and off we went.

Despite knowing that Aberdeen airport is northwest of the city, and that we would be driving further northwest still, I didn’t complain when the TomTom took us around Aberdeen and southward down the coast – after all, there was bound to be a good reason, wasn’t there.

We were also extremely hungry and looking for food as much as roadsigns. (Incidentally, we found the first ever chippy that’s asked me which of a selection of batters I’d like – how good is that?).

The mileage remaining got less and less, and we were still driving along a large clear road in a fairly low-lying area, but my suspicions were rising. When we found ourselves on the Dundee bypass, I knew something was up. The TomTom was taking us to a non-existent destination, which had added two hours to our journey.

Finally, we got onto the main road north, and hammered along in the gloaming. Fantastically for a southerner, the sky remained light until 11pm, so the driving wasn’t that painful. But, even so, we had a deadline: the B&B owner wanted us there by 10pm, so we made a series of grovelling phone calls as we got closer and closer.

It stuck in my memory as just another random irritating drive until reading Those wacky agile zealots are at it again, when the greater implications became clear.

Even when the route, timings, are as clear and as well-defined as they can possibly be, we still need to keep our eyes on the road, not just for rabbits and corners, but also to check that the route is correct (or, in this case, the destination).

I want problems, not solutions!

jamesk — Tue, 19 Aug 2008 10:39:11 +0000

So, there I was, quietly listening into a conference call between a couple of clients on one side, and the account manager, project manager and me on the other.

We were going through a small project that we’d just completed for the purposes of getting sign-off. We had built in the functionality they wanted, using the designs that they’d agreed to, so it was plain sailing.

And then the spanner.

Part of the project is a news article page with a sidebar listing other news articles. The client decided that he wanted to be able to filter these. “Could we add a couple of dropdowns listing the article categories?”.

That was the point when my anticipated reality and real reality diverged:
- anticipated reality: AM says “Sure, we’ll have a think about the best way to implement filtering, and present a couple of options back to you”.
- real reality: PM says “Right, we’re going to add a couple of dropdowns below the list, one for ‘projects’ and one for ‘countries’ and they’ll alter the article list you see”.

After the phone call, the PM asked me to go ahead with it. Eh? Shouldn’t we get a designer on the job – someone who knows about usability and interface design, perhaps?

I thought I’d won that little spat when the PM sloped off, but she got a tester who wants to be a designer to photoshop exactly what the AM had suggested on the phone. Bang went any hope of getting an expert in human computer interaction on the job.

The Account Manager’s defense is that we’re doing what the client wants. Well, I counter, that’s not good enough – despite my previous post saying that we “pretend the client knows what they want”, we shouldn’t allow them to define the solution. Yes, sure that’s what the client thinks they want, but we are being paid to know better.

I may know what I want to eat when I go to a restaurant, but I still like to hear what the specials are, just in case there’s something even more exciting. I may even know how to cook the dish, but that doesn’t mean they’re going to allow me to roll my sleeves up and get to work in the kitchen. I am paying for the chef’s expertise, and for the satisfaction of delegating a whole bunch of thinking and labour so that I can enjoy the fruits.

Yes, the client should be right in there defining the problem. Then we should check it and redefine it, and again and again, until we’re absolutely clear about it. Then we should get an expert (maybe a few, even, bringing different viewpoints together) to draw up a solution or two, and present those back to the client. “But it’s just a simple change” the AM cries, except that it isn’t, because it hasn’t been fully defined.

The wannabe-designer did a great mock-up, but couldn’t tell me how the functionality should work – there were different colours of text indicating selected states, but she didn’t know how that would work between the two dropdowns. In short, the solution wasn’t a solution. Meanwhile, the developers aren’t clear what they should be building, the project manager’s frustrated because she thinks that the project is now in development (well, she got us the designs, didn’t she?), and the account manager’s having to deal with an increasingly impatient client who thought the solution was defined over the phone.

If the client’s paying good money for our services, we should provide those services. That’s the clearest thing, isn’t it? We are digital experts: strategy, user experience, design, technical development. The client is an expert in marketing and sourcing quality work (I hope). One side should be bringing a problem, the other a set of solutions. Now, which is which?

Readers who viewed this page also viewed:

About Us

Testing Proxies in PureMVC

jamesk — Wed, 11 Jun 2008 13:13:25 +0000

This post is prompted by Larry Marburger’s article, since I came across this problem a few weeks ago, and found a different solution.

The scenario
There’s this great new framework that you’re starting to use, and it’s persuaded you to turn a new leaf and unit-test your work as you go. First off, be warned this is all AS2.0, using asunit2.5, because I’m still stuck in the dark ages

The problem
PureMVC uses Proxy objects to access data from the model, which fire off Notifications (PureMVC-specific events) when the data is ready. However, in the case of a Proxy that loads XML before making its data available, how do we know when it’s ready to be tested?

Solution
Mediator objects sign up to receive notification of Proxy events in PureMVC, so we can subclass the Mediator to create a class that can run tests on the Proxy.

Example please
ASUnit calls run() for every TestCase in the TestSuite, the default implementation of which calls runNow() to run the tests within a class. So I’ve overridden run() to create the Proxy we want to test. When the Proxy is ready, it will notify the TestCase, and runNow() will be called.

In order to achieve this, I’ve created a TestHelper, which subclasses Mediator, to capture the Proxy’s completion Notification. The TestHelper tells the TestCase that it’s good to go, and runNow() gets called.

A thousand words

Implementation Specifics

First, the class we’re interested in, and as you can see, it’s very simple. It registers with the PureMVC ApplicationFacade for Events.XML_LOADED Notifications, and calls the responseHandler it was given by when created by NavigationProxyTest (runNow()).

import org.puremvc.as2.interfaces.IMediator;
import org.puremvc.as2.interfaces.INotification;
import org.puremvc.as2.patterns.mediator.Mediator;
import Events;
class NavigationProxyTestHelper extends Mediator implements IMediator {
public static var NAME:String = "NavigationProxyTestHelper";
private var _responseHandler:Function;
public function NavigationProxyTestHelper(view:Object, name:String) {
super(name || NAME, view);
}
public function listNotificationInterests():Array {
return [Events.XML_LOADED];
}
public function handleNotification(notification:INotification):Void {
switch(notification.getName()) {
case Events.XML_LOADED:
_responseHandler();
break;
}
}
public function setResponseHandler(response:Function):Void {
_responseHandler = response;
}
}

The NavigationProxyTest TestCase sets up the TestHelper in run(), and registers it with the ApplicationFacade. Then it creates the NavigationProxy instance that we want to test. When the Proxy is fully-loaded and raring to go, TestCase#runNow() will be called, which calls all methods starting “test” – so in this example testValuesFromXML().

class NavigationProxyTest extends TestCase {
private instance:NavigationProxy;
public function run():Void {
var mediator:NavigationProxyTestHelper = new NavigationProxyTestHelper(
createEmptyMovieClip("empty_mc", 1),
NavigationProxyTestHelper.NAME
);
ApplicationFacade.getInstance().registerMediator(mediator);
NavigationProxyTestHelper(mediator).setResponseHandler(
Delegate.create(this, runNow)
);
instance = new NavigationProxy("navigation.xml");
}
public function testValuesFromXML():Void {
// initialDestination & showIntroVideo are found in the XML that the NavigationProxy loads
assertEquals("destinationID = 72", 72, instance.initialDestination);
assertFalse("showIntroVideo = true", instance.showIntroVideo);
}
}

Readers who viewed this page also viewed:

Mocking slavery

A grown-up conversation

jamesk — Tue, 20 May 2008 17:02:56 +0000

Several places I’ve worked have spoken about the client in two contrasting ways: one, hushed tones suggesting that they’re too sensitive to handle whatever reality we’re dealing with; two, derision suggesting that they’re too much of an idiot to understand whatever reality we’re dealing with.

Both are clearly untrue (to greater or lesser degrees), and both serve to make our jobs harder because they distance us from the most important person in any project.

So here’s a list of questions I would like answered:

why do we keep secrets from clients?
why are we so keen to promise tight deadlines?
why do we try to squeeze in extra stuff for them?
what if we treat them as part of the team?
what if we made them fully aware of the repercussions of their decisions?
what if we made demands of them, in order to deliver
what if we explain how risk builds up, and what they can do to mitigate it?

I honestly don’t understand the prevailing attitude towards client in my industry – after all, we can view them as the other, or we can view them as our extension in another organisation, where they have their own set of clients that they are trying to satisfy. After all, we do what we do in order to succeed don’t we, to work our way up the ladder? If my job becomes one of enabling Joe Client to do well in his job, then he and I are allied with a common purpose, rather than sitting opposite each other across the client-agent divide (which is what creates the kind of attitudes I mentioned at the start).

So let’s pretend that clients know what they’re talking about, and that we are there to support them when they don’t. And let’s start down that path by having sensible grown-up conversations with them where we are open about the effect that they have on the success of the project.

Project in distress (IV)

jamesk — Fri, 16 May 2008 09:25:12 +0000

I particularly like this one: a week has passed, whilst the project manager has been “working” with the designer on the definition of 3D behaviour of playing cards on the site. His output landed in my in box yesterday afternoon: it was a list of cards, and the places they would sit in on the site.

This information was available in the original pitch document! So has it really taken a week to change the document format?

Finding out what’s best …

jamesk — Wed, 14 May 2008 21:20:14 +0000

Just doing our best ain’t good enough – we need to be more savvy than that and work out precisely what’s the best thing to do first. So far, we’ve identified the conflict, and we now need to assess possible solutions.

If you haven’t read It’s not rocket science yet, please do first, as this article is a continuation of that theme.

I’ve said that key to a successful project is not just having everyone involved do their best, but having them work out what is the best thing to do, and then do their best at that. Anything else is at best a waste of effort, and at worst will doom a project.

I’ve also said that a sucessful project, just as any other system, needs a systemic view, rather than a bunch of local team views (new business, project management, creatives, developers, etc.).

So, how on earth do we go about finding out what’s best from a systemic perspective? A good place to start may be looking at some of the gripes that sit uncomfortably between teams involved in a project.

For example:

Project Manager (PM): developers’ estimates are always wrong.
Developer: PMs treat our estimates as promises, and thus can’t handle it when they turn out to be inaccurate.

Let’s think about lines on a graph: x axis denotes time; y axis denotes understanding. At the very start of the project, my understanding of what’s involved is minimal. At the end of the project, I know all there is to know about it (ah, the beauty of hindsight!). Between those two points, the line rises in a sloping curve, with most altitude gained in the first half of the project.

Where does estimation take place? Early on in the project, where understanding is incomplete (often requirements are incomplete too).

And that’s only the first problem. Here’s a second: when we estimate towards the start of a project for the length of a project, we’re looking far ahead into the future. The further we peer, the poorer our seeing, and the harder it is to a provide realistic estimate.

Estimating a project from the start requires long-distance lenses, so we may pad with a buffer because that protects us slightly. But, as the project progresses, problems arise, change requests come through, and the specification that we’ve been working from changes (or it doesn’t, even though the functionality does, but that’s another problem). This is how reality departs from our estimates. Towards the end of the project, we’re dealing with bugs that we couldn’t foresee and test results have come in, which frequently mean lots of change requests now that the client’s seen the proposed release version.

Two problems: estimating when our knowledge about the project is less than complete; changes arising that throw the project off schedule. Now what could solve them?

We want our estimates to be more accurate, so they can be considered commitments; and we want to be able to handle changes and problems that arise.

Imagine that, as a developer, you were asked each morning how long it would take to perform the single task you were about to tackle. Your response would be in hours, and probably more or less accurate. Imagine now, that you were given the whole list of tasks up front and asked to estimate on them – the answer would be in days, and a lot less accurate.

Firstly, say it takes 10 hours to complete a task, and you’re 10% out: it takes 11 hours. We’ve lost an hour. Say it takes 10 days, with the same margin of error, and it’s taken 11 days. Say it takes 100 days, and it’s taken 110 days. Thus the same margin of error, when affecting differing timescales, has very different ramifications. And just in case you think I’m being unfair by swapping from hours to days: if you think something will take one hour and I think it’ll take two, we have room for a discussion – the difference is clear; if you think something will take 30 hours and I think it’ll take 31, it’s a lot harder to explain the difference and decide which is a better estimate.

If we can make our estimates more often and more short-sighted, rather than a single one tackling the whole project, we stand a much better chance of getting the estimates right, we can adjust them based on recent learnings, and we can incorporate changes/problems as they arise.

That may resolve the conflict of PMs wanting commitments and developers not having concrete specs to work from (with no changes, ever ever). Whaddya think?