Andy Hitchman

More Auto-projecting LINQ queries

Sun, 13 Feb 2011 22:14:00 +1100

Jimmy Bogard has a great post about projecting LINQ queries to view models.

My team was having the exact same conversation even as his post was sitting unread in Google Reader.

Out domain is rich with value objects which are designed to be rendered on the presentation layer via MVC EditorTemplates. This makes AutoMapper (another of Jimmy’s innovations) a little difficult to fit into our approach.

Jimmy’s alternative approach is exactly what I imagined we’d be writing shortly.

We quickly found the need to override the basic binding and have published some enhancements at https://gist.github.com/824585 that provide a simple override DSL.

Please use and improve!

Import Your Delicious Bookmarks into Google Bookmarks

Fri, 17 Dec 2010 17:40:00 +1100

As it looks like Yahoo! are shutting down Delicious, I needed to get my bookmarks (with tags intact) into a new social bookmarking tool. I chose Google Bookmarks (www.google.com/Bookmarks) as I already have a google account.

Exporting from Delicious is easy, but importing to Google Bookmarks is not.

So I knocked up a basic bookmarklet to do the job. Please try it out and let me know if you have any problems:

http://andyhitchman.github.com/DeliciousToGoogleBookmarks/

getKanban

Wed, 25 Aug 2010 08:57:52 +1000

I went to the 'Limited WIP Society' meetup last night to play the getKanban game. Russell Healy ran the session and it was great to get to talk with him about kanban.

But the highlight of the evening was definitely the game! It taught me a lot about the formal application of kanban systems. I’ve understood and applied the concepts of kanban on projects previously, but the game excels at teaching you how to measure and control work in process and optimise flow.

The game has not officially launched yet, so it was nice have the opportunity to test out a preview version and offer a little bit of feedback. If you get a chance to play, I’d recommend the experience.

Delivery Responsibility on Agile Projects

Tue, 17 Aug 2010 15:49:00 +1000

I had a great chat with a friend and colleague, Tom McDermott, over a coffee this morning that culminated in a little ‘Eureka!’ moment (at least for me).

We started talking about the somewhat tenuous role of business analysts on agile projects, where collaboration and communication directly between the business and developers is necessary to ensure success.

But complex project often need analysts, distinct from developers, and the larger the project the more likely this type of team structure will evolve.

The conversation then drifted into how testing should be performed and the significance of the quality assurance role, as opposed to the traditional waterfall tester role. That got us talking about Feature Injection (read the comic strip by Chris Matts: Episodes 1, 2, 3 & 4 and Liz Keogh’s Pulling Power article) and the risk of late information arrival from QA activities into development (which is a clever way of saying “bugs”).

In a Kanban system we pull requests for work and push back the finished article. In the exemplar (the Toyota Production System) a customer requests a car, which causes a flow of requests into the system and the parts being manufactured and assembled in the return path out of the system (yes this is gross simplification, bear with me).

So how does this relate to agile or lean software development? Well, the customer requests features which flow into the system to be pulled by developers who build and then return working software.

Teams often have information radiations in the war room, say a couple of whiteboards or a window, covered in cards or sticky notes that represent the requests for work: stories, features, MMFs, or however you work. These stories typically travel left-to-right thought swim lanes, or queues.

This works, but my observation to Tom was that the concept of pulling the request and pushing the result symmetrically (into and then out of the system) is missing. We have a linear system that promotes fine-grained analysis, build, test in that order, and consequently suffers from the late arrival of information into development from QA (those pesky bugs).

Surely that isn’t right?

So what might be better? Well we have a customer who is requesting features and a developer who is pushing bits. In the linear system we have a business analyst on the inflow and quality assurance on the outflow.

The developer is responsible for “build”. What is analysis and QA really doing? So Tom and I popped the why stack and found the answer is “delivery”.

Who is responsible for “delivery”? Well it’s a value chain, so who ever is connected to the customer is the right answer. But in our linear system there are two roles connected to the customer. Does that make the tester (on the outflow) responsible for delivery? That seems a bit harsh, given that they are simply assuring that the bits match the requirements. They didn’t define the requirements; that was the job of the analyst. The analyst? Better, I would suggest, as they defined the requirements in our linear flow. But they typically aren’t really involved in the outflow of bits.

