extreme programming adventures in c#

Just finished the above book. I quite liked it, although it felt a bit long. I had to force myself to read it as it seemed to be labouring the same point over and over towards the end.

I'd still recommend a read, however.

Is it just me, or do technical books that are over 500 pages seem too long? I've read shorter ones and found that I blitzed through them.

I like books that:
- are short (300 pages or less)
- are very short (100 ish pages)
- have loads of useful stuff in them (this keeps them fresh to the end)
- or cover lots of specific topics so it feels shorter, like the 50 effective tips in C# book.

So if I ever write a book, I should remember that.

agile cooking!

I had to cook dinner tonight as my wife is busy at work.

And since I had to drop off and pick up the kids it meant that I was under time stress to meet my dinner deadline.

How to expedite the cooking process? How?

I knew that I needed the oven hot to cook the frozen delights, but I didn't know the required temp.

Right, time to be agile!

Step 1, turn on oven to approx temp
Step 2, search for suitable frozen delights for consumption
Step 3, determine exact temp for cooking and adjust thermostat.

Fantastic, I dealt with my riskiest concern first, got started with it, then adjusted when I know exactly what I wanted.

What an analogy!

silver bullet

I wish that there was one simple thing that I could do to ensure success of my projects.

I know more than I used to. I read and think and experiment. These things help.

But there is no one thing that ensures success. There is no silver bullet.

There are lots of things that will help:
- constant feedback
- constant review
- constant planning
- improving communication

But these are comprised of many more things/techniques. There is so much to consider and each project is different, so your concepts and tools will need to be adapted.

All I can suggest is to improve your knowledge and experience and talk to anyone that can assist. Ask to anyone that has experience. Ask anyone you respect. Ask anyone anything...

Don't be surprised if the quietest member of you team holds some gems that can help.

(If you do have a silver bullet, then please let me know)

management overhead

A while back I was asked if the effort expended to determine your progress/position in a project was worthwhile.

Well...

In almost all cases the answer is YES.

If you don't measure/review, then you cannot know if you're moving in the right direction. I won't bore you with an analogy of a boat a sea without a GPS... I'm sure you can imagine that.

So how do you determine how you're going? This is really something that is different from project to project, but assuming that you've got a project goal, you can assess your position against that. You do have a project goal, right?

An I'm assuming that from your goal you've worked out milestones? Yes, of course you have. So all you have to do is work out how you'll move from milestone to milestone, all the wile moving in the direction of your goal.

Easy.

2.5 times

The above number is the cost factor of making mistakes.

Don't get me wrong, mistakes equate to experience. And experience is very important.

But if possible, avoiding mistakes/moving in the wrong direction can save you 2.5 times the time.

Why? Here's an example:

Suppose I work on a task, like the one described in the previous post and it's something that the customer didn't want. It takes me 1 day to complete it.

The real cost of this is:
- 1 day to implement the unnecessary feature/mistake
- 1 day lost of not implementing required features
- 0.5 days of context switching and clean up

So it cost me 2.5 days.

Ouch.

In a sprint, that's a lot of time lost.

Now I must tell you not to have fear of doing anything in case it's wrong. This is not the point of this post. It's really about making you aware of the cost of doing the wrong thing, implementing an unnecessary feature, or working for too long without feedback from your customer.

How do you remove the fear? Always discuss what you're doing and how you're going with your customer.

COMMUNICATION.

This will help you stay on track and improve your development velocity.

customer on site

I was reminded how important this was the other day. I was fixing a bug and noticed that when the grid was refreshed that the grouped sections that were collapsed would re-open.

Right, I figured that the list should be in exactly the same state as it was prior to the refresh. Luckily, my customer was there for me to ask.

I showed him that the grid re-opened the collapsed sections on a refresh and I asked him should I ensure that they stayed collapsed. He said no, it should open them. That way, any entries picked up in the refresh would not potentially be hidden.

Great. This is communication!

It's just a pity that he's not always on site. Bring on the "on site" customer!

goal, goal, goal!

Yep, I stayed up on Monday to watch Australia play Japan. I'm not much of a soccer fan, but I really enjoyed the game. But this post is not about that.

I believe that in order to have a productive team one thing is important:

Communication.

Simple really.

Actually, it's not.

Lack of clear communication is the reason that things do not go as expected.

There are many techniques that can help communication and this post is about one: goals.

Goals allow all involved parties to understand where they are heading and what defines completion. Without goals you have no idea of direction or when you're done. Goals are very important.

Here's a simple plan:
1. define an overall goal that describes the desired result.
2. define sub goals that help you determine checkpoints to ensure that you're on the right path
3. measure progress against the goals
4. determine if the goals are sufficient to help you deliver, if not, define better goals

This way, you know what you're trying to achieve and you can determine how you're progressing.

yay

It's my birthday today. I'm now 34.

You'd think that that is a mature age, wouldn't you?

If I'm soooooo mature, then why did I just spent over $200 on fireworks?


Oh.
Right.
Because I like fireworks.

footy!

I went to the Swans v Roos game on Sunday.

I can't say that the Swans played a good game, but they managed to get home. The highlight was seeing Hall and O'Loughlin kick goals from over their shoulders.

Great fun.

It's a pity that more (Swans) games don't make it to Canberra.

boxing

I'm a big fan of OO.

Yup, BIG FAN.

So, I always like to do things in an OO way. This includes things writing statements like:

object1.Equals(object2)

in preference to:

object1 == object2

But I recently discovered that this will cause boxing if either object1 or object2 is a value type. And we should all try to avoid boxing.

Another subtle boxing issue can be in the form of:

MessageBox.Show("Today's Date: " + DateTime.Now);

In this statement, the DateTime value has to be boxed to allow it to be appended to the string. The way to avoid this is:

MessageBox.Show("Today's Date: " + DateTime.Now.ToString());

Simple really. This is the same for all Value Types.

If you want to know if there is boxing in your application, then use either ILDASM or Reflector and look for a box call in the IL. I don't know of a tool that will scan all of your files for boxing. I'm sure that there's gotta be one out there...