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:

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 …

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?

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?

Let’s take one of the problems in the previous article (It’s not rocket science), and see what’s driving it, which may give us a better perspective towards possible fixes.

I’m going to use a tool that I first saw (read, actually) used by Clarke Ching in Rolling Rocks Downhill, which uses a diagram to define the conflicting behaviour, and thence to uncover the assumptions behind it.

1. state the behaviour that you want to get rid of
I said that developers were so pushed for time that they didn’t test their code as they wrote it, nor before committing it to Subversion, our code control system. They were clear that they were working as hard as they could – doing the best they could – in the circumstances. Their repeated complaint was that the requirements kept changing so nothing could be finalised. That statement goes into the box marked D.

2. State the need that is being met by the undesirable behaviour, or which drives us putting up with it
On this project, at least, it was crystal clear – we had no time: we just had to meet the deadlines. Speed was driving slapdash development methods. So that’s what goes into the box marked B.

3. State the behaviour you desire, which is the opposite of D
Again, straightforward: I want developers to test their code before they commit/release it. This goes in the box labelled D’ (”d prime”).

4. The need that the desirable behaviour fulfills
Well, if we’re testing, we’re catching bugs during the development phase when it is cheaper/easier to fix them, rather than the later testing phase. That goes in box C.

5. The objective that the needs fulfill by both being present
Need B is meeting the schedule/delivering the project on time; Need C is delivering a high-quality product. Thus the objective we have to put in box A is: delivering a high-quality project on time and budget.

So, put it all together, and you get the conflicting behaviours and the reasons behind them, and a reminder that both reasons are aiming at the same target. Note also that for the objective to be reached, both needs have to be met, i.e. desirable and undesirable behaviour both have the same ultimate goal.

I’ll look at what comes assumptions are revealed from this exercise shortly.

We now know how some of the mismeasure, frustration, and sometimes despair arises as we try to manage that relatively recent invention; the serial process – the manufacturing process. We recognize, often intuitively, that we are trying to optimize according to some reductionist/local optima approach but that we are actually bound by the process dependency and variation of our system. But what does it mean to optimize? Surely this means to do our very best. In fact, for everyone to do their very best. (From Dr K. J. Youngman’s website.)

In software development, we have a virtual shopfloor – a cyber pipeline – through which all work flows. If we all “do our best”, the pipe soon gets blocked with incoming work (if the account management/new business teams are any good) and the production teams don’t have the room they need to give each project the time it deserves; the creative team never fully hands off designs to the developers, as they always have one final tweak to make (after all, as they see their ideas realised, so they gain more ideas about them).

Organising the pipeline
Given that a chain is only as strong as its weakest link – that a group of boy scouts can only walk in single-file as fast as its slowest scout – any production process can only move as quickly as its slowest part.

If the new business team is fantastic, and concentrate on doing their job to the best of their ability, but define “best” purely in terms local to them (i.e. “I’m doing my best when I bring in most new business”), they will soon swamp the next team in the pipeline. If creatives never fully hand off their work, the next team can never really get started on it.

A brief detour to look at production problems
I’ve recently witnessed a massive project screw up, based on obstacles arising that surely were avoidable. A quick list of the major problems:

• Lack of clarity over what was to be delivered from the outset
• Changing requirements throughout the project
• Deadlines imposed from above
• Frequent personnel changes
• Deceit between different parts of the team over progress
• Command/control behaviour

Wow, where did all those problems come from?

Well – first among equals – the role of the new business and account management teams in bringing new projects into the company is where the rot starts (there are plenty of other places too, but this is the most common, possibly only because it’s first in the line). Their job was to bring this new client on board, and make them so happy with us that they would line up lots of projects as quickly as possible. And they did this job extremely well.

The team did their best, within the limited perspective of their role. But if we judge their work from the point of view of the production system as a whole, we see a markedly different story. One in which their contribution to the project’s failure is clear. Their priority was to ensure that the project delivered was exactly what the client wanted, so they changed requirements and delivery dates throughout the schedule. Nothing signed off was sacrosanct, and work had to be re-done on a regular basis, without changing delivery deadlines.

Although I know this sounds like finger-pointing, it’s not, I promise. I can do this same exercise with every team that played a part in the project, and each and every time doing “their best” will end up contributing to failure.

To prove that point: the development team also did their best, by demanding water-tight specifications. When they finally got them, the deadline was so tight that they worked extremely long hours (like 16 hour days for more than 7 weeks); they coded until they could no longer speak. They were demons!

But they failed to deliver. They blamed uncontrolled change and lack of specs, and late sign-off of designs. They tried to cover up basic mistakes in the bespoke framework (like writing a bespoke framework – anyone heard of PureMVC?), and didn’t test their code as they went.

And again: the project manager tried his best, within the definition of doing his job according to those who employed him. However, nothing was delivered on time; less than a quarter of the project was actually delivered; it was buggy and immensely expensive. It had failed on time, cost, and quality counts. And yet, I’m sure he would say that he did his best.

