How Agile and PRINCE2 Can Play Nicely Together

I'm involved in the "How PRINCE2 and Agile can play nicely together" presentation that will be given at the next Prince2 and Agile Meeting.

I'm really excited by this. Yes, excited.

I know you think that I'm nuts and yes, you're probably right, but this is one of the issues that faces Agile developers in a government department.

We have to appease the gods of process and control - that's where PRINCE2 comes in. Upper management love the way that they feel like they're in control.

And if we can convince them that Agile is not a dirty word and will work with a governance method like PRINCE2, then we may just be able to bring new concepts into the area.

That way, everyone's happy.

And that can only be a good thing.

PRINCE2 and Agile, Round #2

The next PRINCE2 and Agile interaction meeting will be on Wednesday night at Wizard Solutions, 15 Barry Drive Turner, starting at 6pm.

This month there will be some small presentations on the way that PRINCE2 and Agile methods can play nicely together and what documentation from PRINCE2 is similar/different to documents in Agile methods.

See this for more details.

let me at them!

I was at a workshop with the business today. I spent over 2 hours presenting material on:
- what we've been doing,
- what we are about to do,
- prioritising coarse grained requirements,
- discussing a particular chunky concept, and
- gathering new requirements.

It was brilliant. I really enjoy these kind of things.

We started getting the business involved in a more agile development way and showing them how great things can be achieved faster and easier than they imagined (or are used to). All it takes is motivated people and the ability/authority to communicate.

As an example, a requirement that was suggested today, should be further analysed and delivered to production within about a month.

I know that according to Mary Poppendieck that cycle time should be improved, but it's the best I can do right now!

The best comment I received today was from a BA on our team said that she thought I would make a great BA. I take that as a compliment as I like to bust the preconceived ideas about what a developer is. (Damn stereotypes)

Report on the Agile and PRINCE2 Meeting

That was a fantastic start to the discussion of this topic.

We had some very experienced PRINCE2 people, including the person who brought PRINCE2 to Australia.

