Installing a Microsoft .NET assembly into the GAC used to be fairly trivial. Unfortunately, I just spent some frustrating time learning that things have changed quite a bit with .NET 4.

I began with my .NET 4 assembly and tried to install it via the usual approach, dragging and dropping it into the %windir%\assembly folder via the Explorer shell extension. Strange; nothing happened.

A quick search revealed that for .NET 4, Microsoft, for reasons which do not seem to be well documented, have created a new GAC location, in the %windir%\Microsoft.NET folder.

Well, that was annoying, I thought: but I could deal with it. I tried dropping the file into the new GAC folder… but there is no nice Explorer shell extension for the new GAC. Doh! (for the second time)

Ok, time to drop to the command line and fire up good ol’ gacutil.exe.

FAIL

I received this error message:
“Failure adding assembly to the cache: This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.”

Sigh. Ok, I thought, I’ll just use the .NET 4 version of gacutil.exe. After a quick search of my PC I learned that it’s not installed with Version 4 of framework, nor with Visual Studio 10.

Yet another brick wall! But no worries – I would just download it. I found out via Matt Whetton’s Blog that I needed to download Microsoft Windows SDK for Windows 7 and .NET Framework 4 to get it, so I did (while wondering why I need to download that whole SDK to get gacutil??)

So then I found gacutil in the bin folder of the SDK and I ran it. Arrgh, it returned the same error message again!

Eventually I found the .NET 4 version of GACUtil in the SDK – it’s nestled in
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools.

Sigh. Could Microsoft really make things any more difficult? I just wanted to install an assembly into the GAC!

By the way, if you need to copy gacutil onto a server, you will need to copy the following files to it: gacutil.exe, gacutil.exe.config and gacutlrc.dll (the last one located in the 1033 sub folder containing gacutil).

We’ve all been there: code that hurts your brain to look at, let alone comprehend.

Not written by you, of course. You wouldn’t write a mess like that, and you can hardly believe that somebody else did (or maybe you can…?)

Your mind wanders to who to blame for this abomination before your eyes. You start complaining to the person sitting next to you. Then to your boss. Then you decide that it’s time for a coffee and then to browse for new jobs.

Sound familiar? I bet it does!

The difference between an average programmer and a good one is in what you do next.

Do you ignore it and try to forget you ever saw it, or do you attempt to improve it?

I have a simple rule that I like to follow: I always try to leave the code in a better state than I found it.

This might involve small improvements, like improving code formatting, renaming methods or variables, or adding useful comments. Tiny improvements add up over time, especially if the whole team is doing the same thing!

Or the improvement could be larger, like refactoring or adding test coverage.

Yes, this can take time, and yes you do have that deadline to consider. But it’s amazing how quickly small improvements can be done; certainly in much less time than it took to understand that grotesque code. Which means that your improvement might make it much quicker for the next person to understand – and that next person might be you, when you revisit it in a year’s time…

The important thing is to do it, and encourage your whole team to do it. Don’t be afraid to change things. Take responsibility for that code, even if you didn’t write it: embrace collective code ownership!

I recently had the opportunity to hear Jean Tabaka, Agile Coach from Rally Software, speak in Brisbane at Yow! Nights about The 12 Failure Modes of Agile.

Jean has been consulting as an Agile coach for many years, so it was really thought-provoking to hear her top reasons of why the adoption of Agile might fail.

I thought I’d repeat the list on my blog for my readers because I think it’s a great compilation of potential pitfalls we should all work hard to avoid. Perhaps we could call them “Agile anti-patterns”!

The 12 Failure Modes of Agile (from Jean Tabaka)

1. “Checkbook commitment”

This refers to when people are saying they’re doing “Agile”, but without actually committing to it. They expect immediate results, and they use the same old organisational structure and metrics.

2. Culture that doesn’t support change

If the company culture is resistant to change, how can it adopt a methodology that embraces it? An example of this would be a culture where people are rewarded for not “rocking the boat”.

3. Ineffective use of retrospectives

Retrospectives must be done and handled effectively. The feedback gained via retrospectives must be learned from and acted upon. The whole team must be responsible for the actions from the retrospective, not just the scrum master.

4. Ignore needed infrastructure

For example, for a team to do Continuous Integration, it needs access to a build server!

5. Lack of full planning participation

The whole team needs to participate in planning and, as a team, commit to the work defined for the iteration.

6. Unavailable (or too many) product owners

Product owners are busy, but it is a warning sign when they say “we’re too busy for all this communicating”. Also, if there are too many product owners, it can be hard to get agreement.

