Please stop moving deadlines

I've been struggling with deadlines for a long time, and I've finally discovered the pattern that makes my struggle most painful. They move all the time. A moving target is harder to hit than a stationary target, so my theory is that the more deadlines move the more futile planning becomes. The good thing about time is that it (usually) only moves in one direction, but man has invented budgets to compensate for this glaring lack of complexity.

So what can we do? Well just never, ever move a deadline. I will go into detail some later post on how to avoid deadlines altogether, but for now let's just consider what happens if you make the deadline stationary.

When you refuse to move the deadline the thing will not be DONE.

This is not a problem. Nothing is ever done. Done is an invention by people who like tickboxes. When the deadline comes you just do what you planned to do at that deadline, or you conclude that you have failed. Failure is good. Failure is the only true done. If you have failed you are free to go do something else, probably something that you have found the inspiration to do when you were dragging around Doomed To Fail project X. A deadline that can't be moved helps you to fail early and this will save time and money.

When you refuse to move the deadline the thing will not be as good as it can be.

This is a misleading statement. If you're building a cruise control driver, "as good as it can be" is a well defined concept, but most of us aren't building those kind of applications. What we're building is usually the implementation of some idea somebody dreamed up with very limited input. It might be a very good idea, but it's not well defined. In fact it's our job to define it based on small hints the product owner is giving us. This makes "as good as it can be" a moving target. The longer we wait to deliver, the further ahead the dream of the business will get ahead of our actual implementation. And the bigger the disappointment when we finally do deliver what we have.

But just look at what we have now! We can't deliver like this, right?

Maybe you're right - you're probably not though. Delivering is easy and delivering something that sorta works is much better than delivering nothing at all. You don't know if the business can break even with the thing you consider crap before someone tries. It is your obligation to try this as soon as possible. Cheating your customer into thinking he's going to get rich is not professional.

Much more important though: the longer you wait, the more you're going to think you're not ready. Dreams go faster than reality and by definition you will never catch up. By delivering whatever you have on the deadline and not moving it you're delivering reality to the dreamers. The earlier you do this the more they will keep liking you.

Ok, no more moving deadlines. But what happens after the deadline?

Well, its simple. After the deadline people will invariably think it can be done better. If you deliver your ideas of how to do things better with the unfinished product, you might get a chance to fix the things you wanted to fix before delivering. The good news is that you will get that chance based on realistic expectations. And if you don't get that chance you're free to do something else, which might not be a bad thing at all.

Posted via email from iweinfuld's posterous

Stir fried spicy spinach

There's nothing original about stir fried spinach with a dash of other flavors, but this combination was pleasant enough to mention anyway. 

Per person:

• 200g spinach
• 2 cloves garlic
• 2 thai chilies (a normal chili pepper should work fine too)
• juice of half a lemon
• 1 tbsp grenadine concentrate (Ayurveda)
• arachide oil

Heat the oil over medium heat, add the ginger  in fine slices so it can get acquainted with the oil. When the ginger is getting soft add the garlic (bashed and chopped) and chilly, also finely sliced. After a minute or so, add the spinach and increase the heat. Stir until the spinach is done and add the grenadine and stir again. Finally turn of the heat and add the lemon. The taste is quite funky, but definitely worth the 10m that it takes to make.

Posted via email from Koken en Eten

Untitled

I made this for lunch yesterday and it was even better than I expected:

• 3 eggs
• handful of coriander leaves
• two hands full of mushrooms
• juice of half a lime
• 2 tbsp of skimmed milk
• 1 tbsp sesame oil
• 1 tbsp sweet soya sauce
• 1 tsp thai fish sauce
• rice oil (to fry in)

Chop the coriander and whisk all ingredients together except for the rice oil and the mushrooms. Slice mushrooms. Heat up a frying pan and toss in the oil and mushrooms. Fry until the mushrooms have lost most of their liquids and give off their aroma.Reduce the heat (or take the pan off the heat for the moment). Whisk the mushrooms into the omelet mixture. Make sure the pan is clean (if you have a good pan you can just stare at it for 0.5 seconds), add some more oil if needed and gently poor the omelet mixture into the pan so that the mushrooms are spread well. Gently fry the omelet on medium heat, turn it if you feel like it. When it's golden brown and completely solid you can eat.

