Instead of trying to meet all those criteria just aim for MT goals. (I got this from manager tools podcast). Measurable and Timed. Complete/improve/change x by exact date. Simple, clear, unambiguous.

OK so x can still be tricky. Complete what exactly?

What do we want from a performance review? Better performance of course!

So x should be something that improves performance measurably. And that’s where you need to be creative. There is a danger of the objective becoming task management. And another danger of task management is that often the ability to complete the task by a given time depends on many external factors that the guy with the objective has no influence over.

The best performers should not be task managed but asked to make something better, let them determine how. Without constraints those that want to won’t be constrained and will achieve more.

How often should you review performance? Quarterly? Monthly? At least!

Running has fairly simple targets. Be faster or go further. I’ve got 6 weeks left to prepare for the Warrington 1/2 marathon, so I’ve got one big objective – run from start to finish, no walking. To reach that I have some smaller intermediate goals. At the end of the first week my target was to run 3 1/2K. But by the weekend I had changed this to be reach 5K. Next weekend a new target to reach 7 1/2K. All was going well at 6K so again I pushed for a bigger target 8 1/2K. Made that too, but it was hard.

Every time a target looks like it can be reached, set a new target that’s harder to achieve. The best performance comes when the target is just out of reach and we dare to succeed. Sometimes we’re going to fail when always pushing for the best performance. Set achievable targets and you will never get the best. Always re-evaluate the target as you go along.

Now we often hit a problem. Some organisations like to link the performance review to more than getting the best performance, but also to a pay or salary review. If you can almost never achieve your objectives, and continually deliver fantastic performance, does your review say you’ve failed, so won’t get that pay rise? Well, yes if you work for a dumb organisation. If your performing that well go somewhere else.

If you want best performance and you’re tying it to pay you’ve missed the links between incentives and performance anyway. Lack of money demotivates, more doesn’t increase performance. Find out more from Dan Pink below:

If we’re truely going for single flow we work on one feature (a minimum marketable feature or MMF) at a time. We want to work on the highest priority. Whilst we’re not working on the rest of the features in the queue, the business can change their priority as often as they like, it costs very little in development terms until we’ve actually started working on the feature.

But we often have a couple of features and it’s difficult to tell which is the highest priority, especially when you come from a background where you’re allowed to have 10 Must haves, a couple of Should haves and few Could haves (Oddly enough I’ve had to work on projects where features were put into must, should, could, want; and then project success was defined as all must and should have’s delivered – so much for that relative prioritisation).

So how do you work out an absolute priority. Often we’re asked to do both. It could be that both features will be developed before a release, but that shouldn’t be necessary. If we can develop one and release it we have delivered real value. So there is an important decision to be made, which is the highest priority?

There has to be one, even a donkey with two identical carrots placed an equal distance either side of it’s head won’t stand there and starve to death. It will very quickly decide on one carrot to eat before the other. Donkeys don’t starve.

Now we’re a little more complex and with better reasoning than a donkey. And this can make it difficult to decide which out of a small set of features is the highest priority. We can just randomly pick one feature over another, that’s quite easy to do. But to be able to accurately determine which feature should be developed first we really need to start to understand the benefits and trade-offs of picking one feature over another.

This takes some thought and knowledge and understanding of things like cost of delay. The more we move from a batched/grouped priority to a queue the more this needs to be understood.

Of course we get some benefits from working and delivering a single feature, much quicker feedback from our customers which should help improve our knowledge and prioritisation of future development. But when you’re starting out, don’t starve, we’re smarter than donkey’s – something has to be more important than any other feature, and do you know why?

Some time ago the US navy took 5 monkeys and put them in a cage, in the cage was a step ladder with a load of bananas at the top. Whenever a monkey touched the ladder the cage was flooded with icy cold water. This was repeated until the monkeys no longer approached the step ladder.

At thus point of of the monkeys was taken out and replaced with another monkey that had never been subjected to the cold icy water. The cold water jets were also switched off. No more threat of being soaked.

The new monkey saw the bananas and headed straight for the ladder. The other monkeys, not wanting another soaking dragged it away and stopped it going near the ladder through whatever persuasive techniques available to them.

Once that new monkey no longer wanted to go near the ladder, a second monkey wad introduced that again had never been soaked, replacing one of the original (and now presumably angry and hungry) monkeys.

Again the new monkey was restrained by all the others, even though there was no risk of cold icy water.

And so the monkeys were slowly replaced until not a single monkey in the cage had ever been soaked, yet not one monkey would approach the ladder for fear of being mindlessly attacked by the others.

Humans would never do anything like this would they?

First off is the story of the onion – and it starts with a newly wed couple. The husband wanting to impress his wife cooks their Sunday roast. Into the pan with chicken goes half an onion. Once the roast is cooked, the onion is taken out and thrown away. Puzzled the wife asks why do that?

