I’d like to share a few techniques with you which have helped me to change the behaviour of code I’ve worked with, with little conflict, great success and positivity all round.

Imagine a legacy system who’s been in the job for five years and can’t see the problem with the way he’s behaving.

Imagine a class, who feels like he needs to be in control of everything, and can’t delegate or trust other classes effectively.

Imagine a service who’s overloaded, doing the job of three systems that no longer perform, but who just heroically accepts all the work and never gives any signal that he’s about to collapse, again.

We’ve successfully used these techniques to help change our codebases, our systems, our services and our applications, as well as our people. I’d like to share these simple guidelines with you, based on the sandwich model of feedback. They are:

• Start with the right mindset
• Anchor the things you value
• Avoid labelling
• Use examples
• Work towards a bright future

Start with the right mindset

There are lots of reasons we might want to change our code. I’ve seen people work on code

• because it doesn’t work the way they expect
• because it’s annoying
• because it refuses to do something which isn’t really its responsibility anyway
• because it’s fun and powerful to change code for the sake of it.

I believe there are only two good reasons to change code:

• to reinforce valuable behaviour
• to increase effectiveness.

If you’re not approaching the code with one of these mindsets, stop. How much do you actually respect the code you’re about to change? All code wants to do a job effectively. No code is perfect. Remember that time when you first wrote code? You were learning, too. If you can approach the code with an appreciation for the things it does right, and build on those, you’re more likely to meet with success.

As an example, I had one piece of code which controlled the registration of pets. I really wanted this controller to broadcast a pet’s registration, but instead of communicating asynchronously, the controller was insisting that anyone who requested the registration of a pet hung around, waiting.

Unfortunately, one of the people who requested pets was the GUI – an extremely important class with a lot of other jobs to do too!

The code was frustrating me so much that I almost got rid of him and replaced him with someone else… but then I thought about it, and remembered that apart from the fractious relationship with the GUI, the controller had been doing his job very well. This respect allowed me to change the code’s behaviour instead of replacing him.

Anchor the things you value

Once you have an appreciation of the value of the code, make sure that the code knows. Reinforce this. You can call out specific examples of times when the code has done something well.

I told my controller, “I appreciate the way in which you register pets, and the effective way you delegate to the repository. Here’s an example. I registered a new rabbit, Snowy. I gave you his date of birth, his breeder and the price I wanted to sell him for, and when I verified it with the repository later, I found that you’d passed the information on very well. This is important to me.”

I tend to use a unit testing framework and perhaps a mocking framework – Moq or mockito – to translate these conversations into the language of the code.

If it’s a whole team whose behaviour needs to change – perhaps an entire application – then I’ll get everyone together and talk about the things that the entire team does well. For this, I use scenarios, either with a DSL or perhaps a BDD tool like Cucumber or JBehave. Automation tools like Selenium or WiPFlash let me translate my feedback into something they understand.

By anchoring the things that I value about the code, I can change his behaviour without fear that he’ll change in ways I didn’t want.

Avoid labelling

There are two types of labelling that I avoid: negative labelling, and pattern labelling.

Once I was judging a competition in which a coder announced, “This code is shite!” I marked him down. “If any other coder hears you say that,” I said, “they’ll either be wary of trying things out or they’ll think it’s OK to start devaluing other people’s code.” Labelling code negatively this way can be damaging for everyone involved in the project, even if you wrote the code.

Labelling code by calling out the patterns of behaviour can also be unhelpful. I remember one piece of code that got labelled as a “Visitor”. From then on, everyone expected it to behave like a Visitor. No matter what its responsibilities were, coders expected it to behave like a Visitor and encouraged the other classes in the system to do the same. Eventually the code broke down so badly that we had to replace it altogether, just because we had labelled it badly.

Use examples

We already looked at how to use examples to anchor positive behaviour instead. We can also use examples to show the difference between the behaviour we want, and the behaviour we’ve actually got.

“Instead of watching the repository,” I told the controller, “I’d like you to listen to him instead, and trust him more. Sometimes the repository might give you a message. I’d like you to respond to that message.”

“How long do you want me to wait after saving to get the message?” the controller asked.

“Don’t wait,” I told him. “Instead of telling me it’s done, I’d like you to tell me that it’s in progress instead. Let’s say that the repository takes five seconds. You should be responding in less than one.” We used some threading to illustrate how the repository might go off and do its job, and talked through the example in the controller’s language until I knew he understood.

Work towards a bright future

By focusing on the positive goals we want to achieve, we don’t really have to spend much time on the negative aspects of the code’s behaviour. After the examples were written, the controller was able to verify that his behaviour had changed appropriately, with as little fuss as possible. What’s more, he had those tests available to him going forward, so his behaviour stayed fixed. Eventually he became one of the most important classes in the system, responsible for the interactions of ten other imports – but he never got overwhelmed by the job.

We can do the same thing with scenarios and applications, or performance tests and whole systems. The ability to define the behaviour we want is one of the most important aspects of changing the behaviour which exists.

Here they are, in alphabetical order, because none is any better than any other:

Budget-driven Estimation

Whatever estimate you come up with will be enlarged by the customer so that he can spend the rest of this year’s budget, otherwise he won’t get it again next year.

Catch-up Estimation

