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