Jean raised an intriguing question here: she asked how many people in the audience had done some form of Agile training. Many hands went up. Then she asked, how many people had worked with product owners who have been trained in Agile? I don’t think anybody raised their hand…

7. Bad scrum masters

The team needs to collaborate well within each iteration, and a poor scrum master can be harmful to the team’s morale and productivity. An example of a bad scrum master is one that plans all the work, puts it in a tool and then tells people to do it.

Jean made the point that if you take over the decisions for others you lower morale (and IQ’s!). Scrum masters should not control, they should empower.

8. Not having an onsite evangelist

This point is particularly important for distributed teams, or teams in branch offices. Without an Agile evangelist/coach onsite, the remote team can lose its way.

9. Team lacks authority/decision making ability

Agile is not about control, it is about empowerment.

10. Testing not pulled forward

Testing should be done up front, ideally, or else as soon as possible. Testing should also be automated.

11. Traditional performance appraisals

Traditionally, performance appraisals reward individual performance. In an Agile environment, the focus is on team performance, not individual heroics, and appraisals should reflect this.

Performance evaluations should also be regular, not once per year.

12. Change is hard, Agile is blamed

For example: an Agile methodology is introduced to solve a company’s problems. It fails, and Agile is blamed rather than the company’s own, deeper problems. It is often easier to look outwards and assign blame rather than to look inwards.

Recently I attended a session of the Brisbane Agile Academy Meetup Group (which I highly recommend, and not just for the free pizza!) chaired by Craig Smith, on Using Agile for Non-Development Projects.

I must admit have a special interest in this idea: ever since I began using Agile for software development I have fantasised about its potential for non-development projects. I used it to partly plan my recent round the world trip. A former colleague of mine was using it to plan his wedding. If it works for a software team, it could work elsewhere… right?

But it’s never quite that easy, is it? It can be difficult to get buy-in for an Agile process in a development team, depending on the level of management support and developer engagement. Imagine how much harder it must be to get momentum in an environment or industry that may not have even heard of Agile!

Having these doubts in mind, the session was a real eye-opener for me. I was introduced to real people working in corporate teams using Agile for non-software projects.

Some examples I have discovered:

• The bank, Suncorp is using Agile for finance and procurement teams, with an Agile coach from software development background, and by mapping Agile onto standard processes
• The telecommunications company Telstra is applying Agile while providing external services to Suncorp, integrating with Suncorp’s preferred business service methodology
• Lonely Planet’s team of in-house lawyers is now using Agile to plan their work load and ensure priority items are done on time (Beverley Head in Agile Today, May 2011)
• AccuRev trained their whole sales team in Certified Scrum Training and adopted a quarterly iteration period, aligning with their sales cycle

I am looking forward to watching this trend continue.

Perhaps it might become the silver bullet to unlock the next wave of productivity growth for teams of knowledge workers. Or maybe lots of story boards will just end up getting thrown off rooftops!

What do you think? Do you know of any other examples of Agile being used in non development environments?

I like to see the process of managing email as a little like gardening. You need to prune the plants and keep on top of the weeds. If you get it right, you end up with a beautifully manicured garden. If you don’t, you just end up with an overgrown backyard full of weeds!

Japanese garden (Randy Robertson)

With this thought in mind (perhaps I’m a little too enthusiastic about spring?), today I took the challenge of greatly simplifying my Inbox, based on one simple principle: does this item need my immediate attention?

To do this, I used the advanced features that Gmail offers to handle a lot of the ‘email gardening’ for us!

I started with the low-hanging fruit: the Priority Inbox feature.

Turn on the Priority Inbox feature

The Priority Inbox feature is brilliant. It means that Gmail will automatically determine which items it thinks are important and which ones aren’t, and then shows you the priority ones at the top of the page. You can train it to teach it what you view as important and what isn’t.

You may ask, what about the items that the Priority Inbox feature doesn’t deem as “important”? I’m talking about dozens of emails every day: newsletters, notifications, bookings; as well anything important that Priority Inbox might have missed (it’s not perfect, after all!)

It would be helpful to be able to categorise all these emails, wouldn’t it? I did this by using Gmail labels.

Create labels

Labels are a very powerful Gmail feature: they allow you to classify and thereby group your emails. Think of it as an array of virtual flower boxes, organised by type of flower.

For example, I have a label called Newsletter, in which I like to group any subscriptions that I don’t need to read straight away. Later, I can read them by clicking on the Newsletter folder that Gmail creates for me the left-hand side of the Inbox.

Gmail Label

