with pants comes dignity

How Agile and PRINCE2 Can Play Nicely Together

2007-10-09T00:02:00.000+10:00

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

2007-10-08T23:57:00.000+10:00

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!

2007-09-13T22:35:00.000+10:00

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

2007-09-13T22:23:00.000+10:00

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

2007-09-10T23:41:00.000+10:00

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

2007-08-06T22:18:00.000+10:00

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

2007-06-24T23:19:00.000+10:00

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?

2007-06-14T23:22:00.000+10:00

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

2007-06-03T00:17:00.000+10:00

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

2007-06-03T00:03:00.000+10:00

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

2007-04-27T23:32:00.000+10:00

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

2007-04-12T23:13:00.000+10:00

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

Should be good.

after code camp 2007...

2007-04-12T23:05:00.000+10:00

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

2007-03-25T23:12:00.000+10:00

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!

2007-03-25T23:07:00.000+10:00

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)

2007-03-21T23:35:00.000+11:00

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

2007-03-19T23:25:00.000+11:00

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

2007-03-19T23:18:00.000+11:00

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

2007-03-17T00:08:00.000+11:00

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!

2007-03-15T21:57:00.000+11:00

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

2007-03-11T14:40:00.000+11:00

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!

2007-03-04T11:33:00.000+11:00

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

2007-02-28T23:44:00.000+11:00

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

2007-02-28T23:35:00.000+11:00

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...

2007-02-28T23:15:00.000+11:00

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

2007-02-22T23:51:00.000+11:00

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

2007-02-16T23:44:00.000+11:00

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

2007-02-15T22:29:00.000+11:00

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...

2007-02-07T23:34:00.000+11:00

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

2007-02-07T23:27:00.000+11:00

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

2007-02-05T22:58:00.000+11:00

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

2007-02-05T22:48:00.000+11:00

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!!!

2007-02-03T23:00:00.000+11:00

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"

2007-02-03T22:38:00.000+11:00

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"

2007-02-03T22:30:00.000+11:00

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

2007-01-28T22:49:00.000+11:00

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"

2007-01-22T23:19:00.000+11:00

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

2007-01-05T22:24:00.000+11:00

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

2007-01-02T23:30:00.000+11:00

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!

2007-01-02T00:02:00.000+11:00

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

2007-01-02T00:00:00.000+11:00

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

why, why, why, why!

2007-01-01T23:28:00.000+11:00

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.

attitude?

2006-12-24T23:44:00.000+11:00

I keep hearing comments in IT that we know better than the business.

Hmmmm...

We know technically how to work with computers better than the business (mostly), but we do not know better than them. I'm always saddened by that attitude. We need to work with them to get the best result. Its like pancakes with only lemon and not the sugar. Or the other way around... You choose.

I think that if you're concerned that the business doesn't know what's what, then you have to help them work it out.

Try talking with them, showing them samples, involving them in the process...

You might be surprised.

merry christmas

2006-12-24T23:43:00.000+11:00

to all...

how many books?

2006-12-18T22:34:00.000+11:00

One More Done.

I've finished "User Stories Applied" by Mike Cohn. Good, but draws a lot from his Estimating and planning book.

I've also now started "Design by contract, by Example" by Richard Mitchell and Jim McKim.

I'd like to read a good book on the DbC subject. Sounds like another great idea in the programming techniques spectrum that doesn't seem to have been embraced. Well, at least from my experience.

one more book on the finished pile

2006-12-07T22:56:00.000+11:00

I've finished "Applying Domain Driven Design and Patterns: with Examples in C# and .Net" by Jimmy Nilsson.

I found that this book was difficult to read - it just didn't keep me interested. It was dry and somewhat uninformative. When I compare it to any book in the Pragmatic series, it just doesn't cut it.

Books shouldn't be a chore to read. I'm really quite interested in Domain Driven Design, but I didn't really get much out of this book that couldn't have been written in about 50 pages in the pragmatic style...

Pity really - maybe I've turned into a jaded critic?

On another note, I'm a quarter through "User Stories Applied" by Mike Cohn. Seems quite good.

one more book

2006-10-18T14:35:00.000+10:00

I've just finished "The Pragmatic Programmer". This is another excellent book in the Pragmatic series. I highly recommend that you read it.

I've just started "Applying Domain Driven Design and Patterns". It seems quite good from the 10 or so pages I've read so far.

That's two down from my current stack of 10 that I'm getting through...

hey

2006-09-27T22:54:00.000+10:00

