my opinion

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

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

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

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

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

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

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

website vs phone

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

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

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

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

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

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

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

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

Silly, really.

something to do...

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

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

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

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

He agreed with me. This would be useful.

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

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

fantastic

I tasked a team member with solving a problem today.

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

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

Fantastic!

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

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

peer reviews

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

safety

Consider the following SQL:

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

This could be written with parameters as follows:

SELECT title FROM books WHERE isbn = :isbn_value;

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

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

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

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

Consider this SQL statement:

SELECT first_name FROM employees WHERE last_name = :LastName_Value;

In this statement, the :LastName_Value is the parameter.

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

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

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

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

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

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

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

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

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

communication, coupling and stuff...

You may have noticed that I like reading technical books.

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

But I think that there's a better way.

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

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

So as an example we could talk about coupling.

Loose coupling is good, right? Depends.

Lets use buses and trucks as an example.

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

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

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

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

follow up on the estimates post

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

three things I like

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

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

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

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

efficiency

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

Only do what's really important.

Sounds too simple?

Let me explain:

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

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

Seems innocent enough.

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

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

estimation - aaarrrggghhh!!!

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

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

Yes - that ever present issue.

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

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

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

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


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

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

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

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


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

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

What do you do?

"patterns of enterprise application architecture"

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

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

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

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

"design by contract, by example"

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

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

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

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