We also had some experienced Agile people there too. (Agile is younger than PRINCE2, and I don't want to start a competition!)

The discussion was very constructive and both parties were interested in seeing why and how they can interact. From the initial conversation, I can't see how with a little tweaking it can't be achieved.

We intend to break into small groups and look at particular issues and spend some time working out how they can be overcome.

I would like to thank Rowan who did most of the organising and Lawrie for coaxing the PRINCE2 guys to come along. Great Stuff!

There is more information on the Agile Canberra Group page at this link.

PRINCE2 and Agile - the meeting

On Wednesday 12th September at 6pm at Wizard Solutions Building in Civic, we will be having a meeting to discuss how PRINCE2 and Agile processes may better interact.

I'm excited by this kind of thing. I really enjoy talking about software development and ways to make it better.

I'm hoping to discuss how a structured project management process, PRINCE2, can interact with a process that is more flexible. We have some very experienced PRINCE2 practitioners and trainers coming along, so it should be great.

I hope that all can walk away with a better understanding of what each is trying to achieve and find ways to work with each other, rather than against.

If you want to come along, then please contact me by commenting on this post and I'll send you the details.

I will post up any exciting outcomes...

PRINCE2 vs Scrum

I was at 1 day overview of PRINCE2 today. It was interesting. Much better than I expected. The trainer was very good and he showed interest in the business aspect and the delivery as much as the process. Previously, I had viewed PRINCE2 as process focused, I.E. if I tick this box, then my project must succeed.

I am a certified Scrummaster. I wanted to better understand PRINCE2 so that it will be easier to see how the two play together.

Essentially, both frameworks/processes want the same thing: Successful delivery of projects to the customer/business. They have a few differences in their approach, but I think that this can be worked out.

I'm going to keep in contact with the trainer, as the Agile SIG that I'm involved in is also keen to get this sorted. He was also interested in this issue.

Oh, and I'm still an agile fan, but we need to determine how we can still function in a more process driven framework. I can't see PRINCE2 disappearing in the short term...

bye mitch

I read tonight that Mitch has moved to Melbourne.

I used to see Mitch every so often around the Canberra and at local geek events and I'm sorry to see him go.

I wish him well in Melbourne.

Rewarded?

I lent a colleague one of my recommended books a while ago - Code Complete by Steve McConnell. He returned it today with five $1 scratchies.

Thanks Dave. Much appreciated, but unnecessary.

I'm more than happy to lend my books in the hope that it improves their knowledge and they may do the same for myself or others.

special thanks

I must give special thanks to Nick Randolph. I asked a question during his session at Code Camp Oz 2007 and he promised to send me a book as he didn't have any with him.

I have recently received the promised book. I'm impressed that he bothered.

It is much appreciated, but wow, bothering to remember to send me a book - some guy who interrupted a presentation, especially one requiring postage to the other side of the country!

I'm not sure that I would have, given the effort required. Obviously he's a better man than I.

end of an era

Several long standing members of our team left on Friday.

Shaun. What can I say about Shaun? He supported me when others wouldn't. I doubt that I would have had the opportunities I've had without him. I owe him many thanks. I learnt a lot from working with him.

Paul. What can I say about Paul? I can say that he hates plurals and doesn't like grammar. But he is an excellent team leader and has the respect of many. Yes, including me. He's gone to Brisbane for a change. Good luck.

Eddie. What can I say about Eddie? I can say that his knowledge is formidable. He was the go-to guy for the Dev team. I'm sorry to see him go, but it was his time. I wish him well.

Geoff. GT, you were not here long, but you were well liked. I was amazed to find out that you were in a Disco band. Good stuff. I hope that you enjoy your new job and I look forward to working with you again.


I will miss them all. They were a great bunch of guys. I wish them well in the new endeavours, and look forward to crossing paths with them again.

There are several others leaving at the end of June. I'll leave the teary farewells for them until then.

Certified ScrumMaster

I am now a Certified ScrumMaster.

w00t!

I returned from the two day course in Sydney tonight. I wholly recommend that if you're interested in Scrum that you attend a course like this.

What did I learn? Lots - and it's great to interact whilst learning. I had read the book and have been trying to get something like Scrum implemented for a while now. But to be able to talk with those that have is refreshing.

(And no, I didn't receive any gifts or payments for this recommendation. In fact, I had to fund the entire cost myself, including losing 2 days pay!)

Certified Scrum Master Training

I'm off to the Scrum Master Training in Sydney to get Certified!.

Should be good.

after code camp 2007...

I really enjoyed Code Camp 2007. It's great to go to a conference where everyone is keen and is obviously committed to their career, demonstrated by being prepared to spend a weekend of their free time to attend.

Big thanks to Greg Low and Mitch Denny. Fantastic work.

As an aside, we were asked to leave the venue as clean as we found it and so I collected about half of the Readify pamphlets for the up coming WPF session in Sydney that had been placed on each chair.

As a joke, the guys from my work have been placing those very same pamphlets on my seat at work whenever I get up form my desk. This has been going on since we got back. I'm amazed that they are so committed to the joke. The funny thing is - I bet they get tired of it before I do...

repeating myself

I want to repeat the contents of this post, but that would be breaking rule #1.

Seriously, I am amazed that there isn't a ruler poised above the knuckles of every developer that raps down whenever they duplicate code. Naughty, naughty, naughty.

Code Camp!

It's less than a week to Code Camp 2007. I'm really looking forward to this years event.

I have been to the last two and really enjoyed myself. If you thinking of going, then I recommend that you do.

Hope to see you there.

why pipelining? (response to Andreas)

Andreas added a comment to about this post.

The question was why would you pipeline?

Perhaps a definition is in order - I define this as encapsulating the conditional call check inside the function to:
- reduce duplication of code
- to remove the possibility that the check is not made before the function is called and
- ensure that the function is only executed when appropriate

I noted that this was different to Design by Contract (DbC), as in DbC if you fail the preconditions, then the application will throw an exception.

Consider this code, without Pipelining:

public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

private void OKButton_Click(object sender, EventArgs e)
{
string cleanText = string.Empty;
if (removeCheckbox.Checked)
{
cleanText = ReplaceUnderscoresWithSpaces(sampleTextBox.Text);
}

System.Windows.Forms.MessageBox.Show(string.Format("Cleaned text: {0}", cleanText));
}

private string ReplaceUnderscoresWithSpaces(string p)
{
return (p.Replace("_", " "));
}
}


This, rewritten with pipelining would be as follows:

public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

private void OKButton_Click(object sender, EventArgs e)
{
string cleanText = ReplaceUnderscoresWithSpaces(sampleTextBox.Text, removeCheckbox.checked);

System.Windows.Forms.MessageBox.Show(string.Format("Cleaned text: {0}", cleanText));
}

private string ReplaceUnderscoresWithSpaces(string p, bool execute)
{
string temp = p;
if (execute)
{
temp = p.Replace("_", " ");
}

return (temp);
}
}