I've been quiet lately. There's several reasons for this - none too exciting:
1. Busy at work. The usual excuse.
2. Reading. I've finished "Crystal Clear" By Alistair Cockburn. Much better than I originally thought.
3. Stumble. Check it out. It'll suck you in...
4. Bought 10 more books. I've read the first (practices of an agile developer), and onto the second (the pragmatic programmer). Got to say that every pragmatic book I've read has been great.
5. Lazy. No excuse for that one.

So I'm sure that I post a bit more frequently from now.

Yeah, right.

switched on

2006-08-25T23:29:00.000+10:00

I am preparing a coding techniques workshop for the dev area at work.

I've been reading and researching coding techniques for over two years now and I want to share the knowledge that I've learnt. It seems to me that it's not so much the lines of code you write (although that is still important) but it's more the way you structure your code.

One developer on our team was interested to see what I was going to present, so I ran some of the concepts by him. He was keen to give them a try.

He seemed to "get" the reasons why this concept is important. So much so that in the next task he was working on, he was applying them. It was amazing to see how the change had effected his coding.

He was switched on.

performance

2006-08-14T22:39:00.000+10:00

Sometimes the illusion of performance is enough.

Here's an example:
I just tried to copy a DVD full of files over to my hard drive. It got part way through and then it threw an exception. Some of the files got over, some didn't. So now, I'm copying the files one by one. This is a slow (and annoying) process.

But copying them as a group seems faster.

I'm not sure that the actual time taken by the computer will be that different, more that my interaction will slow the process down.

This is a great example of how the time involved is similar, but the effort and inconvenience is higher when moving over files one by one.

This is demonstrating is that by using a "natural break" in the process, it seems easier and faster.

This is a lesson for application design. Look for
- breaks in the workflow that can be unobtrusive to the user
- ways to group actions without involving the user (could be as simple as multiselect in a list)
And this will help your application appear to be efficient.

Try to avoid:
- frequent pauses and halts to in workflows
- lack of feedback about what the computer is doing
These make your application annoying and slow.

Some simple rules:
- always give feedback to the user, especially where the delay could be more than half a second
- show them that the process is still executing
- if possible tell them exactly the progress of the task and the expected completion

testers

2006-08-11T21:56:00.000+10:00

I like testers.

I used to think that they were only for testing the application to make sure that I'd completed the task correctly.

What a naive view on the true power of testers.

Testers can make your project so much more successful. You should include testers from the very inception of the project. They can help with:
- analysis of the issues
- define the scope of the work
- define successful (and unsuccessful) conditions
- show you what's necessary to complete the task
- provide a different point of view on the issue and how it fits into the application/project

"How? " I hear you ask.

Well, quite simply, get them to analyze the requirements, write test plans/test cases in the initial stages of the project/task. This effort almost the same as them writing the test plans/cases when they are delivered the application for test, but if that information is available to the developers, then they can use it to determine how much work there is to do. It can also be useful for the project lead/manager to help in creating a "block plan" of the tasks involved.

functions vs workflow

2006-08-10T23:26:00.000+10:00

I worked on a project a few years ago where the project requirements were in a Business Requirements Specification (BRS). The end result is usable, but it's difficult to get value from it - all the information is in the system, but bringing it together is tricky.

Had the requirements been defined in user stories/use cases, then I believe that the end result would have been much better. (It's important to note that the project was run in a waterfall fashion, so the users didn't see it until it was complete and that was too late...)

I can really see how analyzing a requirement/issue/project focusing on use and purpose rather than discrete functionally makes such a difference to the end result. Requirements analysis is still necessary - but it should be in context of use.

practice vs theory

2006-08-09T23:03:00.000+10:00

We had our first team estimation meeting today.

It's a technique from Agile Estimation and Planning.

Basically, the whole team provides estimates for the development and test component of each issue. The idea behind it is that as a group we should be able to better estimate the work that if just one does it. Additionally, since the work is not allocated a resource until just before it's started, anyone on the team may get the issue, so assuming that X will be responsible may skew the estimate.

It's interesting to see how things work when you are doing them for the first time and the team and the business are not experienced with particular techniques.

Several team members added very relevant points and I think that more agile concepts became understood by the team.

It went rather well.

where next?

2006-08-05T00:15:00.000+10:00

What's next for me?

My boss keeps telling me that his type of job, a manager, is the next logical step for me.

Hmm... I'm not too sure. I can see quite a lot of options, but I'm not drawn to be a proper manager, one that has to manage budgets, staffing issues and the like.

It's not that I wouldn't do it, but, I don't currently see the appeal.

