In the ten years I’ve been programming I’ve learned two pretty important things.

1. Project success is about people and teams. No matter your process, good teams will succeed (usually in spite of your process) and bad teams will fail.
2. Every time you make a rule about something, people will stop thinking about that thing and blindly apply the rule.

This sounds pretty bland, even chinese fortune cookies usually have more interesting things to say, until you think about one of the consequences. You need good people for project success but if you give them too much rules they will stop thinking and become as smart, or as stupid as the rules. Most Methodologies seem to think that more rules is better. If a rule doesn’t benefit you it surely won’t hurt too much, just implement as much as you can and things will surely get better.

More...

Just to see how doing an open source project would work Rob Cooper from Can’t grok won’t grok and me have started a small open source project. World, please meet EMo. EMo is a small component to make unit-testing events in .Net languages easier to write and easier to read.

More...

I started writing a reply to this post but it got kind of long, by the time I started thinking about adding pictures it dawned on me that it’s probably a good idea to write my own post on the subject.

The discussion here is based on an idea from lean development. Traditionally people thought that quality had a price. Removing defects has a cost so more quality means higher cost. Lean production tells us this is not true. If you remove the defects sooner you can remove them cheaper. By removing the cause of the defects you can prevent them from being added. This will not only improve the quality but actually remove the cost of fixing the defects. Agile methodologies like XP show us that this works for software too. Up to a point.

More...