(Changes in bold)

Now, forgetting the simplicity of this example (and some of the other minor issues), it shows that:
- the function identifies what it needs to execute,
- the conditional is inside the function, not dispersed throughout the code
- there is less complexity in the calling code
- the conditions of execution are in the function

But this technique is only useful for functions that do not have a side effect if they are not executed. I only do this when it's necessary to do so. But it's still a nice technique to remove duplication and clean up the calling code.

Code Complete, Second Edition

I've posted about this book before.

I bring it up because a colleague asked me about it, or I mentioned it, I can't remember - it doesn't really matter.

He said that he'd been told it was a good read.

I absolutely recommend this book to everyone in the software development industry.

It's a fantastic grounding on lots of topics that developers and others may not have considered.

There's two things I must say about this book:
1. It will take a while - stick with it.
2. Read it and then move on. As I said - it's a great grounding, but you need to keep reading other books after this one. It's just a good one to have read, or be going to read.

Patterns of Enterprise Architecture

I finished "Patterns of Enterprise Architecture" yesterday. It's very good and definitely worth a read.

I know, most don't read these kind of books cover to cover, but I like to amass all of the knowledge I can, in the hope that a little sticks so the next time I see an issue or an opportunity, I have more options...

Which book next, I hear you ask? Well, I'm 24.4% through "Agile Software Development - Principles, Patterns and Practices". This is a great book, bringing together lots of Agile and programming concepts into one place. I'm really enjoying this one.

reply to start choppin

My last post got two comments! So far, that's the best ever. (Pity one was deleted.)

But I'm not sure that I didn't cause confusion. Sorry.

To clarify, I was talking about programming languages. Not written languages.

If you read Start Choppin's comment you'll see what can happen without capitalisation in English. (Superb example, by the way.)


Careful, I've entered rant mode now...

I cannot think of a good reason to have case sensitivity in any programming language. If you have a good reason, then please let me know.

Rant mode off.