I really like managing teams and being a technical specialist. That can lead into many jobs, including roles like:
- project management
- trainer (in team management, development techniques, etc)
- consultant (yes, like you Mitch)
- development specialist
- architect
- others that I can't think of because it's late and I've had a few drinks...

I guess my point is that the process shouldn't just be:
- developer, then
- team lead, then
- manager.

It's OK if that makes sense for you, but remember that people who are keen to step up have many options in their career. Find what you like to do, or are good at and work at it - you'll be amazed what you can do...

co-location

2006-08-05T00:06:00.000+10:00

We had a move today at the office. All seats were re-organised so that teams were co-located.

I was the bunny that was responsible for organising it. Several people complained.

Why do I have to move?

It's such an inconvenience!

What's the point?

Within an hour or so of moving, I overheard a conversation on an issue that I have to report to the business on on Tuesday.

Whammo!

This is the reason why it's important to sit with your team. The cost of communicating must be as low as possible. This can deliver real benefits to the immediacy of information and help.

There will always be nay-sayers. Ignore them and know the truth!

quote of the week

2006-08-04T23:58:00.000+10:00

I gave a presentation the other week about how we want to improve the current situation of the interaction between the support group and the business.

I had a slide that had the following line:

"more transparent and more visible"

Apparently the Business Analysts section decided that it was their quote of the week...

I know it sounds contradictory, but I'm wasn't after the literal meaning of those words. What I meant was:
- more transparent, so that the business can see exactly what we're doing, when we're doing it. This helps to improve trust.
- move visible, so that the business sees that we are there and know what we do for them. This helps to improve communication.

Both communication and trust are very important if you want to improve the acceptance of agile methods and get the business to become more involved and receptive.

Without trust and communication, you're fighting an uphill battle to get positive changes made.

more ducks, more rows

2006-08-04T23:47:00.000+10:00

After getting things in order as described in the ducks in a row post, things seemed better.

But recently I was feeling out of control again. So I set out to work out what the problem was...

It was those damn ducks again. The ones that I knew about were in a row, but several new had ones turned up.

I determined what information that I wasn't in control of and I made it visible - I had to get out my trusty duck herder and herded them into a row.

Much calm has returned.

