Owen's Blog

I’m trying to find a nice weblog editor for the mac and MarsEdit seems to be the final one to test after Ecto fails to post to subtext properly. I’ll add an image too:

Yep that’s me trying to avoid the camera at the wellington agile bar camp last week

Well I know, I missed a post on Friday, I’m sure someone was holding out for it but it never came.

Truth is I realised that a post a day is probably unrealistic and instead I’m just going to aim for at least a post a week, hopefully more.

However I still have to find things to write about, and as such I’m going to hold out till I have played around with the new ASP MVC framework which just had a preview release. I’m looking forward to see how it compares with monorail and see what I can swap in and out.

I’ve recently been working on a project trying to use xUnit.net and I’m really pleasantly surprised by one thing…. the change in vocabulary. No longer do we have tests we have facts. It may seem to some that this change means very little (Apart from making it really hard to swap out xUnit.net and put in Nunit or mbUnit which both use a common syntax to mark a test. However to me it comes down to how the act of unit testing is interpreted, rather than stating a test about the whole system we are combining our unit tests into a set of hypothesis and proofs around how the system works, which when executed help us to determine a level of confidence over how well our software helps achieve certain goals.

Phil Haack has had a recent number of posts about some of the misconceptions about what unit testing achieves

But also recently with my unit testing I’ve been put into new teams and worked with colleagues who I’ve never had the pleasure of working with…. now not too long ago I was merrily coding away when one of them noticed my (liberal) use of the RhinoMocks framework and blankly stated that he never used mocks and didn’t really like them.

I suddenly realised that I’ve become a very mockist developer. Let me explain, there are two camps when it comes to mock frameworks, those who use them (mockists) and those who don’t (classicists) Now I’m firmly in the mockist camp, and my whole work pattern has revolved around them, I will often code to interfaces by default and do the very minimum possible to get a function working with mocks, I find it really helps me to focus on the unit in question without having to fill out every single layer to test every permutation of circumstances.

I will code a test for a method, start to write the code, and using Dependency Injection work out what pieces of data should be coming from other layers and use mocks to achieve this. There is one caveat, the tests don’t cover end to end functionality so there is a danger that maybe the tests really don’t cover real life scenarios, however I would hope that I would get this kind of coverage from my front end WatIn or Fit tests. So speed and focus are why I’m firmly in the mockist camp, however I do wish I could do something like this.

TDD, Agile}

Technorati Tags: Agile, mockist, RhinoMocks, tdd, xUnit.net

In every profession there is the middle ground and I’ve yet to work out an example of where the middle ground is a good thing.

Politics is possibly the best example of where the middle ground flourishes. In order to appeal to the most voters possible, political parties try and “capture the middle ground”, growing up in Britain this was none more apparent than the New Labor movement that swept to power by shedding there left leaning policies and focusing whole heartedly on the middle ground.

And this is not a good thing?

I guess it depends on what angle you come from, if as a politician you wish to be voted for I guess you do have to appeal to the middle “swing vote”. However, it takes principles and belief to really form change, by appealing to the middle ground you’ll inherently take no action or maintain a status quo. By taking a side however your principal can drive real change and satisfaction (although admittedly not from all)

As software developers we have to be really careful not to take the middle path, the path of least resistance. Instead we should have opinionated solutions that rather than pander to the masses and fail at each step, side with a select bunch and really satisfy them. The benefit of software over politics is once we’ve created a solution that sufficiently caters for one group, we can create another solution for the polar opposite group without encroaching on the firsts opinions.

That is the beauty and the danger of software.

Blogged with Flock

Tags: Middleground

Throughout my adult and formative years I have set myself a number of goals as I’ve progressed. As human beings goals can be incredibly powerful to our psyche whether long term goals such as career prospects or short term such as getting home at night they play a powerful role in our life.

As software developers the realization of goals is the most powerful tool in our arsenal. And the realization that Goals matter beyond most other aspects gives a new freedom and purpose to the software we write. A lot of our concerns become superfluous once we start focusing on specific goals of the users. Alan Cooper popularized this with his Goal-Directed Design in books such as The Inmates are running the asylum and About Face (both of which I advise a read of)

“User goals serve as a lens through which designers must consider the functions of a product.”

Other techniques are also at our disposal to help ratify goals. For example I view Behavior/Test Driven Development as Goal orientated design in the small. Each test defining a small part of the users goal, and introducing the specification for a software goal (which IMHO is also a goal worth considering)

Goals must become the first and only true test of a products and functions merit, without ratifying against concrete goals we are chasing an elusive deam and doing no better than sticking our finger in the wind.

Luckily we and the user are chasing the same goals, we are on the same side.

Tags: Goal Directed Design, TDD, BDD, Goals

December is upon us and I’ve decided to actively try and increase the amount of posts I make to my blog, trying to pick up interesting and diverse topics and actively writing 1 article every Monday to Friday, I’m not sure how well I’ll stick to it but it’s worth a try.

I’ve recently realised it’s nearly a year since I left my job in the UK and decided to travel all the way round the world to work in New Zealand. Assessing the work I’ve done since then I’m not 100% happy, I seem to have slipped into the inevitable comfort zone, and not even realised it.

The comfort zone is something that really scares me, it’s the place where I go from an active member of the development community to JAD (Just Another Developer). I can’t remember the last time I actively tried to push my own boundaries and worked on something I had no clue how to do, and actively learned. I also seem to be way to comfortable to just accept problems with the software I’m working on as inevitable and don’t actively try and fix up problems such as tight coupling, low cohesion and other elements that make my job difficult on a day to day basis. Instead I seem to have let it was over me, slowly dipping my foot into the pool of the dreaded 80% unreachable people.

http://blog.red-bean.com/sussman/?p=79

I have to agree with Jeff Atwood that this group scares me, not the individuals, just the apathy of the group. However I’ve started to become one of those people. So from this day forward for the next year I’m going to try and take myself out of my comfort zone. I’m tempted to resurrect my old pet project NFitnesse again, although I’m no longer sold on the Fitnesse Idea, I’ve found it quite hard to gain traction in an existing environment.

I’m also determined to get everyone around me evangelising Test driven and behaviour driven development, and really going to try and finish some technical books that have sat on my shelf for a bit too long.

The comfort zone should be something we are all scared of, don’t let it take you.