The reply “well I’ve always done that, I don’t know why – it’s what my mum did.”

So the ring the guys mum and ask her why there was an onion roasted next to the chicken only for it to be thrown away.

Her reply is just like her sons “i don’t know – it’s just what my mum did.”

So they ring up the husbands grandma and ask her why she put onions in with the roast dinner, only to throw it away.

At last comes an answer, “oh, when I was little we did’t have non stick pans and you really had to scrub the pan hard to get it clean after cooking in it, but if you put an onion in it helps to stop bits sticking, of course I don’t bother doing that now!”

Far too often we just do things without knowing why. Because someone else does it a particular way, because it worked that way for us once before (could have just been luck, or really sub optimal). There Is very little thought it challenge. Tradition happens because no one wants to stand out or ask why, if you wait too long before asking you may never know why at which because those that started the tradition may be dead by then. Then we call it dogma because to make sure we keep following the rules it has to sound more important than a tradition.

The second story also involves a man trying to impress his girlfriend/wife with his cooking. This time it’s a turkey he’s cooking, and before he puts it in the oven he snaps off the legs and lays them down next to the rest of the bird. His wife asks why? He doesn’t know – it’s what we’ve always done. So they ring the mother who does it because het mother did, who tells them that she did if because they only had s small oven that wouldn’t fit a turkey in with it’s legs attached.

Beware of onions or broken turkey legs. Challenge what is being done and ask why. If you ever get because we’ve always done it that way, or no one got fired for picking IBM, or because amazon do it that way, think about what your doing cos you’re probably doing something wrong, most likely wrong and stupid.

—–

Read about “Why England Lose” for more examples http://bit.ly/bYpxok

So what’s needed for TDD – red, green, refactor – with quick feedback. I’ve had a quick look at the infinitest plugin for Eclipse and it’s really good, however I’m not going to be able to justify the cost whilst we’re just starting out on TDD, perhaps the single user cost, but not the corporate cost. Fortunately the project started off as an open source project and whilst this version doesn’t give all the feedback goodies, it works pretty well.

Infinitest will run only the unit tests relevant to what you’ve been changing and in an order to give you feedback really quickly. Go get the 4.0.3 version from Google code, then unzip to some location on your system.

Although be default Eclipse is configured to build a project automatically, it doesn’t save files automatically like IntelliJ does. Currently I set Eclipse up to not build automatically, but change the preferences to save automatically before build, then use Ctrl-B to trigger a save all and build. If I’ve edited more than one file this saves at least two key presses.

The Infinitest download comes with instructions, basically add the infinitest.jar to the projects build path as an external jar:

Then create a run configuration passing the main class of org.infinitest.Infinitest, and run.

As mentioned before I also like VIM, and to aid navigation around the editor window I’ve installed the vrapper plugin and mapped toggling this on and off to the Ctrl-] key.

Now, in just a short few days she has joined the ranks of the accomplished. No longer the ugly duckling of the scooter world, but a fully fledged swan.

Bombing down steep hills, weaving in and out of other kids, pushchairs and parents. The ability to travel yards without touching the floor and skipping on and off whilst travelling at a frightening pace.

No longer do I walk along feeling embarrassed at her attempts, now I can barely watch as the beginner has moved up to daring expert.

It’s amazing how quickly new skills can be mastered when you have no fear of failure, just chase the taste of success.

It’s a team who will work on the project, and there will be lots of times when there will be pairing.

To keep things consistent throughout the team the same editor should be used.

The pragmatic programmers recommend (Tip 22) that you should use a single editor and get really good at it. That also implies we should pick one editor to use consistently across the team.

Some team members are more familiar with and prefer IntelliJ, others Eclipse (no one’s using Netbeans, so it’s only a deathmatch between two).

Does it matter which one? In some ways the choice of IDE shouldn’t matter. Kind of like driving a car. It helps being familiar with a particular car, but they are all similar enough that once you can drive one, you can drive another. At first there might be a few things in different places (windscreen wipers and indicators swapped around), but you can quickly adjust to these things. It’s the ability to drive that matters, not what you’re driving in.

I once drove round Germany in a hire car picked up in France. It was left hand drive – at first I was worried about this, but having the gear stick on the other side wasn’t a problem. There was some initial problems finding reverse, I was used to pushing the gear stick down, not lifting some latch on the stick – but once figured out – no more problems.

The road signs are all a little different, and on an empty road I’d sometimes end up on the wrong side after turning right.

Thing is, I could still drive, corner, avoid other cars and get around safely.

