energised

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!

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

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

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

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

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?

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?

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

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

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?

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