Scrum Master: We have 30 points of work still to do, and only 2 more sprints to do it in. How many points can we manage in a sprint?
Team: 15!
Scrum Master: But we only managed 5 last week! How many do you really think we can manage?
Team: 15!
Scrum Master: (facepalm)

Comedy-driven Estimation

As told to me by Dan from a talk he saw – if you know who it was please let me know so I can credit:

Presenter: How tall am I?
Crowd:5′8″! 5′9″! 2 metres!
Presenter: Go on, you can manage more than that. How tall am I?
Crowd: 6′2″?
Presenter: Come on! You can do better than that! HOW TALL AM I?
Crowd: (Giggles nervously.)
Presenter: Just because a project manager tells you you can do more, it doesn’t make it true.

Done-driven Estimation

A symptom of a pressured team, this method of estimating allows a pair of developers to get the story out of their stream as quickly as possible by eliminating time spent on tedious things like refactoring to make the code maintainable, deployment, manual testing, etc. Symptoms include the oft-quoted “Works on my machine.”

Done-done-driven Estimation

A good team knows, of course, that the code counts for nothing until it’s out there in production, doing the thing it was built to do. Estimates are given with this in mind, but without the help of anyone involved in production deployment, systems integration, performance testing, UAT, etc., because they’re in different teams.

Fractal Estimation

After the scope of the project has been constructed, some stories may be considered too large to fit into an iteration, so the team decide to split them into the smallest possible deliverable slices, re-estimating each slice. Of course, this is a bit like measuring the coast of Britain. The epic which was 13 points at project inception becomes 16 points of features, and 23 points of stories by the time it’s done in the sprints. Analysts wonder where this extra scope came from, while advocates of burn-down charts tuck the growing scope away somewhere where it won’t be noticed.

Wikimedia Commons, CC Attributions ShareAlike 3.0

Goat Estimation

Asking a goat can help when you know it doesn’t really matter what you say, you’ll probably end up doing target-driven estimation anyway.

Job-driven Estimation

As practiced by residential consultancies on Time and Expenses, contract Project Managers and anyone else with an interest in seeing the project go on as long as possible.

M25 driven Estimation

“Yes, I know it took me 3 hours to get around London yesterday, but that was because there was a traffic jam on the M25. Today will be much quicker.”

Pareto Estimation

Often used by teams which have work still left over at the end of an iteration and desperately want to include the incomplete work in their velocity. Unfortunately the Pareto principle, applied to tasks, suggests that 20% of any task will take 80% of the time. Let’s hope the 20%’s not the bit that got left till last.

Post-mortem Estimation

The team chooses estimates that will allow them to avoid the post-mortem inflicted by the project manager when they missed the deadlines last time.

Promise-driven Estimation

Developer: “These estimates… they’re just estimates, right?”
PM: “Don’t let the business hear you say that!”

Like Scrum’s sprint commitments, but used for release or project planning, this estimation method often leads to three-week long project planning meetings before the project starts. Frequently occurs as a result of fixed-price contracts with first-time suppliers. Also the second time. And the third.

Star-Trek Estimation

Geordi La Forge: I told the captain I’d have this analysis done in an hour.
Scotty: How long would it really take?
Geordi La Forge: An hour!
Scotty: Oh. You didn’t tell him how long it would REALLY take, did you?
Geordi La Forge: Of course I did.
Scotty: Oh, laddie. You’ve got a lot to learn if you want people to think of you as a miracle worker.

Student Estimation

If an estimate is chosen wisely, 50% of measurements will fall under the estimate, and 50% will fall over the estimates. Strangely, nothing ever gets handed in early, no matter how inflated the estimate is.

Target Estimation

PM: How many story points can you manage this week?
Team: 10.
PM: That’s not good enough. I need you to do 12. How many can you manage this week?
Team: 12.

Velocity-driven Estimation

Once a target velocity has been established – sometimes by the team itself – the team members will find a reason as to why the work they’re capable of doing does actually add up to 12 story points. Often applied in conjunction with Fractal Estimation.

Zero-outlier Estimation

If being wrong is uncomfortable, a team will wait for the most experienced developer to “throw” their estimate first before following suit. Planning poker fixes the symptoms, but not the problem.

If you can scan your threads when all around you
Are searching for the last response they knew
If you can kill the spammers with a button
While others must select a different view
If you can wait and not be tired of waiting
For others to get round to their replies
If email’s not the greatest thing you’re hating
And others’ weary rants are a surprise

If you don’t need to dream of working faster
And swift communication is your game
If you believe that emailing your master
And mastering your email are the same
If you can find the words that you have spoken
Within the folders chosen by your rules
If you can fix the email list that’s broken
Without the need to curse your dodgy tools

If you can start again from the beginning
And find out that your draft is not yet lost
If you must fight your inbox and you’re winning
Without your leisure time bearing the cost
If you find others accidentally bin you
Or cc you in mails they forward on
If you can laugh and even find it in you
To help discover where they might have gone

If typos with control keys never hurt you
And buttons don’t exist you fear to touch
If sanity and reason don’t desert you
When all the mailing lists become too much
If you find you can spend a single minute
And get some useful work done while you’re free
Yours is the Net and everything that’s in it -
And I guess you use a different client to me!