When programming, it’s nice if the IDE completely dissapears into the background and you can concentrate on the programming without being interupted by figuring out what key presses to make. But those key presses can be learn’t pretty quickly, and most of software development isn’t about the key presses, but the decisions made when coding. Using experience of how to do development, supported with TDD/BDD techniques makes the choice of IDE irrelevant to how well we can produce good, safe software.

At the moment I like IntelliJ, because the keyboard shortcuts are the ones I’m familiar with from Visual Studio with Resharper and Rubymine. But I’m not coding .Net or Ruby, so I’ve already got one mental switch in language to get around.

When working in multiple (human) languages I used to swap the keyboard mappings from English to French and could touch type in either no problem, French for French and English for English. So a different programming language with different keyboard shortcuts shouldn’t be a problem either given the different mental context (or does this indicate I’ve got some sort of split personality disorder?).

In the end I expect it will be Eclipse because of the cost and currently no genuine justification of the price of IntelliJ.

Without wanting to start an IDE war – how did you decide on which editor to use?

Individuals and interactions over processes and tools

What is a process?

A Process is an unnatural thing that helps us go faster with less energy.

Swimming is a process.

Even babies when thrown in to a pool don’t drown. But the way they swim is just like a dog. All arms and legs pushing around and they don’t get very far very fast. It uses lots of energy. This is our natural behaviour in water.

Learning to swim is a move from the natural following a process. Learning to swim helps you go faster using less energy. It is not something that happens naturally. It has to be learnt. It takes a while.

Armbands
To get started swimming some people use armbands. This helps them stay afloat, stops them drowning whilst they learn a new stroke. Gives them confidence to start moving faster. The armbands are tools, sometimes tools will start to slow you down – but eventually you want to discard them.

Tuning
There are different strokes in swimming. Some faster than others. There is more than one process to accomplish your goals. You need to be able to pick the right one.

If you start from breast stroke, you can only go so fast. Sometimes as individuals we need to work out that to go faster means adopting a completely new stroke.

To swim really fast using very little energy means lots of fine tuning to your process. Total Immersion Swimming will show you how to swim front crawl properly, but it’s over 200 pages long! Lots of fine tuning. But if you want to be the fastest these are all the refinements you need to learn.

Copying
Even top swimmers still change their technique to try and stay ahead. Michael Phelps winner of so many golds at the last Olympics has changed the way he swims to try and go faster. If it works, others will copy this faster way of swimming.

It’s not just in swimming that this constant search for a better process goes on – the British Olympic team from the cycling to the bob skeleton always seek out any performance advantage. This never stops. Tiger Woods in golf when at the top of the rankings rebuilt his golf stroke from scratch to be better.

On Being Agile
Agile software development emphasis individuals and interactions over processes. But we need to have a process to tweak, to improve. Agile rails against a fixed process. When the process dictates how we work and we cannot change it, then we are no longer agile.

Agile software development covers so many different processes from OpenUP to Scrum to XP to Kanban. They share some practices, they try to be as light weight as possible, but the only true agile process is one that can be changed. Don’t be dogmatic. Don’t get stuck following the process. Value your individuals interactions and how you should change the process to support them.

Individuals and interactions drive processes and tools

is the agile way.

Jim Webber gave a quick talk on HATEOS at my workplace today. Where the web stands a traditional problem upside down is in enabling scalability. The web is inherently scalable and reliable, but with a pull model, not a push. On the web it is not the service that is responsible for ensuring reliability but the client to continually pull (or poll) the server for the latest information.

In a non web application this continuous polling kills scalability, however with the infrastructure of the web providing caching and reverse proxies our service can be defended against the polling until there is an update to give to the clients.

Ebay turn referential integrity on it’s head to ensure that their systems can scale too. No longer is the integrity of data enforced in the database, data is inserted with the foreign keyed data first. The standard example of an order with several line items will have each line item inserted and then finally the order item. This removes the need for transactions and constraints slowing down the access and the processing within the database. Consistency of the data is achieved eventually through the software, with a separate clean up process removing any orphaned records.

These counter intuitive methods are the key to building the reliable, scalable applications that run on the web.

Change your perspective and build something better. Please post anything else in the comments and enjoy the contribution from TED:

So here’s a rough diagram of the application architecture. Product data of some sort is going to be defined and managed within a cappuccino based application, and persisted through a thin RESTful interface defined within sinatra through to tokyo cabinet.

In theory the models for the data will only be defined in one place within the entire application – within the cappuccino interface for managing the data. As new fields are added to the product data they will be added at this point and will propagate through the rest of the system without having to change any code. Of course to render the information back to the customer web site, the HTML rendering will need to call the name of the field.

This does place some limitations on the type of data being stored to what can be supported using the key/value approach within tokyo cabinet. One of the challenges to overcome will be how to map groupings of products within the data store.

Target Architecture