So, what’s going on?
Consider how we work: we are social animals that collaborate for a common good. Our social network, however, is fluid in terms of strong and weak links and thus we have many strategies for dealing with changes within the network – we can help each other, we can withhold support from each other, we can circumvent weaker members, we can break links and make new ones. Thus, although there is huge dependency in a social network, it is loosely-coupled and dynamic – everyone cooperates, with a few subordinating themselves to others at any one time*.

* by “subordinate”, I mean work to the betterment of others rather than oneself, put others’ needs and desires above one’s own.

Another form of experience also exists, though – our personal experience as individuals: here, we don’t need to subordinate or coordinate; we are free to improve and work to the best of our ability independently of those around us**.

** putting our own needs/desires first, I’ll be calling “maximising” later, and in regard to process, I mean promoting that particular piece of the process.

Now, the industrial mode: well, you might think that it’s a network, especially as workplaces have personal networks, but actually it’s far more linear: there are few if any alternative routes through the process (get new business -> specify the work to be done -> design -> architect -> implement -> test -> deploy -> review, for my industry). There is far greater dependency between the parts of the process – we can’t just ignore or cut out design because the designer’s on holiday. Finally, there is always one part of the process that is weaker or slower than the others. Improving the workflow of the other parts won’t speed up the total throughput because of that bottleneck.

In an industrialised line the only place that maximising adds value is in the bottleneck, and everything else has to subordinate to that bottleneck, which experience is almost the exact opposite of the social and individual experience, where the bottleneck can be avoided. Does that spell doom for our chances of success? Thankfully not, but we do need to change the way we work.

There is much within an organisation that contributes to a silo effect: there’s me, my team, my division, managers, department managers, division managers – all of which put an individual or group focus on working practices. But this can mask the strong serial dependency of the process pipeline. We need to view the system as a system, not as a set of silo’d groups. However, many of our measurements revolve around localised views of parts of the system, including our individual definitions of “doing our best” .

If each team involved in a project does its best, the project still runs the risk of failing (sometimes monumentally), so what should we do? Find out what is the best thing to do, and then do that to the best of our ability.

More anon.

I’ve worked for several companies where the money comes in only when production is complete. All speculative brain-storming and project-definition is paid for by the cost of the implementation stage.

Problem #1: brain-storming/project specification isn’t an expense; it’s vital, hard work, required to think up the best product we can. As such, it requires time and skill. If it’s not paid for in its own right, then it is always under pressure to cut costs – by lessening the time spent on it, and/or by putting cheaper resources on the job (when this is precisely the point at which more experienced people are most effective).

Problem #2: if we’ve thought and spec’d up the most wonderful product in the history of the web, but the client changes their minds, all that work hits our profitability. If we only charge for implementation, the time spent thinking up fabulous ideas is money lost unless the project goes all the way through production.

Problem #3: development frequently takes longer than estimated – whether it overruns the schedule or stays within the buffers put into the estimate. If all the up-front creativity is to be paid for by the profit from development, then guess what – we’re making less than we planned to.

Problem #4: because it’s not paid for, the cost of it is frequently covered by the account, which means that the account managers do the work, rather than pulling IAs, art directors, senior developers off paid-for implementation work (after all, they’re expensive). The result is those with least experience define the project.

The most important part of the project is in the definition of the work to be done. That, then, is where we should spend a sizeable part of our time, discovering/brain-storming, defining/specifying, and planning. Given that we are creative agencies, then we should charge for our creativity. It’s bleeding obvious when you read it, isn’t it?

The solution: charge for our creativity. Agree with the client that they will pay a certain amount for us to think up and define a project. Getting paid for the work means we no longer need to skimp or cut corners on it (problem #1). Getting paid means we’ve not lost anything if the client decides not to go ahead with the implementation (#2), or if they choose to take the work elsewhere. Getting paid means that we don’t need to fund that part of the work from somewhere else(#3). Getting paid means that the right people can be on the job(#4).

Bleedin’ obvious, innit?

They reckon that “urgency is acidic” – it burns out morale, especially when working towards an emergency deadline lasts more than a day or two (like, say 7 weeks plus – you know who you are!).

If your deliveries are that critical to the hour or day, maybe you’re setting up false priorities and dangerous expectations.

I re-read it several times, and each time it sunk in deeper just how important this concept is: this alone proves the worth of an agile approach to project development. Requirements go stale.

Most obviously, they run the risk of becoming obselete as the team and client’s understanding of the project evolves; but, equally importantly, they suffer atrophy simply through lack of use.

Once captured and defined, a requirement has a half-life – the longer it gets left in the requirements document without being actively worked on, the poorer the knowledge of that requirement. Clearly, if the developer leaves, the team suffers massive impact in its understanding of the requirement. But, even if the developer stays, their understanding and knowledge of the requirement withers as they work on other things.

The reality is that a requirement can rarely be so fully captured that it doesn’t depend on an individual’s understanding and definition of it.

The solution to this problem?

Define a sub-set of requirements that can be worked on within a specific timeframe. Move from requirements capture and definition to solution implementation within the same timeframe. Work agilely.

* Eli Schragenheim & David J. Anderson, Prentice Hall, 2003 (ISBN: 0-13-142460-2)