(Hi to Nick if you're reading this!)

more on crystal clear

2006-08-02T23:32:00.000+10:00

I wasn't too enthused about Crystal Clear in my last post.

I've read some more since then and I think I misjudged it. It certainly gets better, but I still have the feeling I've read it all before.

I'm sure that that's because in the bit that I've read, it's all similar to other agile processes...

another book done

2006-07-23T23:23:00.000+10:00

Today I finished Agile Estimation and Planning. Quite a good book.

I am hoping to try out planning poker, but the work that we have on at the moment isn't really suitable for this.

The book has some good ideas and practices for dealing with estimation in an agile environment. Recommended.

I've just started with Crystal Clear. So far, I'm not enamored with it. I don't know why. I've been looking forward to it for quite a while. Perhaps because I'd read lots of stuff about it on the web that it feels like I already know the good bits, much like a trailer for a movie that has all the funny bits in it... Pity.

But I'll continue. I almost always read every book I start.

Tomorrow I'll be ordering some more from Amazon.

bonsai

2006-07-23T00:14:00.000+10:00

I'm an extrovert. I like to talk.

But sometimes I think that I can go too long. I also think that others do the same.

I have a thick skin and am not easily offended, but I know that others aren't. People interpret things in ways that upset them, even when that was not the intention.

Enter "bonsai".

It's a stop word. What I'm suggesting is that this is a substitute for asking someone to stop. But because the recipient can interpret in a way that causes them no offence, then there's no miscommunication.

It's a benign word that can mean:
- we're off topic now, can you please stop
- I have other important things to do
- I'm not interested
- you're boring me and others
- that's very good information, but we need to keep moving

Or anything - it's up to the recipient to interpret it in any way that they want. This means that it's less likely to cause an issue. The point is that everyone knows what the purpose of the word is.

You could use any word that was sensible for you. It's just thought that bonsai was suitable...

ducks in a row

2006-07-22T23:52:00.000+10:00

I've got a new team and role at work.

In the first week, I felt odd - something wasn't quite right. I felt, well, out of control. I couldn't work it out. I've been the lead on two previous projects and I knew that I could manage those. What was it that was giving me that uneasy feeling...?

On Thursday last week, I worked it out:

I was blind.

I couldn't "see" what the project was doing. I could fumble around and get bits of information, but not a decent overview.

So, I took the project and shook it about. I pushed it until I got what I wanted from it - visibility. I got my ducks in a row.

From then on, I've been feeling much better.

It's amazing how decent reporting has made everything much, much better.

I wholly recommend that if you're managing a project that you spend some time getting the right information at your fingertips. Once you do that, you'll be much happier.

simple things first...

2006-07-11T22:27:00.000+10:00

I was working on a small financial app the other day (to work out where all my money goes) and I found that I started to struggle to make progress.

While I was watering the garden, I was mulling over how I was going to get the automatic categorisation and difference between actual and budget amounts working and then BAM, I suddenly realised that I wasn't starting out with the simplest thing I could do.

I decided that categorisation could come later, I needed a win and I needed it now. So I decided to just break down all income and expenses by each month and graph that. Easy. Anything with a minus is an expense and anything with a plus is an income. Within an hour I had it working.

I realised that the power of starting off in a simple way and getting a success is very important to being productive.

It's amazing how the stuff that you read is true, sometimes you need it to experience it for yourself...

extreme programming adventures in c#

2006-06-25T23:52:00.000+10:00

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!

2006-06-21T22:58:00.000+10:00

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

2006-06-20T22:44:00.000+10:00

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

2006-06-18T00:04:00.000+10:00

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

2006-06-17T23:50:00.000+10:00

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

2006-06-17T23:47:00.000+10:00

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!

2006-06-17T23:28:00.000+10:00

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

2006-06-08T21:58:00.000+10:00

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!

2006-06-05T22:52:00.000+10:00

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

2006-06-05T22:19:00.000+10:00

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...

energised

2006-05-29T21:46:00.000+10:00

I spent some time talking with Mitch today.

Over cuppacinos, we chatted about processes, team dynamics, ideas, techniques and general development issues.

I could have gone on forever. This is the stuff I like.

If only I'd put more money in the parking meter...

d'oh!

2006-05-29T21:09:00.000+10:00

I like Test Driven Development (TDD).

I was starting on a small application the other day. So, I added a reference to NUnit, added a class to my new Windows Application and wrote my first test. Compile.

Now, over to NUnit to execute it...

Where is my test? I can't find it.

Right, I check the code. Yep, the appropriate NUnit attributes are there. What's going on? I double check the code and then back to NUnit. Rebuild, Reload. Rebuild, Reload. Still nothing.

Hmmm...

OK, I know that I have gotten this working before.

I have a small DLL that I have tests in. Open it in NUnit. Tests are there. Strange.

I create a new Class Library application. I write a test in it. Over to NUnit. It's there. Arrrggghhhh!!

Back to my Windows Application.

It's then I notice that there is no accessibility modifier on the class. I just assumed that it was public. I add a public modifier, rebuild and over to NUnit.

Test appears.

D'oh!

right of review

2006-05-20T22:52:00.000+10:00

I do a fair bit of peer review at work.
It's not fair.
It's easy to look at something that's there and find holes, or make suggestions.
I don't like doing it...

But part of me does.
It's the part that wants to help others. I'm able to add my input to the code to help the developer see what they could do better. This is a great way to share techniques and improve code quality.

One thing that I think really helps your own code is to write it and then review it yourself. This way, you can get something working and then make it better.

This is all part of XP/Agile.
Get something down.
See how it works.
Look for improvements.
Discover the design.
Only do what needs to be done.
Don't borrow trouble from the future.
Stop when it's good enough...

tools or techniques

2006-05-18T22:56:00.000+10:00

I saw a demonstration of a code gen tool today. It was quite good. But I think that code gen is both a good and bad thing.

One reason that I do like it is that it can save you an amazing amount of time. And deliver other benefits you may not have thought of, like auto generating doco and unit tests.

One reason that I don't like it is that you can spend an awlful amount of time getting it to generate the code that you want, and it puts in another layer into the design/feedback cycle.

But that is the point of this post - the code gen tool is potentially fantastic for development and it's also potentially bad for getting your application completed.

So the question is: If you have a really flexible tool, something like code gen, or even C#, is it that the tool is good, or is it how you use it?

I believe that you have to know how to leverage the tool to get the most out of it. This goes for code gen and development. Techniques will make you a better programmer. Knowing where to put a function can make an amazing difference to your application...

be explicit

2006-05-15T22:23:00.000+10:00

Another tip for better coding:
Always be explicit in your code.

Why? Well, consider this example. I was working on an application that required that the order of the rows in a grid that had been sorted and grouped be in sync with the order of the same results in an arraylist.

The current version of the code reacted to events from the grid to re-sort the Arraylist. Good. Except that when the grid was grouped, the arraylist wasn't being sorted correctly. :P

Two options (of several more...)
1. Find all of the events and ensure that the arraylist is synchronized each time the event fires.
2. Define points where I need the arraylist to be in sync with the grid and sync then.

I chose #2. Why?:
I know when I need the arraylist to be in sync and so I force it to be. Therefore I am being explicit about what state I need the data to be in. Relying on the events to sort the ArrayList is implicit. This means that I can never be sure that the order is correct unless I check it is. That's just a bomb waiting to go off.

Synchronizing in my function is similar to a precondition. This is a step in the right direction. My code required that the list was in order and I made it so. Therefore I ensured that the precondition was met in the function that needed it to be.

Sample Code:

private void OpenSelectedItem()
{
SyncArrayListWithGrid();

OpenSelectedItemInBrowser();
}

Now for simplicity's sake, I've ignored the implicit coupling (I'll post on this later). And yes, those are the names of my functions. If you don't like em, tell me why. I'd love to discuss coding styles/techniques with you.

it's finally happened

2006-05-12T23:34:00.000+10:00

Today. About 3pm. I was heard to say "w00t!, w00t!, w00t!".

I'd resisted for so long.

The utterance of these three words has such a serious meaning. I'm now Fully Geek.

And yes, the occasion did demand it. You try to work out why your data binding isn't working when someone had overloaded the standard Data Binding properties and implemented their own form of it and me without a clue that they'd done it. So, after I'd uncovered this and got it working (although a refactoring is yet to come), I said those three words.

w00t.

oo vs oh-oh?

2006-05-11T22:18:00.000+10:00

I had a discussion today with a guy at work about a point in David West's book, Object Thinking. The lines in question were something like:

"If you wrote a well designed OO functional equivalent version of an application that was written by a programmer that didn't understand OO, then the number of lines in the application would be at least one order of magnitude less, perhaps two. In addition, the time to market would be at least 50% less, perhaps 70% less."

His point was that this statement was unqualified. I'd agree. But when I read the book, I never really worried about that - as I believe that a proper OO program would definitely have significantly less lines than a regular program.

I have done some bug fixing and then refactoring (yes, they should be separate activities) and removed an amazing amount of code. All this without removing functionality and improving quality, simplicity, readability, robustness and reuse (At least I hope I did!). All by following simple OO concepts.

I tend to go on about this, but Duplication in all forms is your enemy. Blatantly obvious duplication is an issue, but you have to keep you eye out for functional duplication as well.

For example, suppose that you wanted to copy a set of phone numbers from an object obj that allowed them to be 30 characters to another that only allowed them to be 15:

obj1.homephonenumber = obj2.homephonenumber.tostring().substring(0,15);
obj1.workphonenumber = obj2.workphonenumber.tostring().substring(0,15);
obj1.mobilephonenumber = obj2.mobilephonenumber.tostring().substring(0,15);

This is an example of functional duplication. This should be changed to:

obj1.homephonenumber = NumberHelper.ConvertToOldFormat(obj2.homephonenumber);
obj1.workphonenumber = NumberHelper.ConvertToOldFormat(obj2.workphonenumber);
obj1.mobilephonenumber = NumberHelper.ConvertToOldFormat(obj2.mobilephonenumber);

And depending upon the hierarchy of the obj object, the function ConvertToOldFormat could be placed upon obj's parent.

Now for the reasons:
- the ConvertToOldFormat function is now testable via NUnit or similar
- the code is more readable
- the ConvertToOldFormat function could be re-used anywhere that the functionality is required
- the intent of the code is obvious
- if the rules regarding the convert process change, then there is only one place where it has the be changed
- the result of the ConvertToOldFormat function is consistent
- you can add preconditions, postconditions and invariants to the NumberHelper object to make your code more robust
- others will marvel at you abilities

There are so many opportunities when writing code to make these kind of choices - added together, your application can be so much better.

wow, you thought of me?

2006-05-11T22:10:00.000+10:00

My boss just got back from a two week trip to the US to check out how we are placed against the industry and to have a look at Microsoft. That's cool - but what really impressed me is that he brought me back a present: a business card from the Pike Fish Place Market. Thanks Shaun.

For those that have read "Fish!", you'll know what this place is.

For those that haven't - I guess it'll just remain a mystery...

big thanks to Eddie...

2006-05-10T23:40:00.000+10:00

I really like working with Eddie. He knows stuff. Lots of stuff. Ask him a question - I bet he can answer it.

I do not understand how he has such a broad grasp of the framework and the industry...

Thanks for the help today - you turned a task that would take me a couple of days of investigation to get going into an afternoon of fun.

I didn't think that control customization could be easy - but it is with an experienced guide.

first and second steps to being a better developer

2006-05-10T23:29:00.000+10:00

Two things that are important if you want to be a better developer:
#1 - Avoid Duplication.
As simple as that. There are very few excuses for duplication in code. Removal of duplication is important for so many reasons. Firstly, consistent behavior, secondly, better design. Yes, almost any attempt to remove duplication should move you into a better design position. And it allows you to improve your design easier if necessary. Do not repeat yourself. Do NOT repeat yourself.

#2 - Become a Better Tester.
Yup, a tester. I worked with a colleague years ago who was (and probably still is) a better tester than I. I helped her get her code working, as it was a bit of mess, but hey, we all do that sometimes. She tested it. Comes to review time and management love her. Me, not so much. Moral to this story: Code quality is important, very important, but being a better tester and a better dev makes you and your area work better. Management will love that.

where have I been?

2006-05-03T22:27:00.000+10:00

I really have no excuse for not posting.

Lazy? - Yep.
Too Busy? - Yep.
Other Things To Do? - Yep.

Well, I guess that's three excuses.

Anyway, what have I been up to since I last posted:
- Went to Code Camp with some guys from work - Dave, Eddie, Jenny, Richard and Paul. That was great. I got to catch up on what's over the horizon and even closer. And saw some old chums, Mitch, Geoff, Darren and more...

- I've been reading. A lot. The list since I last posted is:
"Head First Design Patterns"
"Extreme Programming Explained"
"Pragmatic Unit Testing in C# and NUnit"
"Refactoring to Patterns"
"Agile Project Management with Scrum
"The Design of Everyday Things"
"Test Driven Development in Microsoft .Net"
"Six Habits of Highly Effective Bosses"
"The On Time, On Target Manager"
And I'm in progress on:
"Design Patterns"
"Extreme Programming Adventures in C#"
"About Face 2.0: The Essentials of Interaction Design"
Almost all of them were great, some of them not so much, but generally worthwhile.

- I've been busy at work. I been dev team lead on two projects so far, both successful. It's great to get Agile process in place and see how they just work.

- I've got people at work more interested in improving their skills and lending books to anyone that is interested.

I think that's about it...

reducing the cost of change

2006-01-01T14:22:00.000+11:00

Since my last post I have decided to re-order my tenets of good coding.

The new number one is:
REDUCE THE COST OF CHANGE

All others are still very important, but this ideal is important for several reasons:
- it gives you a guiding principle to work towards
- it allows you to work faster
- it makes the politics behind business easier
- it requires most coding best practices to work

So, because of all of these points I think it's a great way to direct developers to write better code.

Let me elaborate on my points listed above:

It gives you a guiding principle to work towards
If you keep this principle in mind, the decisions required to implement functionality become clear. An example: Suppose that you need to add just one more step to a function. The easy way is to just add the code to the current function. Hmm? No, that doesn't seem right. Surely a separate function that executes the new logic that is called from the other function is a better idea. Why? Well because you have abstracted the execution of the function and if named appropriately then there's even no need for comments. As a bonus you get reuseability and testability.

It allows you to work faster
OK, another example: I was working on something that had to save data from a new application that allowed more data (30 chars) then the old (15 chars). I assumed that the business would want me to save whatever would fit in the 15 chars from the 30. So I worth a small function that did just that and called it from all appropriate places. I had also asked the business to determine exactly what had to be done. They decided that I should only save the data where it was 15 characters or less. No big issue - I just changed the one function and it all worked. As the cost of change was quite low, I was able to assume what was necessary and continue, whilst waiting for the business to decide. If I had got it right, then great, if not, then it's easy to change.

It makes the politics behind business easier
This happens to all of us - the management want the application done now and you know that to do it that quickly will compromise design. So what do you do? Implement the functionality, ensuring that you have reduced the cost of change as much as possible - that way if you need to work with the code later, it will be easy to extend.

It requires most coding best practices to work
How do you reduce the cost of change? Well, the simplest answer to that is to write small discrete functions/classes that are single purpose. Use abstraction and encapsulation to reduce coupling and allow re-use. This will also mean that your code will be more (unit) testable. I could write oodles of stuff on best practices - but there are lots of great sites/blogs out there already.

Oh - happy new year!

Less vs Simple

2005-12-09T23:00:00.000+11:00

We had a discussion the other day about whether simple is better than less. I always believe that the simpler the code, the better. To write simple code is a glorious thing. You will be praised by your successors and revered for understanding the tenets of good coding. Your peers will respect you and girls will find you attractive. Well, maybe not the girl bit, but the others will follow.

What are the tenets of good coding? (I reserve the right to change and reprioritise, based upon my current beliefs) :
1. Avoid duplication
2. Write testable functions
3. Aim for Simplicity
4. Reduce the cost of change

Now each one of these is a complete post in itself. And they require quite a bit of discussion for the intent of the statement is understood. I believe that to truly understand these guidelines you mush be switched on. The catch is that the switch is different for everyone.

A while ago I posted about an epiphany that I had. That was referring to the understanding just how important unit tests really are. It was one simple statement that a peer had said that stopped me in my tracks. I just got it. There were even more benefits than I realised at the time and further research and experience has taught me those.

From then on I always feel exposed when I'm writing functions that are not the subject of unit tests. Actually, the discussion of unit test is worthy of a complete other post as well. And covered under tenet #2.

Now you're looking for the meaty bit - the examples. Well, I'll get to those, but for now this is just something that I had to say to start the process. Soon, I'll post more on each of these topics and more.

Believe me when I say that I'm opinionated...

Oh, and if you're wondering if we won the Grand Final, mentioned in the last post, then yes we did.

stuff and things

2005-11-30T22:02:00.000+11:00

Haven't posted in a while, so I'll combine a few things in this one...

I went to the launch party tonight for VS 2005. I met a few people and can now put bodies to blogs. Frank, I'm impressed that you knew the name of my blog! I, along with Eddie and Geoff "won" copies of VS2005, SQL Server 2005 and Biztalk Server 2006. w00t! (although I don't really know what that means)

I bought Paul Mac's latest album "Panic Room" recently - it's really good. If you liked his first one, then I wholly recommend that you get it.

We had a major release last night. After a long time in development and a change in management, we got it out and apart from a few small issues, it all went well. This is part of the reason that I haven't posted in a while...

I play in an indoor cricket team on Tuesday nights. We're called "Warwick Todd VIII". We won the game last night and are now into the grand final next week. Hope we win.

We have been playing on and off (but mostly on) for about 10 years now. No, that doesn't mean that we're any good. I think that we're going to call our team "Preston's Brothers Brand" next season. I could explain it to you, but trust me you don't want to know.

I've also read a few more books recently, One Minute Manager, Fish! and am half way through Refactoring to Patterns.

Reviews:
One Minute Manager - An easy read and seems to (mostly) make sense. It was originally written in the late '70s, and the reprimand concept using emotions seems a bit dated. But what do I know. Although I agree completely with the praise and goal definition concepts.

Fish! - Nice story, but I don't think that it's that simple. Also an easy read.

Refactoring to Patterns - Very dry in places. Which is a pity. There are some great patterns in this book. The author has a great respect for Martin Fowler. I just wish he'd used his or Kent Beck's writing style. Those guys were much easier to read.

bit late, but still

2005-10-25T22:15:00.000+10:00

I have finished Test Driven Development: By Example. This is a very good book about TDD. I highly recommend that you read this one if you're interested in TDD.

rebel without a clue?

2005-09-27T22:49:00.000+10:00

I used to not want to be a geek. I wouldn't read technical books, nor technical websites. I played with computers after work, but it was just that, playing.

A little while ago, probably about the time when I started this blog, I decided that I could ignore it no longer. So I got hold of some books and started reading. And reading blogs and accepting that to be better at my job that I need to improve.

So, I've read about 6 books since then and have a stack on my shelf of about 6 more. Then I'll be onto amazon to get some more.

Why am I telling you this? Well, because I discovered just how easy and important it is to do this.

I'm realising that in the last 12 months I've learned so much and found proof that some of my crazy ideas weren't crazy. In fact, they were pretty good *blows on nails and polishes on shirt* ;)

If only I'd started this earlier...

bam! one more

2005-09-19T22:41:00.000+10:00

I have just finished "eXtreme .NET - introducing eXtreme programming techniques to .NET developers" by Dr Neil Roodyn.

It's quite a good introduction into the art of agile project methodologies.

and another one down

2005-08-08T09:48:00.000+10:00

I've just finished reading "Object Thinking" by David West. Quite an interesting read. He proposes that the true intent of OO has been misinterpreted by many and that the true path will set you free...

If anyone else has read it, I'd love a chat about it.

another one down...

2005-07-11T09:47:00.000+10:00

I just finished reading "Effective C#: 50 specific ways to improve your C#" by Bill Wagner. Definitely worth a read. Not too long, and each point is only several pages so you can just read a bit and put it away, read a bit and put it away, read a bit, and - you get the picture.

I've started Refactoring by Martin Fowler. Seems like another great book.

I really wish I'd started reading these much earlier in my career. Although I'm finding that a lot of what I'm reading I'd already picked up from other sources, but it's nice to read a comprehensive coverage of each topic.

more is more

2005-07-07T09:11:00.000+10:00

We've recently had seven people join our team. We recently only had 5 full time developers in our team, so that's a big increase (sure, I could have worked it out as a percentage, but you can do that in your spare time).

The change has been great, I always like meeting new developers to get their perspective on how they approach their work.

It also gives us the chance to do stuff we've been too busy to do - like more pair programming.

Welcome to Richard, Michael, David, Kyle, Mark, Goran and Andrew.

less is more...

2005-07-07T09:05:00.000+10:00

I've been reading/watching/thinking about this recently. Everyone's saying less code is better and I agree. The less code, the less chance for bugs, the less the program has to do and the less code paths makes the code more robust.

Now the art of writing less code is easy - understand exactly what is required and implement it the simplest way possible. Also, avoid duplication of code or functionality like the plague and you're on the way.

Get on board and write less!

swimming upstream

2005-07-01T08:14:00.000+10:00

Anyone with experience (or knowledge, Mitch ) will know that the more time you spend on upstream tasks will pay large dividends further into the product cycle.

I know there's no easily identifiable point when you know you've done enough analysis and design, but it's better to overspend in this area then suffer the consequences later.

It's amazing how just one extra class or one decision can save hours (or weeks!) of work.

You're never going to get it completely right, as the details are never immediately obvious. But that's no excuse not to try.

Right now, I'm doing a bit of swimming upstream...

Object Orientated Design (OOD).

2005-05-26T14:09:00.000+10:00

OK, I am a big fan of OOD. Why? Well, it makes your life easier. Yes, it can be a bit harder to understand and grasp what's actually going on, but the payoffs are immense. Once you get into the concepts, you really see how it's just logical.

If you want to know more, read http://blog.objectmentor.com/ArticleS.UncleBob.PrinciplesOfObjectOrientedDesign

Please.

Epiphany

2005-05-18T13:33:00.000+10:00

Epiphany: the comprehension of the meaning of something through a sudden intuitive realization.

Had one just the other day.

It's strange. You read something and go "yeah, that's good." And you acknowledge that it's something that you "should" do, but you don't.

And then, some time later, you're discussing it with someone else, thinking about it in the shower or the realization just pops into your head from your subconscious. And you just suddenly get it. A total and utter understanding of WHY you should do it.

Wow.

best book ever

2005-05-13T15:22:00.000+10:00

No, I'm not going to tell you that the best book ever is "The Davinci Code". It's good, but not that good.

What I am going to say is that the best book ever is "Code Complete 2" by Steve McConnell. If you're a developer (or even just someone involved in the whole IT industry), then please, do yourself a favour and read this book.

'Nuff Said.

Process, Process, Process

2005-05-12T10:53:00.000+10:00

Sorry. I should have made this more obvious in my last post. I do think that process is important. Very important. I would have to say that I prefer Agile type processes to waterfall for a few reasons:
- it helps you identify progress and problems early and frequently
- it accepts what IS going to happen and embraces it (i.e. iterations)
- more team focused and skilling orientated.

That's not to say that you can't do all that in a waterfall project. Infact, I bet that the waterfall projects that are classified as successfull actually implemented those points, but not in a formal fashion.

wondering

2005-05-06T09:29:00.000+10:00

There's so much talk around at the moment about how many projects are failing and the quality of the result when they do succeed.

The main thing that industry experts suggest is that the issue is the process. I.E. Waterfall projects tend to fail and XP projects do not.

Hmmm.....

salt and vinegar chips

2005-04-07T08:35:00.000+10:00

Seems there's a new player in the almost full to bursting point salt and vinegar chips market. Arnott's have been advertising their "Tasty Jacks". They say that if you try them you'll never go back.

Well I did, and although they're pretty good, I'd say that they come in at #3 on my list. So what's my list? Glad you asked:

#1: Kettle Sea Salt and Basalmic Vinegar. Fantastic!
#2: Smiths Salt and Vinegar crisps. The thin slices really add to the enjoyment
#3: Arnotts Tasty Jacks Salt and Vinegar. Great attempt, but can't quite match the taste of #1 or #2.
#4: Smiths ridged Salt and Vinegar. Good regular chips.
#5: Pringles Salt and Vinegar. Ok.
#6: any other brand. No one really cares at this level.

I also have very fond memories of a chip called the BIG Salt and Vinegar. I think that they were only available in about 1985. Probably because the flavour was so strong and the chip so thick that several children were admitted to hospital with salt and vinegar flavour poisoning.

Anyway...