I created more labels, for example, one called Facebook, for Facebook notifications. Some people have said “just stop forwarding the notifications to your email account!“. But it’s often quicker to read them as email. It also means that I don’t need to log into Facebook, which as many of us might know, can be very distracting!

Create filters

I took the label idea one step further: I used Gmail filters to let it do the work for me. Filters are another powerful feature and are used to automatically process your emails for you as soon as they arrive. It’s like having a gardener to tend to your plants for you while you’re out shopping.

So I created the filter “all emails from Facebook should be removed from the Inbox and assigned a label of Facebook“. (Another example of a filter would be, “all emails from Brendan should automatically deleted.“)

Creating a filter in Gmail

I applied a similar process for labels and filters for notifications from Twitter, LinkedIn and so on.

Process remaining emails

At this stage the groundwork has been done for an automated email-management process. The flower boxes (labels) had been set up and the Gmail gardeners (filters) had been told what to do.

I then took my Everything Else folder and went through the remaining emails, the ones that were not classified as Priority. (At this stage I had around a thousand items in this folder!)

For each email, I applied a simple process:

1. Is this item spam?
   If yes, click on the Gmail Mark as Spam button. I find that with this feature I very rarely receive spam in my Gmail account.
2. Is this an email one that I DO NOT want to receive ever again?
   If yes, unsubscribe and/or create a filter to automatically delete items from that address in future. (For example, a mass marketing email.)
3. Is this an important item which needs to be read/processed?
   If so, click on the Mark as Important button to tell Gmail to mark emails like this one as important in future. Also click the Star icon to mark the item for later processing. (For example, an email from my Dad.)
4. Is this email one that could be archived automatically in future?
   If yes, create a filter such that any emails in the future from this address are removed from the inbox and assigned a label. (For example, all hostel booking notifications from HostelBooker can be archived and assigned the TravelBooking label.)
5. Anything else, either click on Archive or Delete as required.

The Result

INBOX ZERO!

What does that really mean? It means I have no emails in my Inbox that are unprocessed. Every email is in its logical place: either assigned a label for reference, or marked with star so I can deal with it later. I also have a large set of new filters to automatically process items in the future.

Is there more work to do?

Yes. I still have to go through and process the starred items. But now I know exactly how many of those there are, and as a constant reminder, I will see them every time I log in at the top of the page.

Was it worth it?

Overall, the process probably took me couple of hours to do. It was a profitable investment of my time: in future I will spend more time responding to important email and less time managing unimportant email.

In a slightly geeky way I also kind of like the feeling that my inbox is being constantly monitored by a robot that will filter the emails for me. That means less work for me.

On the other hand, I also know that I will need to be vigilant in applying this process regularly. I will need to keep creating new filters/labels to keep those pesky weeds under control.

Ok, enough about email. Now it’s time to go and have a cold drink in that garden!

“What we can or cannot do, what we consider possible or impossible, is rarely a function of our true capability. It is more likely a function of our beliefs about who we are.” Tony Robbins

A few years back I was telling one of my former colleagues about a new technique I’d discovered and had been using for a little while: test driven development (TDD). I was full of enthusiasm for this, at the time to me, new technique.

His first question to me surprised me a little: “yes, but is it as fulfilling”?

I was initially unsure how to answer, but said something like yes, that I felt a lot more productive and seemed to spend a lot more time writing code.

After much time spent coding in different TDD environments and after more time to reflect, I can now say for certain that yes, it is more fulfilling.

Let’s consider for a minute to the situation prior to TDD:

With TDD I enjoy the feeling of being much more confident both in the code I write, and in the code base itself, because it is covered by tests. I like that I can fix bugs or refactor with confidence, knowing that I can run tests to ensure I haven’t broken anything. And that an automated build will also run tests after every check in. And that my team is doing the same.

I like that I can write a test to reproduce a bug, and then write the production code to fix the bug. And then run all tests to make sure that I haven’t broken anything elsewhere.

I like that I don’t have to waste as much time stepping through code in the debugger.

I like that I can go home at night, knowing that all my code has been integrated successfully and that all tests have passed.

The resulting code base produced is better quality, and bugs can be fixed with more confidence.

I know that all of the above is only as good as the quality of the tests and of their code coverage. But that’s what being a pragmatic programmer is about; and it’s still a huge leap forwards from the previous situation.

Feels pretty fulfilling to me!

I am currently reading The Art of Unit Testing by Roy Osherove. He recommends the following naming convention for tests:
[MethodUnderTest]_[Scenario]_[ExpectedBehaviour]

Which I am glad is similar to that which I’ve adopted in the past:
[MethodUnderTest]_Should[ExpectedBehaviour]_When[Scenario]

