attitude?

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

to all...

how many books?

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

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#

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!

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

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

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

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

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!

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

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!

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

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

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

reducing the cost of change

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!