(all the amounts in this recipe are wild guesses as usual, I don't believe in careful measurements when cooking)

Posted via web from Koken en Eten

Note to self: how to sparsely check out a git repository

Today I discussed with Dave Syer about some improvements in Spring Integration, which I had sandboxed in my messy github repository. A sparse checkout would be convenient, but we both didn't know how to do it. I even thought git didn't support it, but boy was I wrong!

iwein:si-sandbox$ git init

Initialized empty Git repository in /tmp/si-sandbox/.git/

(master) iwein:si-sandbox$ git config core.sparsecheckout true

(master) iwein:si-sandbox$ echo message-store/ >> .git/info/sparse-checkout

(master) iwein:si-sandbox$ git remote add origin git://github.com/iwein/Spring-Integration-Sandbox.git

(master) iwein:si-sandbox$ git pull origin master

The important thing to remember is that this also works with git-clone. Your index will still have everything, just your checkout (working copy generated from the index) will not. This is a big difference with svn sparse directories, and as usual it's an improvement.

Posted via email from iweinfuld's posterous

Using negative feedback to prevent disaster in Software Development

Invariably we are taught that when working with people we should give them plenty of positive feedback whenever they do something right and be very careful with negative feedback. I've never completely bought into this hugging hippie attitude, but it seems there is a good point there: if we're all nice to each other and keep a positive spirit, we get more done right? The problem with this approach is that it doesn't take into account that it might be important to not get something done. Some ideas are just terrible and they should be killed off as soon as possible.

When I had the idea for this blog I thought it would fit on twitter. "Positive feedback induces brilliance, negative feedback prevents disaster. The latter is sadly undervalued." i twote. It seems this could use a few backing arguments and today I've made time to provide them. I will explain why negative feedback is important and how you can apply it to your advantage.

What's the problem with positive feedback?
Positive feedback induces brilliance. Like the brilliant glow of a nuclear meltdown is caused by positive feedback. If you're doing something absolutely great, positive feedback will cause you to do more of it and it will cause others to try and emulate your behavior. Brilliant right? But what if you're doing something that is ever so slightly off target? Will positive feedback make you augment your course? Will it make others slightly vary your behavior before emulating it? I don't think so. You need negative feedback to change.

I have a background in physics and some electronics and signal analysis is part of that background. In electronics positive feedback doesn't have the credits that it has in social studies. It is viewed as a destructive force that will ruin your signal, make your appliance useless, or even destroy things. Let's look at the example of a feedback loop in it's most generic form:

Download now or preview on posterous

PastedGraphic-1.pdf (18 KB)

In the diagram you see input being processed by a system G the output of G is connected to its input via a feedback loop. If the feedback is negative or zero, the output will be strictly related to the input. If the input drops, the output goes to zero. If the feedback is positive two things can happen: first, if the feedback is less than the input, the output will eventually go to zero, but it takes more than one loop. In audio this is called an echo. It's not dangerous, but it can pollute the output if the echo is of a sound that you didn't want to hear. If the feedback signal is stronger than the input, when the input drops the output will continue to increase. In audio this is called a feedback loop, the typical symptom is a high frequency tone that gets louder and louder until either the speaker gives or the amplifier can't go any louder. This is not considered a good thing generally.

If we apply this model to human interaction, it still works. Let's say the input is an idea by developer Joe, G is the team. Let's say the idea is to improve quality by adding more test cases. Let's say the idea pays off the first loop and everybody is very happy. This causes some serious positive feedback. The feedback will say: "More testing is good". And more resources will be invested in testing. Depending on the positive attitude of the team this will lead to more and more resources being spent on creating tests, until there are no more tests to write or the team is out of resources. As much as I like tests, that's crazy. So developer Bill will come with the great idea to spend less time on testing. The first loop this will get positive feedback because the team gets stuff done again and the tests are in place to keep them safe. Two loops later we're in the hole again, quality is crap, coverage is abominable, we're stuck. Rinse and repeat. Does this really happen? You bet!

There is a dangerous psychological phenomenon that is entirely caused by positive feedback in groups, dubbed Group Think

The reason that people fall into this trap in my opinion is that they have the instincts to give positive feedback and act on it. Also our education system is based on it because it works well on small children. But in fact getting only positive feedback makes you lazy and stupid. What can we do? Simple: introduce negative feedback.

I thought negative feedback was bad?

If negative feedback means bashing then yes, it's bad. If negative feedback means using force, it's bad. If negative feedback is used to block others, it's bad. But it doesn't have to be that way. In the case were Joe suggested testing the first iteration good things happened, but then it spun out of control.

Download now or preview on posterous

PastedGraphic-5.pdf (18 KB)

The team lost track of the goal: working software and started focussing on some symptoms like test coverage.

In the next image the green arrow are the actions the team is taking, the red arrows are the negative feedback that is applied to reach their goal instead of overshooting it. 

Download now or preview on posterous

PastedGraphic-4.pdf (19 KB)

The important thing is not to stop the team from doing what it's doing, just to stop it from doing it too much. Make the team do it better instead of more. In some cases a really terrible idea comes up and no time should be wasted on it. In those cases people usually have no problem killing off the idea. The problem arises when a good idea comes up but the implementation is not completely right. It's only human to want to move forward when you're going strong and that makes it very easy to overshoot the goal entirely. The trick is to gradually apply more corrective negative feedback once the team gets closer to a goal.

Thinking about decision processes using this metaphor works for me. I hope you find it useful too.

Posted via email from iweinfuld's posterous