I think the latter makes for easier reading. Though I admit that the convention recommended by Roy makes for easier ordering/categorising of tests by scenario.

Whichever method is chosen, I think it’s important that the same standard is adopted by the whole team.

I’ve been on the road in South America for nearly 2 months now. Actually, I’ve found it surprisingly difficult to find time to read whilst travelling (excluding travel guides!). Most of my time has been taken up by travel experiences, organising, and the inevitable socialising. But for better or for worse, the long bus journeys in South America have proven to be the saviour of my reading.

This is what I’ve read so far:

Ancient Futures: Learning from Ladakh

by Helena Norberg-Hodge
This must be the quintessential travel book. It’s the story of the Leh tribe in the Ladakh area in the Kashmir region of northern India, which was documented over 16 years by Norberg-Hodge. She made extraordinary efforts to get to know the people and their culture, which included learning their language, and she watched the impact as they went from minimal contact/trade with the outside world, to mass tourism and western-style development. The book raises real questions about the nature of western-style progress, especially regarding life satisfaction and happiness. Everyone should read this book.

Crucial Confrontations: Tools for Resolving broken promises, violated expectations, and bad behavior

by Kerry Patterson, Joseph Grenny), Ron Mcmillan, Al Switzler
This is a book all about how to safely confront people… you know, what most of us try to avoid doing, because it’s usually easier to avoid, and/or because most of us do it poorly. The book offers a lot of great, practical advice with plenty of examples. Everyone should read this book.

Underground: Tales of Hacking, Madness, and Obsession on the Electronic Frontier

by Suelette Dreyfus with research by Julian Assange
This is a book co-authored/researched in the late 90′s by Julian Assange, of Wikileaks fame. I found out about it when researching Assange’s background; it’s a book about the underground hacking scene in the early 90′s, which he was involved in. The book is meticulously researched and brought back a lot of memories for me of the computer scene that existed back then, a time when as a 15 year old I could think of nothing more fun then messing around on my Commodore Amiga 500 (why didn’t someone tell me?!). Fittingly, this was the first book I read on my Kindle. (Not everyone should read this book.)

How To Win Any Argument: Without Raising Your Voice, Losing Your Cool, Or Coming To Blows

by Robert Mayer
My friends may find this amusing given how much I love a good, err, discussion, but the book isn’t exactly as one would expect from the title. It’s about how to put forward persuasive arguments, either in writing or verbally. It covers subject matter such as the techniques used in marketing and politics: very useful if you want to learn how to build a case using techniques that professionals use, and/or further understand how products are marketed to us and how politicians manage to win us over!

30 Sentences For A Millionaire Mindset

by Dragos Roua
This book was recommended to me by a former colleague of mine, and I also read it on the Kindle. Firstly, this isn’t one of those <groan> “how to become a millionaire” type of books. It’s more a set of rules for a successful and healthy mind-set, with details on how to action change, if required. A lot of the rules are just common sense and some are down-right simplistic, but some are really inspiring. One might suppose this book could be opposite to the ideas presented in Ancient Futures (mentioned above)… I would say, diplomatically, yes and no… 30 Sentences, to me, seemed mostly about how to avoid common traps in a Western, consumer society which are to the detriment of your well-being, and instead to seize back your time and money and use the system to your advantage.

The Intelligent Investor: The Definitive Book on Value Investing

by Benjamin Graham
(Reading right now). As the title might give away, this book is THE classic book for value investing, written by Benjamin Graham, the mentor to billionaire investor Warren Buffet. Everyone who wants to be a successful investor should probably read this book. I must admit, it’s a little dry to read while travelling, though…

HoPE is a very nice WordPress theme by Patrick that I’m currently using for a travel blog.

I’ve found two minor niggles with Version 2.5.8 so far: the theme doesn’t display italics, bullet points for unordered lists or numbers for ordered lists. The fix is quite simple (just to return the styles to their defaults) but I thought I’d post the stylesheet fixes in case anybody else has the same problem:

1. Edit the style.css file. You can do this via your WordPress admin interface by clicking on the menu item Appearance->Editor, then choosing the style.css file
2. Search for

   i, em, dfn, .fn, cite{font-style:normal;}

   and replace with

   i, em, dfn, .fn, cite{font-style:italic;}

3. Search for

   .entry-content ul{list-style-type:none;}

   and replace with

   .entry-content ul{list-style-type:disc;}

4. Search for

   .entry-content ol{list-style-type:none;}

   and replace with

   .entry-content ol{list-style-type:decimal;}

5. Update the file
6. View your website again (don’t forget to click refresh your browser to clear the cache)