hunger is the best source

I've previously blogged about being taught ITA spelling at primary school. About how it causes me spelling problems. I was reminded of this when speaking to Geir Amdal at the excellent Agile Coach Camp in Oslo. Geir showed me this wonderful blog post with lovely twist on the famous quote:

Knowledge is power.
Francis Bacon

It reminded me of something my Mum used to say to me when I was little:

Hunger is the best source.

For many many years I didn't understand what she was saying. I was seeing the word sauce as source. She was actually saying:

Hunger is the best sauce.

Food tastes better when you're hungry. Reflecting on my confusion I realize I'm actually quite proud of this mistake. This was a long time ago remember. I was a small boy at the time. Even then, it seems, software was calling me.

Smoking cigarettes, eating sweets, dropping litter, and drinking coffee

I was speaking to Olaf Lewitz at the awesome Oslo coach camp last week. We were discussing why drinking coffee doesn't create the same social dynamic as smoking cigarettes. I chatted with Geir Amdal too and quite by chance he mentioned he's given up smoking. And how approaching a work colleague and asking if they want to go outside for a smoke is not the same as asking if they want to go outside for a talk.

Then I remembered something Olve Maudal said to me recently. He said that kids being allowed to eat sweets on Sundays was not really about kids being allowed to eat sweets on Sundays at all. It was really about kids not being allowed to eat sweets on any day except Sunday. Similarly, apparently in the USA when you're driving along you sometimes see a big sign at the side of the road saying "Litter here" and then another sign a mile or so later saying "Stop littering". These signs are also not really about littering. They're about not littering in the places outside the designated littering zones.

There's a crucial difference between smoking and drinking coffee. Smokers tend to smoke in groups in designated areas because smoking is not allowed except in those areas. Coffee is different. Drinking coffee is, by default, allowed everywhere. When you want a coffee you walk to the coffee machine and make a cup of coffee. There's often no one else at the coffee machine so you take your cup of coffee back to your work desk. It is precisely this take-it-back-to-your-desk default which is why there is only rarely someone else at the coffee machine. It is a self-fulfilling dynamic.

If you want to encourage more social interaction between your team members here's what you might do:

• Buy machines that make really good coffee.
• Put them in a nice area with lots of space to congregate in.
• Ban drinking coffee at work-desks.

The third step might seem a bit draconian. But it's vital. You could justify it on the grounds that spilling coffee onto expensive computers will waste money. But the real reason it to encourage developers to drink their coffee near the coffee machine. Together. To encourage communication.

my kindle book-case

Here's a photo of the kindle I bought myself for Xmas.



When I bought my kindle I forgot to get a case to protect it. I searched around on a few sites looking for a case but didn't find anything I particularly liked. Before I knew it, it was time to head off to the awesome Agile Coach Camp Norway 2012. I wanted to take my kindle but needed a case to protect it. It was too late too order a case via the internet. But I had an idea. I could use a book! A regular old-fashioned hardback book.



I simply cut out a kindle-sized panel from the middle of about 100 pages and then glued the holed pages all together:



Viola, I have a case for my kindle. A book-case you might say.



I showed off my new book-case at the coach camp. It was a hit. At dinner one evening Marc Johnson mentioned he too has a kindle and loves it but misses the social aspect of a real book. The simple fact that most real books display the book's title on its front cover. People can see what you're reading. I sat next to a really interesting man on a plane once. He noticed I was reading Jerry Weinberg's Quality Software Management, vol 2, First-Order Measurement and asked me about it. We chatted away the whole flight.

My kindle book-case allows me to regain this missing social aspect. I can simply print the cover the publishers use for the real book and stick it to the front. So now I have something close to my ideal kindle case. It just needs a clear front cover sleeve so I can easily slide a cover in. And some kind of clasp. As a final bonus, I can pay homage to one of my favourite films:

Managing the design factory