One reason I was given today was that the developer wanted to name the variable the same as the class, but only differ in case. For example (in C# syntax):

Link link;

Where Link was the class name and link is the name of the variable.

OK, seems a sensible reason. Except that it's bad form to name your variable the same as the class. Why, let's just say one word. Confusion. Much Better to name it something appropriate:

Link nextPageLink;

We can't have descriptive programming! No, that's toooo sensible.

But if this is your only argument for case sensitivity and you must call your variables the same as the class, then why can't the compiler know what you're referring to based upon it's context. Even VB6 could handle this.


And, the real point of my post was that we do things in software development that make it harder than it needs to be. Case sensitivity is just one example.

Another would be choosing to use an Object Orientated database instead of a relational database. (Can't wait to see the comments about that statement!)

stupid, stupid, stiupid!

I will never understand the need of case sensitivity in a language.

I'm sure that because C had it, everyone else who thinks that their "serious" language must have it as well.

I refuse to like having something in a language/application that enables me to make mistakes and have it next to impossible to notice.

Stupid, stupid, stupid!

back of my t-shirt

I've ordered a t-shirt for Code Camp Oz, 2007.

On the back I've put something that's a bit obscure. Those that know me will know that that's exactly me favourite kind of joke.

So, if you see me and don't understand it, then check out this link.

amazing!

I posted here about the lack of a particular feature in VS 2005. Turns out that it's already there, but turned off by default. (Thanks Rory for pointing it out!)

I'm not sure why - everyone I've talked to about this thought it should be turned on by default.

I was going to crack open the IDE extensibility area to add it myself, but it's already done.

I wonder how many other useful features are "hidden" in VS 2005/TFS?

my opinion

This is funny - Mitch has commented on this as well. (In fact, that's where I found it from. Thanks Mitch.)

I agree, there seems to be a real lack of skilled programmers.

But I'm not talking about those that are particularly skilled in a particular language, or those that know how to do tricks - like the swapping values without using a temp variable (2nd comment on on that post).

I talking about the developers who:
- can work in a team
- can self manage
- are thorough and meticulous
- complete tasks to, well, completion
- know how to dissect issues
- know how to measure progress
- know development concepts, like patterns, coupling, code structure, etc
- are interested in their career
- and know and understand development processes (and the point of it)

But unlike the attitude in that post and comments of just terminating those that don't reach the bar, I'm looking for those that:
- have the right attitude
- want to improve
- want to participate

Because then you can work with them so that they will improve and in return will help you improve as well.

I remember what it's like to not realise what I didn't know and not know how to find out. That's not a fun place to be.

website vs phone

A friend just had a new addition to their family. Exciting news.

My wife instructed me to send them flowers. Wives are good for remembering important stuff like that. So I found a local florist website and decided to use that rather than ring them up.

After about 10-15 minutes of having to fill out address and credit card information and select a suitable bunch of flowers, the deal was done. But it was a lot of effort.

If I had called them it would have taken about 2 minutes.

I've learned my lesson - next time I will just call them.

There are some things that don't translate well onto the web - having to be precise with address details, rather than just asking them to deliver to a particular hospital is an example.

I guess if they had automated the method of choosing the target location using common locations, then it may have been easier?

I think my point is, you shouldn't just translate a business transaction to the web without considering the usability aspect. There's no benefit in using this particular website over ringing the florist directly, in fact, it's a disincentive.

Silly, really.

something to do...

I was using VS 2005 yesterday with TFS and I was searching for some code using CTRL+SHIFT+F. You know, find in files. Very handy tool.

I double clicked one of the results and the file and the location in the code was loaded. Great.

But then I wanted to locate the file in the 100+ projects in the solution explorer.

So, right click on the tab for the file, but there's no option to highlight and show the current file the Solution Explorer. So I grabbed the closest team mate and had a rant.

He agreed with me. This would be useful.

So, my next task is to write an add-in or similar to make this work.

But, if you know of something or someway to do this already, then please let me know. Thanks!

fantastic

I tasked a team member with solving a problem today.

I defined the problem and the requirements, and provided some ideas I thought may solve the issue, but said that he should think of anything else that would also work.

About an hour later he came back with a simple solution that I hadn't thought of.

Fantastic!

I love it when people show their creativity and come up with new ideas.

I believe that you have to set goals for people and let them have the freedom to surprise you. This helps them gain confidence in themselves and add value to the organisation they otherwise may not have.

peer reviews

I had a interesting discussion with some team members today - they wanted to know why I wasn't enforcing peer reviews before allowing check-ins.

Let me state four things first:
1. I really, really like peer reviews. They are good for many reasons, including code quality, transferring knowledge, cross checking and keeping developers aware that someone else will be reading their code.
2. I think that code quality is very important. Especially the structure of the code. I have posted about this before.
3. We work in an iterative process where code lines are built twice a week, so there are opportunities to change before the final build.
4. Peer reviews are still carried out - they may just not be before the initial check-in.

So now, let me explain why I don't enforce them before the initial check-in:

It's very important to get the changes to test as soon as possible.
- Irrespective of everything else, the most important thing is to get the changes to test. The sooner it's in test, the sooner you'll find if the solution is correct, let alone if the code is high enough quality. And the sooner it's available to show to the customer, the sooner they can confirm that you're on the right track, or for them to refine the goal.
- It's important to keep developers focused on delivering. We've all been in refactoringits, where you just need to refactor one more function... If you have to get it to test, then it helps to keep you on track.
- It's rare that I find critical issues in peer reviews. If I do find them, then I address them and the reason behind them.

Most developers write adequate code.
- Most professional developers write adequate code. By that, I mean that it will function correctly and not have obvious issues.
- In order to improve someones skills takes time and effort and most importantly, a drive from the student to want to learn. Jamming a bunch of standards down someones throat is not the best way to improvement.

Improvement will come over time.
- Hopefully your developers are improving their skills. This is something that tends to happen. Even if it's just experience with the language or it's features, they are improving. And a lesson learnt the hard way tends to stick.

Current knowledge
- You and your team have a certain amount of knowledge right now. This will change over time and you will find that what you thought was very important right now, turns out to be less so. So, you can't be too focused on certain issues.

Understand your team members.
- If you know your team mates' strengths and weaknesses, then you know what to look out for. You'll know that Jim* is great with c#, so he's generally pretty good. So it's less of a risk to not get to his peer review before check-in. (* Not his real name)
- You might know that Joe* is new to the team and the code base, so you'll need to keep an eye on him. (* Not his real name)

You can't change people.
- Well, not much. Just accept that.
- But they can change themselves. If they're in the right state of mind, then you can help them. And if they want to change and understand why then it's easy. This is the best scenario you could want.

It's an unwritten requirement.
- This is a bit of a cop out, but, it's not a stated requirement. And yes, it should be. But if you can point me in the direction of something that I can use as a good metric, then let me know. (Don't suggest lines of code, or even cyclomatic complexity. These have their place, but not here.)

It'll probably come back from test.
- this is not a bad thing (unless it's too frequent), but you probably will have an opportunity to change it and test it again.

Peer Reviews don't have to be the only place where code is reviewed.
- There's no reason why you can't get a team mate to check over your work at any time.

It's not all about the code.
- This one might sound strange, but trust me, once you remove the blinkers that developers tend to wear, you will see that code quality isn't the most important thing. But it's damn close.
- Delivery of quality results for the business are paramount. If this means that the solution is acceptable, but the code should be refactored, but isn't, then so be it.

Oh, one more thing. I believe that I've found the right balance for the current team and requirements that I have to work within. If things don't work as well as I'd like, then they get changed. Continuous review and feedback.


Now, if you work in an environment where the quality of the code is paramount, like medical software, or missile systems, then these suggestions are not for you. Enforce your peer reviews relevant to your process.

Does anyone want to comment on this? C'mon, you know you want to...

safety

Consider the following SQL:

SELECT title FROM books WHERE isbn = '0-321-12742-0';

This could be written with parameters as follows:

SELECT title FROM books WHERE isbn = :isbn_value;

The :isbn_value is the parameter in that statement. You can then supply a value for that. (How you supply the value depends upon your Oracle client. (This is not the important bit))

The great thing about the second SQL statement is that to Oracle it looks identical each time it's executed, irrespective of the actual value associated with the parameter.

So if that second SQL statement is executed frequently, Oracle will find it in the cache and therefore will not parse it again. This can have real performance gains.

But this is not the main reason I like parameters. Oh, yes, performance is important, but there's something else that they do.

Consider this SQL statement:

SELECT first_name FROM employees WHERE last_name = :LastName_Value;

In this statement, the :LastName_Value is the parameter.

If you supplied a value of "Smith" to this parameter, then the SQL would find all employees that have a surname of Smith. Good.

If I supplied a value of "O'Connor", it would find all employees that have a surname of O'Connor. Good. Hang on, it worked with a sting value that had an apostrophe in it!

If the SQL statement had been constructed in Code and the value substituted then the SQL would have been:

SELECT first_name FROM employees WHERE last_name = 'O'Connor';

And that would have failed. This can happen in PROD. That makes you look bad.

So the GOOD thing that parameters gives you is safety against time bombs in code. You will never have to worry about apostrophes in data again!

Note: It's not recommended to use parameters when the comparison between the field and the parameter is the LIKE statement. In that case it's better to use literal values. EG:

SELECT first_name FROM employees WHERE last_name LIKE 'Smi%';

But then, you'll have to deal with those damned apostrophes again. Oh well...

communication, coupling and stuff...

You may have noticed that I like reading technical books.

Why? Because:
- I like it.
- I'm interested in my work and they are a great source of information.
- I find reading on a screen harder than from a book.
- They don't require power and you can take them (almost) anywhere.

But I think that there's a better way.

I like the idea of learning via rich media and flexibility. What does this mean?

I'm thinking video, either on the web or on DVD, that really describes and demonstrates the important techniques and concepts of software development. And it should provide a method to further pursue information, if you need to. So it may start talking/showing concepts at a high level and you can then delve into them further, if you need to. So in this way it's not linear like a book, but relative to the understanding of each consumer.

So as an example we could talk about coupling.

Loose coupling is good, right? Depends.

Lets use buses and trucks as an example.

A bus is an example of tight coupling. It carries people around. That's about all it can do. But it does it well and it's appropriate for it's purpose.

A truck is an example of loose coupling - you can attach trailers that allow you to transport many different things, even people, if a trailer that like the back half of a bus was attached. So it's at the appropriate level of coupling. (BTW - The actual coupling and brake hoses are a fantastic example of interfaces as well...)

Now imagine that you saw a video showing this and that you could pursue further the idea of interfaces via a menu or a link. This way you can find out related information, or more details about the current topic.

I'm sure that this isn't a new idea, but I'd like to try it out.

follow up on the estimates post

A couple of things I should add about the estimate post:
- you should constantly monitor the progress against the estimate. If it looks like things are not progressing as expected, then adjust.
- define milestones and goals for the work that was estimated. This helps you measure your progress.

three things I like

There's three things that I want plug for no particular reason, other than I think that they're great. (And no - I haven't received any free gifts, although I'm willing to accept them.)

1. Mountain biking at Sparrow Hill. The track builders, Paul Cole and others, have built an absolutely fantastic cross country track. I must commend them. If you like cross country mountain biking and live near Canberra, then head out there. It's fantastic.

2. Indoor Cricket. This is a much underrated game. It only takes about an hour and a bit to play a game of skill and participation. And afterwards a drink and a chat. I play with a team at Weston Indoor Sports in Weston Creek. It's fantastic.

3. Toyota Hilux Dual Cab SR. I love my ute. I used to have a Holden Rodeo. I was a fool. The Toyota Hilux is an incredible truck. The thing is great to drive and incredibly useful. It's fantastic.

efficiency

So you want to be more efficient. Here's the key:

Only do what's really important.

Sounds too simple?

Let me explain:

Suppose that you have an application where the user can enter an amount. Your tester identifies that this will throw an exception when the value is very large. Now in the business context, a value this large will never be entered*.

So you investigate the issue, then implement a solution and then it has to go through testing.

Seems innocent enough.

Except that all of that time and effort could have been used in solving an issue that really is important. Granted that this is a simple example, but if you are doing a lot of these, then you're not really adding value. And the time should be allocated to higher priority issues.

* This example assumes that you are sure that the business will never need this functionality. You should never arbitrarily assume that something like boundary checking is not necessary. It normally is. And this is just an example, so take it easy on me!

estimation - aaarrrggghhh!!!

One of my work mates asked me about a book I've read the other day.

He told me that he was trying to improve his estimation abilities.

Yes - that ever present issue.

I totally understand. I, like everyone else, am bad at estimating. (But I'm better than I used to be!)

I once went into a yearly review and my manager said he thought my estimates were bad and that I had to fix it.

OK. I took it on the chin. So I asked for help, but none was offered. Not even a pointer...

That was one of the worst examples of leadership I've suffered through.


I have a much better understanding of estimation now. I have techniques and processes and guides to assist. But I had to work this out myself, through experience and research.

So I let him know that if he wants to talk about it, then I'm available. I'm more than happy to share my knowledge with anyone. I don't want others to have to struggle with the same things I've had to. And besides, I'm sure that their experience and knowledge can help me.

So you're after the techniques to better estimation. Here's a few:
- make everyone understand that an estimate does not equal a contract. The date or time that you estimate is not something that will happen, but something like it will. This leads to the next point.
- allocate the appropriate effort to the estimate. If the estimate is very important or the estimate will be used in some published article, then spend more time determining the actual content of the work and what's really required. This can lead to the next point.
- understand what's really required. In the process of dissecting the issue, you will have a better idea of what's involved and therefore a better estimate.
- estimate as a team. Other's opinions may help you consider factors you may not have.
- add some padding. Use your experience, so that if you're a chronic under/over estimator add the appropriate factor to help cover the slack. Or, pad using tasks of a lower priority that may or may not be completed (DSDM uses this technique)
- cut your work into small chunks and estimate those. It can be much easier to estimate small tasks.
- understand you. Find out why your estimates are wrong. Do you do more than in necessary? Do you double and triple check before completing? Do you fully understand the requirement? Do you know the technology/environment?

- don't use estimates. I know, this seems crazy. But this can be very liberating and very powerful. It requires certain things in order to work and getting those can be extremely difficult. But it can work. You will need:
- trust between you, your team lead, the manager and the business.
- honesty between you, your team lead, the manager and the business.
- frequent reviews of your progress against the goals. This is important to know how you're going.


I use some/all of these and I find that some work better in places that others.

There's probably others I haven't listed and my bag of tools is not full.

What do you do?

"patterns of enterprise application architecture"

I like Martin Fowler. I believe that he's one experienced and intelligent guy.

This is another book of his. He has a great style and all of his books are full of clear and useful information.

I've only read the Preface and Introduction so far, but I already like this book. I've also spoken to friends that have read this one and everyone liked it.

One of my previous managers have met Martin, but I think that it was a waste. I would have loved to have gone and seen his presentation.

"design by contract, by example"

I've just finished this book this evening. It took a little while, even though it only has 226 pages and it used a large font.

I liked it, but it wasn't quite what I was after.

I'm interested in design By Contract (DbC). It sounds like one of those things that some know about, some understand, but very few use.

Would I recommend it? Well, um, yes and no. It's pretty easy to read, but it's a bit (or a lot) like a Uni textbook. Actually it wasn't a hard read, so yeah if you want to read something on DbC, then give it a go - but it's not in my top ten.

something stupid

I've done something stupid - I've put in a bid to present a talk at the next CodeCampOz.

It's now under consideration. I'm not sure that it will be accepted, but if it does, then I'll really have to get organised.

It's going to be on coding techniques. This something that I think is very important.

In my opinion, the key is to be able to adapt to change, whether it be from:
- business decisions,
- improvements in your knowledge, or,
- some other thing that happens.

Basically it's about structure and techniques. Structure is more important than the lines (as long as the code does what it's supposed to do, but that's a given.)

One reason I want to do this is that I really enjoy the buzz from speaking in front of people. Don't get me wrong - it scares the crap out of me, but at the same time, it's fantastic.

Another is that I want to share what I know. I've invested a lot of time in reading and considering how I work and I'd like to pass that on to others.

The only thing that scares me about this is that I'll present the talk and then everyone will say, I already knew that.

But if I can help one person, then I'll be happy...

comment about "design by contract , by example"

I really enjoy it when a book has something in it that makes me go wow.

This book has one of those. It's not a major wow, but still.

It talks about how defensive programming can lead to difficult to find bugs. I'm a big fan of defensive programming, so it got me thinking.

Basically, the point was that for non Design by Contract (DbC) languages, the problem is that if a function just returns if the parameters are not valid (i.e using guard clauses), then the bug/issue may not be discovered and if it is, it may be in an unrelated place - Fair Point.

The DbC language will throw an exception if the contract is invalidated - Nice.

Although, and there's always an although, I'm a big fan of a concept that I call Pipelining. That's where the function will only act when the parameters that are passed require it to act. This means that the conditions of execution are placed in the function, not dispersed throughout the code.

These two concepts kind of disagree with each other!

Hmmm...

I guess this is why development is hard?

five things about me

Well, I've finally been tagged in this five things about me thingy. So here goes:

1. I started this blog in a course that Mitch Denny was giving back in 2004.
2. I can ride a unicycle. But not very well.
3. I found a dead body in Lake Albert in Wagga Wagga when I was about 15.
4. I was on community radio in Wagga. I had a two hour show on Friday nights. I think that there was maybe two or three people listening...
5. My house burnt down in the 2003 firestorm that hit Canberra. The only things we got out with are our two children, the clothes we were wearing and our cars. That's it.

So there you go. A bit of a mixed bag, and I tried to throw in a few curlies...

Now as I can't find five other bloggers that I know that haven't already been tagged, this is the end of the line. I guess the magic had to stop eventually...

rayman 3

I've been playing this game with my kids for the past month or so. I've got to say that it's fantastic - even though it's three years old. The gameplay and graphics are awesome. Yes, awesome.

I managed to pick it up from Dick Smiths Powerhouse during a 20% off sale for the huge sum of $16. The pack also came with Rayman 2, Rayman multiplayer and Rayman print shop.

Wholly recommended.

Especially for the big kids... ;)

a non technical book!

I've just finished reading "The Reality Dysfunction" by Peter F. Hamilton.

Whew! It's huge, 1221 pages... It took me over a week.

I wouldn't say it's brilliant, but it's not bad.

Apparently it's the first in a trilogy. Oh my, I'm not sure that I can find the time to finish it.

If you liked this then check out books written by Iain Banks or William Gibson.

happy new year

Happy New Year to the three people that read this blog!

why, why, why, why!

Why do we make things harder than they have to be?

<-- Here's an example.


The error message that you get is:


"Control cannot fall through from one case label ('default:') to another"


What it could just say is:


"You need to add a break; statement to the default section."


I think that this is unfortunately a common theme in IT - Things are more difficult than they need to be.

And yes, I just as guilty of this as anyone.