Developing software is a force of will...

Software gets complex whether you want it to or not. There are no magic bullets when it comes to developing software, following the right process or doing the right steps guarantees you nothing.

There are a couple of things that I've seen on all my successful software projects:

1) Force of will - willingness to do what it takes to make stuff work
2) Self discipline - trying to keep yourself from making the problem more complex than it is

These are things that come for free with good people.

Holidays!

I'll be in Ontario/Quebec in August. Three weeks. Looking forward to spinning down, maybe do a little exploratory coding. Should see what Mark is up to...find some place in the middle.

More Developers

We're hiring again. Another team, more developers.

Interviewing is keeping me busy.

The Power of 5 Ideas

We have asked our developers to come up with multiple ideas for each problem they're trying to solve. (One of Eric Evans recommendations). We were having the problem where we found one solution and made that work, rather than finding multiple solutions and selecting the best. To start we've asked for five. Bad ideas are as welcome as good ideas. It has had some interesting side effects.

Some observations of Zachs team:

1) Coming up with five ideas requires both partners in a pair to work together to come up with ideas. This leads to cooperation when creating ideas, more willingness to listen to other peoples ideas.

2) When coding, the idea seems to belong to both of you. It is no longer one persons idea, the act of writing them down together makes them everyones ideas. Coding can become more cooperative.

3) Just generating ideas makes you more open to change, and less tied to any single idea.

Nice unexpected benefits of introducing another good habit.

Behaviour or test driven development?

Dave Astels thinks it is important to change our idea of test driven to behaviour driven development. http://daveastels.com/index.php?p=5

Brian Marick thinks we should ask users to provide examples rather than tests.

Gerard Meszaros writes Unit tests to reveal object behaviour.

We write Functional tests rather than Design tests. It makes refactoring easier.

Which is right?

Well all of them provide focus on different aspects of the testing/behaviour of the system. They are all revealing the importance of different aspects of test driven development. Why do we need to choose one? Really, we don't. At different times each of them will become important.

Sometimes I want to describe the behaiour of the system. Sometime I want an seminal example of the system. Sometimes I want to drive my implementation. Sometimes I want a regression suite. They are all important at different times.

Found Dave Astels again...

Added his latest blog to my blog roll.

Mentoring

Mentoring is always a fun mix of:

1) Explaining
2) Letting someone do on their own
3) Demonstrating

It's especially fun to mentor someone whose bright.

Theories and Experimentation are like ...

Models and Coding.

Many models are good, they let you think of thing in different ways. They don't have any answers - only questions.

Coding is an experiment to see if a model works out. Some are right and some are wrong. And some are good enough for our current understanding.

Don't get hung up on your model (theory) or your code (experiment).

A Productive Team

The team I'm currently working on is highly productive. They motor through stories on a regular basis, there is little waste. They have a lot to be proud of. It makes my job easy.

On the other side the lack of waste also means a lack of slack - time to think and reflect on what you are doing. In the last week we allowed the team to "innovate" - take four days and do anything but stories. After being heads down for so long this week was a welcome relief, but also a huge learning experience for them. The payoffs for the project will be huge. People refactored, explored new ideas, and learned on their own for over 4 days.

In the past we have said to the team that they have at least four hours a week to innovate, that they should apply that however they can. The decision to defer a story for learning time is a hard one for a hard driving team and they haven't been able to make use of that time.

We will now be asking them to figure out how "innovate" like we did this week. They'll need to figure out strategies to be able to do it while developing stories. And I know we'll only gain productivity.

Tests

For those who are counting we now have 4700 tests running.