is an excellent book by Don Reinersten (isbn o-684-83991-1). This is the second snippet entry for this book (here's the first). It continues my current theme of preferring to re-read a good book many times. As usual I'm going to quote from a few pages:

Whenever we see an intense need for communications it is typically a sign that the system has been incorrectly partitioned.

A complex system can often be built faster when there are stable steps along the way. This is what Nobel laureate Herbert Simon called "stable intermediate forms" in his book The Sciences of Artificial.

We cannot predict the behaviour of a system simply by understanding the behaviour of its components.

There are more possible interactions in a system of 150 components than there are atoms in the universe.

The act of partioning the system is extremely important, because it creates interfaces… these interfaces are both the primary source of value within a system and the primary source of complexity.

The nonlinear behaviour of queueing systems will amplify variability within the system.

We get into an interesting death spiral when we overload our development process. Overloads cause queues; queues, being nonlinear, raise the variability of our process, and variability raises the size of queues.

The weak cross-functional communication of the functional form sacrifices our other economic objectives.

In life, we design most processes for repetitive activities because a process is a way of preserving learning that occurs when doing an activity. … We need to find some way to preserve what we have learned without discouraging people from doing new things.

We get large queues whenever we have large batch transfers in the process.

There is a strong interaction between the design of our organisation structure, our architecture, and our development process.

6000 degree-minutes

If you use the same recipe you get the same bread.

That's the White Bread Warning from Jerry Weinberg's truly excellent The Secrets of Consulting.

I was thinking about that the other day and I realized something important. I realized that when I read the word recipe I thought about the ingredients but not really about the non-ingredient related instructions in the recipe. About time. A recipe doesn't just tell you what to mix with what, and in what order, it tells you how long to apply heat. And how much heat. These two things matter just as much as the ingredients. If you change the ingredients you'll get different bread. But if you change the time or the amount of heat you'll also get different bread. Although it might not look much like bread.

Suppose the recipe says to heat the oven to 200 degrees and then cook for 30 minutes. That's 6000 degree-minutes. Now 1200 degrees for 5 minutes is also 6000 degree-minutes. But the bread will be predictably black. Similarly 1 degree for 6000 minutes is also 6000 degree-minutes. But the bread will still be ingredients. Or rather it won't. You see 6000 minutes is 100 hours. Which is 4 days as near as makes no difference. That matters because ingredients are organic. They have a shelf life. A sell-by/eat-by expiry date. They decay. And even if baking the ingredients for 4 days at 1 degree did produce something vaguely bread-like the extra time would create extra cost. In lots of ways. Extra time does that.

Quality Software ManagementVol 3. Congruent Action

is the title of an excellent book by Jerry Weinberg (isbn 0-932633-28-5). This is the second snippet review for this book (here's the first). As usual I'm going to quote from a few pages:

Management is the number one random process element.

If you cannot manage yourself you have no business managing others.

Congruent behaviours are not stereotyped behaviours - quite the contrary. Congruent behaviours are original, specific behaviours that fit the context, other, and self, as required by the Law of Requisite Variety.

Congruence is contagious.

It takes a long time and a lot of hard practice to raise your congruence batting average.

A basic law of perception is that we tend to minimise small differences (tendency toward assimilation) and to exaggerate appreciable differences (tendency toward contrast). Thus, our perceptions make the world more sharply differentiated than it is, and we're a lot more alike than we are different.

The simplest idea about curing addiction is to stop the use of X, under the belief that X causes addiction. X does not cause the addiction, the addiction dynamic causes the addiction.

To change the addiction you'll have to use something more powerful than logic.

One of the manager's primary jobs is to set the context in which interactions takes place and work is accomplished.

Management sets the context almost exclusively through the use of language.

Culture makes language, then language makes culture.

In all Steering (Pattern 3) organisations, the team is the fundamental unit of production.

I've learned that there's simply no sense trying to solve software engineering problems, or create software engineering organisations, when I'm not able to be congruent. So I work on that first, and that's what I hope you do, too.

Fit for any type of sea voyage

My beautiful wife Natalie met me here in Norway on Saturday. We visited the Viking Ship Museum. One of the displays said:

Et skip som må øses 3 ganger på 2 døgn er sjødyktig til all slags ferd.

which translates as:

A ship that has to be bailed 3 times in 2 days is fit for any type of sea voyage.

I just love that.

Butter sighted at Olve's house

This is a photo of a pack of butter belonging to my good friend Olve Maudal. Olve has exactly 157 packs of butter in his house right now. All safely housed in his new super-sized fridge. Many of his 157 packs have been flown in specially by relatives visiting from abroad. Olve would only allow one pack out of the fridge for the photo. Even then he insisted it be taken out under the watchful eyes of the two security guards he's specially hired to guard the fridge - Lars by day and the other Lars by night. Well, you can't be too careful right now. Butter is selling for crazy money on the black (or should that be yellow) market.

Yes, it's just one small example of the butter shortage here in Norway at the moment. Apparently the cause is a new fat-rich fad-diet sweeping the population combined with the seasonal tradition of making butter-rich Xmas cookies.

Shortages like this are, as Stephen Fry might put it, quite interesting. At one point there was probably a very mild shortage. Word of the mild shortage started to spread (sorry) and anyone buying butter bought a few extra packets just to be safe. The shortage got a bit worse. Word of the worsening shortage spread further and faster. People bought even more. A self-fulfilling dynamic was thus set in place. Soon the shelves were stripped of all butter.

The shortage the customers are experiencing is, no doubt, fractally mirrored by the shops selling (or rather not selling) butter. Butter wholesalers just don't have enough butter to meet the orders from shops. Shops that get any butter get less than they ordered. Any butter the shops do get is bought in a flash (but only by relatively few people because of the bulk butter buying behaviour) and they're out of stock again. You can imagine the shop keepers pulling their hair out in exasperation. If only they could get more butter they could make a small fortune. But right when there's the most demand they have none on their shelves! They increase the size of their wholesale reorder hoping to cash in.

What will happen in a few weeks time? One possible (perhaps even likely) outcome, is that the wholesalers will finally get enough butter to meet their over-inflated orders. The shop keepers pile the butter onto their shelves and wait for the Krona to roll in... Some of the butter is sold. But not very much. After all, Xmas is now over. The fat-rich fad-diet has gone the way of all fads and the glossy magazines are now preaching a low-fat diet. And lets not forget that a fair percentage of the population has, like Olve, over 100 packets of butter in their new fridges. They're certainly not going to be buying butter any time soon.

The shop keepers then face the daunting prospect of vast butter-walls sitting unsold on their shelves, fast approaching its sell-by date. Lowering the price doesn't help. It all has to be thrown away. Again the same thing will be fractally mirrored at the smaller scale. Lots of people, such as Olve, will have more butter than they can possibly use in time. They too will have to throw out loads of butter as it goes past its use-by date.

The same lurching from one extreme to another can happen when the number of people trying to make phone calls starts to approach network capacity. People can't get through. So they try again. And when they do get through the line gets dropped. So when they do get through they stay on a bit longer. It happens on roads too.

It's dangerous to run systems at full capacity. They reach a tipping point and topple into a death spiral. Busy work and inventory pile up. That causes even more busy work and even more inventory. But almost no butter is being bought or sold. There is no flow.

Everyday heroes of the quality movement

is an excellent book by Perry Gluckman and Diana Reynolds Roome, subtitled From Taylor to Deming : The Journey to Higher Productivity (isbn 0945320078). As usual I'm going to quote from a few pages:

Look for the flaws in the system not in each other.

When we reduce complexity, we start to see the organism behaving as a whole rather than a series of parts.

The effects of preventative medicine are hard to measure.

Theories are only the beginning. Why do we find it so hard to exercise, or give up smoking, even when we know all the arguments.

Quality and productivity are results, not goals.

Automating complexity is never as effective as removing it.

I'm not trying to be destructive. I just want to open the doors to some breezes that feel a little chilling to start with.

If there are problems in the company, we don't borrow money. We solve the problems.

If you automate without first getting rid of complexity, you cast the complexity in concrete.

We do almost nothing to control our workers productivity. They are already doing their best without being goaded. What we all try to control is the process itself.

You need to know your financial direction as far as it can be known, and make sure that you don't hit any big rocks. But something else is more important: to design the ship so that it can withstand the blows when they come.

C sequence points

Olve Maudal and I created a Deep C/C++ slide-deck recently. It's been downloaded over 500,000 times indicating no small appetite for learning some of the deep secrets of C and C++. So...




In this C fragment z is initialized to the value of n after n += 42 takes place.

if (n += 42)
{
    int z = n;
    ...
}

But how do you know this? For sure? The answer is perhaps not as obvious as you might think. The C standard says:

5.1.2.3 Program execution
(paragraph 2)
Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place.

In C parlance, n is an object, and n += 42 modifies n. So n += 42 is a side effect. The only thing governing the sequencing of side-effects are sequence points. And there are a lot less sequence points in C and C++ code that you might imagine. There is a sequence point between n += 42 and the initialization of z. But where? And why? The standard says:

6.8 Statements and blocks
(paragraph 4)
A full expression is an expression that is not part of another expression or of a declarator. ... The end of a full expression is a sequence point.

and:

6.8.4 Selection statements
Syntax
  selection-statement:
     if ( expression ) statement

If we lexically enlarge the expression n += 42 to its left or right we hit the parentheses that form part of the if statement. In other words, the expression stops being an expression and starts to become a statement. That means n += 42 in the fragment is a full expression. That's why there's a sequence point at the end of n += 42. In pseudo code it looks like this:

n += 42;
sequence-point
if n != 0 goto __false__;
int z = n;
...
__false__: 

Photo: http://www.noaanews.noaa.gov/stories2005/images/rov-hercules-titanic.jpg

The Toyota Way

is an excellent book by Jeffrey Liker (isbn 978-0-07-139231-0). As usual I'm going to quote from a few pages:

One day a Ford Taurus mysteriously disappeared. It had been in the factory so they could try fitting it with some prototype mirrors. When it vanished, they even filed a police report. Then it turned up months later. Guess where it was. In the back of the plant, surrounded by inventory.

Extra inventory hides problems... Ohno considered the fundamental waste to be overproduction, since it causes most of the other wastes… big buffers (inventory between processes) lead to other suboptimal behaviour, like reducing your motivation to continuously improve your operation.

…was that data was one step removed from the process, merely "indicators" of what was going on.

Building a culture takes years of applying a consistent approach with consistent principles.

It seems the typical U.S. company regularly alternates between the extremes of stunningly successful and borderline bankrupt.

Flow where you can, pull where you must.

When I interviewed [Fujio] Cho for this book, I asked him about differences in cultures between what he experienced starting up the Georgetown, Kentucky plant and managing Toyota plants in Japan. He did not hesitate to note that his number-one problem was getting group leaders and team members to stop the assembly line.

Every repair situation is unique.

The more inventory a company has,… the less likely they will have what they need [Taiichi Ohno]

I posit here that Toyota has evolved the most effective form of industrial organisation ever devised. At the heart of that organisation is a focus on its own survival. [John Shook]

You cannot measure an engineer's value-added productivity by looking at what he or she is doing. You have to follow the progress of an actual product the engineer is working on as it is being transformed into a final product (or service).

Everyone should tackle some great project at least once in their life. [Sakichi Toyoda]

Sense and respond

is an excellent book by Susan Barlow, Stephen Parry, and Mike Faulkner (isbn 1-4039-4573-X). As usual I'm going to quote from a few pages:

Continuous improvement… is not enough… what is needed also is continuous value creation.

…they continue to create products 'just in case' rather than 'just in time'.

The intelligent business therefore embraces voluntary evolution, designing its own fitness to survive and thrive.

...measure the value creation to value restoration ratio.

Most fast-food burger chains follow, to a large extent, the batch-and-queue principle… Contrast this kind of flow with the one-piece flow achieved by another fast-food company that makes sandwiches and 'subs'… What has been standardised therefore, is not the product but the production method...

Very often the traditional organisation passes work from one department to another in a batch-and-queue system, and with this approach it is not atypical to discover that a task that could be done in ten minutes may actually take ten days to complete. The reason for this is simple: the process is designed that way.

Working together in a cross-functional way actually joins up the company, as well as reinforcing and strengthening the value chain.

Two options exist for businesses: to make offers to customers or to respond to customers' needs.

Is the customer purchasing an electric drill or holes in the wall?

Adaptiveness… cannot just be added on to an organisation's existing capabilities: the organisation itself must become adaptive.

Working together in a cross-functional way actually joins up the company, as well as reinforcing and strengthening the value chain. The result is a critical mass of value creation around flow instead of around functions.

Agilis Deliberate Practice

Here's the slide-deck I presented at the Agilis conference in Iceland. It contains numerous examples of the kind of improvements a group of developers typically work through in just a few facilitated CyberDojo iterations.

Intention revealing #include ?

In a previous post I described how C and C++ have a third #include mechanism. It occurs to me that this idea has possibilities beyond simply using LOCAL(header) as a synonym for "header" and SYSTEM(header) as a synonym for <header> and then using the resulting seam to gain some leverage for testing. You could also add intention revealing names. For example, something like this:

#include "dice_thrower.hpp"
#include <vector>

class stub_dice_thrower : public dice_thrower
{
...
private:
    std::vector<int> stubbed;
};

could be written like this:

#include REALIZES(dice_thrower.hpp)
#include COMPOSES(vector)

class stub_dice_thrower : public dice_thrower
{
...
private:
    std::vector<int> stubbed;
};

Caveat emptor: I don't have any actual examples of this in real code. It's just an idea. It feels a bit like a solution looking for a problem. But I thought I would mention the idea here to see if anyone thinks it has any legs...

Responsibility

I had the pleasure of attending the Agilis conference in Iceland recently.

Christopher Avery gave an excellent keynote and spoke about the difference between accountability and responsibility; you are accountable to someone else but responsibility is personal.

He presented his six step ladder of responsibility:

• Responsibility
• Obligation
• Shame
• Justify
• Lay Blame
• Denial

For example, I'm typing this in TextEdit on my Macbook whilst on a train to XP Day. The font is small and my eyesight is fading. For a moment I struggled to discern the tif in the word Justify. I could almost hear a tiny voice inside my head starting to blame. But then I jumped to Responsibility because I realised the fault was not with TextEdit but with me. I simply enlarged the font size.

Christopher handed out a sheet expanding a little on the six step ladder above.

• Responsibility is owning your ability and power to create, choose, and attract. It's about your ability to make a response - to respond.
• Obligation is doing what you have to do instead of what you want to. As always, if you listen carefully, you can hear this distinction in patterns of speech "… but I have to …".
• Justify where we attempt to rationalise the blame, to use excuses for things being the way they are; we make things just in our mind.
• Shame is laying blame on oneself (often felt as guilt).
• Lay Blame (which is not a French verb ;-) is holding others at fault for causing something.

My son Patrick has Asperger's Syndrome and he has a strong tendency to blame. For example, if he bumps his elbow on the door he gets angry and blames the door. He finds it very difficult to move past this blame, to get inside a positive feedback loop which helps him become less clumsy. So I think laying blame is more than holding other people at fault, it can take the form of blaming anything - anything except oneself.

There is no best practice

I had the pleasure of speaking at the Agilis conference in Iceland recently. While preparing my slides on Deliberate Practice I was naturally thinking about the word practice. As far as I can tell, "Best practice" is the most common phrase with the word practice in it. I searched for "Best practice" on goggle and got over 270 million hits. I searched for "Better practices" on google and got a paltry 20 million hits.

Best practice…

• focuses on achieving someone else's perfect future state
• assumes there is only one best practice
• implies improvement beyond the best practice is impossible
• emphasises the noun practice
• fits with the waterfall-defined-fixed mindset
• doesn't start from where you are now

Better practises…

• focuses on improving your own imperfect present state
• assumes there are many possible better practices
• implies improvement beyond the best practice is always possible
• emphasises the verb - to practice
• fits with the agile-empirical-growth mindset
• starts from where you are now

Float fishing rivers

is an excellent (out of print) book by Ken Giles and Dave Harrell (isbn 0-947674-23-3). As usual I'm going to quote from a few pages:

I always tend to feed the line off the [closed face] spool by hand.

It is also important, regardless of which brand of line you use, to use them in conjunction with a silicon spray. … it does make a big difference. I always spray it on my spool at the start and even if the wind gets up later on, I find I can still sink the line when I have to and then leave it on the surface again if the wind drops.

If you are fishing a very slow moving river such as the Nene or the Welland, where there is a strong wind, then you need the float to be loaded, because when you cast, it goes into the water like an arrow, completely burying itself and helps you to sink your line without it being pulled away from the far shelf.

Holding back is generally only used after the first frost of winter.

The most important point that must be covered on stick float fishing is the need to keep the line behind the float at all times. This is a must. It just does not work if the line is allowed to go in front of the float.

As a line gets older, it has a greater tendency to sink, so by always having fresh line on your reels this problem is easily overcome.

When I hold back, I do not hold back really hard.

Regardless of the method, be it stick float or wagglier, you must keep changing your depth around between being a couple of feet over depth to a couple of feet below the surface. Also, it is important to keep altering your shooting to find and keep in touch with the fish.

You do not select the float you want, you select the amount of weight you want to reach where you intend to fish and then pick a float to suit that.

I also feel that it pays to feed two lines like this anyway, to allow you to rest one against the other.

When waggler fishing I am ringing the changes far more often than I need to with the stick float.

The worst thing you can do… is to feed out of habit, as opposed to in response to the fish.

I think that work rate is the key to it all.

10,000 warnings

Suppose you are working on a codebase that has 10,000 warnings. Perhaps you have discussed how you can get rid of the warnings. Perhaps you have discussed it more than once. But you still have 10,000 warnings. What can you do? There is no magic bullet. You are not going to be able to buy a magic tool, or wave a magic wand, and with almost no effort, get rid of them all. If there was you would already have waved the wand.

Even if there was such a silver bullet it would create a shallow improvement, rather than a deep one. It would create no dynamic whatsoever to encourage the developers to learn how not to introduce warnings in the first place. It would do the opposite.

Naturally new warnings keep appearing. Tomorrow there will be 10,001 warnings. But the 1 new warning gets lost in the sea of 10,000 others. It's not even noticed. The number of warnings is trending relentlessly upwards.

The only way you can get rid of 10,000 warnings is the same way you got them in the first place. A little bit at a time. With effort. Effort that shows you care.

The first thing to do is put a finger in the hole. Cap the number of warnings. Make new warnings count as errors from now on. Don't just say "new warnings count as errors from now on". You said that last time and it didn't work. Alter the way you build your software so that new warnings cause a build failure. If module X has 3,663 warnings then 3,663 is the stake in the ground. If it gets more than 3,663 make that a build failure.

This creates pressure to remove warnings on the code actually being worked on. In a culture where warnings are ignored to the extent that they've grown to be 10,000 strong, developers are not likely to see the merits of removing warnings from old code that seems to work and no one has touched for a long time.

Once the number of warnings has stabilized, or even started to trend slightly downwards, you can work on reducing the number of warnings. If the maximum number of warnings in the build is currently 10,000 then set a target. Agree that in a weeks time the number will have dropped to 9,900. Or agree to look at the classes of warnings and target the worst one.

You don't have to get to zero. Getting to zero would mean removing warnings from old code that hasn't been touched for ages. That's not as important as changing the dynamics of the how people act so that the number of warnings is going down rather than going up.

Once you get to a level your happy with, don't turn the build-checks off. Don't take your finger out of the hole. If you do that warnings can easily start to rise again. Leave them in place.

Once you get to a level your happy with, look at ways you can improve further. Buy new tools that detect new warnings. And start again. Focus on improvement not perfection.

#include - there is a third way

Isolating legacy code from external dependencies can be awkward. Code naturally resists being isolated if it isn't designed to be isolatable. In C and C++ the transitive nature of #includes is the most obvious and direct reflection of the high-coupling such code exhibits. There is a technique that you can use to isolate a source file by cutting all it's #includes. It relies on a little known third way of writing a #include. From the C standard:

6.10.2 Source file inclusion
...
A preprocessing directive of the form:

  #include pp-tokens 

(that does not match one of the two previous forms) is permitted. The preprocessing tokens after include in the directive are processed just as in normal text. ... The directive resulting after all replacements shall match one of the two previous forms.

An example. Suppose you have a legacy source file that you want to write some unit tests for. For example:

/*  legacy.c  */
#include "wibble.h"
#include <stdio.h>

int legacy(void)
{
    ...
    info = external_dependency(stdout);
    ...
}

First create a file called nothing.h as follows:

/* nothing! */

nothing.h is a file containing nothing and is an example of the Null Object Pattern). Then refactor legacy.c to this:

/* legacy.c */
#if defined(UNIT_TEST)
#  define LOCAL(header) "nothing.h"
#  define SYSTEM(header) "nothing.h"
#else
#  define LOCAL(header) #header
#  define SYSTEM(header) <header>
#endif

#include LOCAL(wibble.h)  /* <--- */
#include SYSTEM(stdio.h)  /* <--- */

int legacy(void)
{
    ...
    info = external_dependency(stdout);
    ...
}

Now structure your unit-tests for legacy.c as follows:
First you write the fake implementations of the external dependencies. Note that the type of stdout is not FILE*.

/* legacy.test.c: Part 1 */

int stdout;

int external_dependency(int stream)
{   
    ...
    return 42;
}

Then #include the source file. Note carefully that we're #including legacy.c here and not legacy.h

/* legacy.test.c: Part 2 */
#include "legacy.c" 

Then write your tests:

/* legacy.test.c: Part 3 */

#include <assert.h>

void first_unit_test_for_legacy(void)
{
    ...
    assert(legacy() == expected);
    ...
}

int main(void)
{
    first_unit_test_for_legacy();
    return 0;
}

Then compile legacy.test.c with the -D UNIT_TEST option.

This is pretty brutal, but it might just allow you to create an initial seam which you can then gradually prise open. If nothing else it provides a way to create characterisation tests to familiarize yourself with legacy code.

The -include compiler option might also prove useful.

-include file
    Process file as if #include "file" appeared as the first line of the primary source file.

Using this you can create the following file:

/* include_seam.h */
#ifndef INCLUDE_SEAM
#define INCLUDE_SEAM

#if defined(UNIT_TEST)
#  define LOCAL(header) "nothing.h"
#  define SYSTEM(header) "nothing.h"
#else
#  define LOCAL(header) #header
#  define SYSTEM(header) <header>
#endif

#endif

and then compile with the -include include_seam.h option.

Fred Foster's Swing Tipping

is an excellent (out of print) book by Fred Foster (isbn 0-304-29467-5). As usual I'm going to quote from a few pages:

Imagine you are just lifting the hook gently but firmly into the fish and you've got the idea.

As soon as the bomb has settled, I tighten up to it in the normal way and set the swing tip. That's the starting position. I leave the bait there for one minute and then twitch it forward for the first time. ... I give my bait a twitch once every 30 seconds after leaving it for the opening minute.

On hard fished waters, my aim is always to fish as far out from the bank as the prevailing conditions will permit.

As I see it, the hook is always far more visible to the fish when the bait is suspended (as it mostly is with the float) than it is when the bait is on the bottom as it always is when swing tipping.

I prefer a 3 foot hooklength.

In my experience, accurate casting is more vital when swing tipping than in any other form of fishing I have known.

There isn't such a thing as a magic bait and if those who suspected it spent their time practising their tipping instead of wasting it on wild goose chases like this they'd start to give the likes of me a closer run for our money.

Accurate synchronization in the placing of the hookbait in relationship to the feed is one of the most important requirements if you are to achieve any real success.

It's a case of practice makes perfect until you can drop that bomb on the same spot every time.