Ah ha! The analyst should be responsible for the return of bits to the customer! That’s “delivery!”. So how do the analyst and QA collaborate? Well, maybe the analyst and the tester performing QA should be the same role?

Ah ha! Symmetry.

Now, just to be clear, I’m not suggesting this replaces collaboration and communication. I’m suggesting that the BA and QA role should be changed to a “Deliverer” role.

The Deliverer pulls requests for features and triggers discovery. They ensure the quality of acceptance criteria on features/stories and act as the keeper of truth for a feature. They pull working changesets and perform the quality assurance on these. They have the responsibility of delivering valuable working software to the customer.

That was my Eureka moment. What do you think?

Walking on water

Thu, 12 Aug 2010 15:23:39 +1000

Successfully developing software from a written specification is rather like walking on water: Easy if frozen, miraculous otherwise.

"If you want to build a ship, don’t drum up the men to gather wood, divide the work and give..."

Mon, 09 Aug 2010 10:00:00 +1000

“If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea.”

- Antoine de Saint Exupéry

"A project creates business value when it increases or protects revenue, or reduces costs in..."

Sun, 08 Aug 2010 10:00:00 +1000

“A project creates business value when it increases or protects revenue, or reduces costs in alignment with the strategy of the organization.”

- Andy Poll

ASP.NET MVC 3 preview 1!

Fri, 06 Aug 2010 21:33:22 +1000

Just installing ASP.NET MVC 3 preview 1. Quite excited to try out the new Razor view engine

Martin Fowler speaking at Agile Melbourne

Fri, 06 Aug 2010 11:43:00 +1000

Looking forward to hearing Martin Fowler speak at the next Agile Melbourne meetup (http://www.meetup.com/Agile-Alliance-Melbourne/calendar/14300519/).

Being Geek: The Software Developer's Handbook

Thu, 05 Aug 2010 13:02:00 +1000

Being Geek: The Software Developer’s Career Handbook (http://www.amazon.com/Being-Geek-Software-Developers-Handbook/dp/0596155409) by Michael Lopp, perhaps best known for his blog http://www.randsinrepose.com/, is an essential read for any dedicated developer.

Learn how to work effectively in the organisation around you, learn to recognise different personalities and how people react to stress, learn to manage upwards and understand team dynamics.

Lots of “management manuals” could tell us how to do these things, but these aren’t the right kind of books for someone with an engineering mindset. “Being Geek” tells us how to work with the non-Geeks around us without imploding.

Structured as a series of discrete essays, it’s easily digestible and resonates strongly with my experiences. No doubt it shall become one of works that I revisit frequently to re-affirm my place in the IT world.

Estimates are not deadlines

Thu, 29 Jul 2010 09:51:00 +1000

If we strive to always develop software in less time that our estimates, we risk engendering a culture of compromise. And the easiest path of compromise is going to be quality.

The focus on hitting a larger milestone is legitimate, but I don’t believe it necessarily translates into every task estimate being met.

Given the number of forces at work during software development, I believe it would be statistically improbable for all estimates to be met.

Perhaps we should sometimes willingly exceed our estimates and get it right, rather than flog ourselves working silly hours and still deliver substandard code.

It’s not a race. And by retaining our integrity and seeing the whole picture, I imagine that the overall milestone would still be achievable.

Test Syntax Highlighting

Tue, 27 Apr 2010 15:17:16 +1000

    
    public class Segment : ISegment 
    {
        private readonly IPartitioningStrategy partitioningStrategy;

        public Segment(IPartitioningStrategy partitioningStrategy, int segmentNumber)
        {
            this.partitioningStrategy = partitioningStrategy;
            SegmentNumber = segmentNumber;
        }

        public int SegmentNumber { get; private set; }

        public IPartition MappedPartition
        {
            get { throw new NotImplementedException(); }
        }

        public bool IsResponsibleForGraph(Guid internalId)
        {
            return partitioningStrategy.IsResponsibleForGraph(this, internalId);
        }
    }