Random Code

I’m tired of hearing and reading about organisations that are “agile” when I know they aren’t.  Agile is the trendy new (old) thing, and as Janusz Gorycki points out so well in his post titled Agile is Dead, the main reason we have AINO ( agile in name only ) is PHBs.

I’m propose we create a new agile methodology, one that takes from scrum and xp and lean and provides a loose framework of guidelines designed to be used by competent professionals rather than talked about by PHBs and certificate hungry consultants.

To ensure managers don’t want to be known for having implemented this new methodology, I propose we call it

“Getting Shit Done”

How many PHBs want to front up to their bosses and explain they need to spend money on “getting shit done” – it’s what they are paid to do anyway, isn’t it?

To drive away the money grubbing courseware consultants, the methodology should be simple and the first rule of this new methodology should be:

You can’t teach getting shit done, you can only learn it

Now if it were only as simple to do as it is to write

It works!  I’ve still got a lot of work to do to clean things up and look at getting it patched into the codeplex source, but this screenshot below shows the ReSharper test runner executing tests using a custom ITestClassCommand.  If you need it right now, post a comment below otherwise I will try and get something sorted in the next couple of weeks.

… or mistake proofing vs fool proofing.

Ayende recently caused something of an uproar on his discussion of repositories and query objects (see the post here and follow ups here and here).

The interesting thing about the responses is not that they argued against the underlying  architectural principles, but that the arguments seemed to be about protecting developers from doing dumb things.

Why is it that developers want to protect everyone else from the component / service / framework that they have just written / integrated?  Are we that afraid of the software we write that we must protect everyone else from it no matter the cost?  It was while reading another blog post that I stumbled across the perfect phrase for this approach – Baka-Yoke or “fool-proofing”.  

The problem with Baka-Yoke is that when you fool-proof something, the universe tends to create a better class of fool.  The other problem with Baka-Yoke is the cost.   The cost of using Baka-Yoke is a nasty multi-pronged beast:

• You have to write more code to protect that code you just wrote and now need to be “protected”
• Because you are restricting the use of that awesomely great gee-whiz powerful component you just wrote or  integrated, you loose some of the power of that component.
• You’ve lost flexibility and the ability to adapt to new situations – no longer can you weild the full power of the code you just “protected”, and to respond to new situations you have to write yet another adapter or bridge or some other form of abstraction to provide access to the functionality you now need.
• Perhaps the greatest loss of all; those “stupid” developers you are protecting – they will never learn about the underlying component or code you are “protecting”.  This means they will never be able to make intelligent decisions about it’s use or use it in new and previously unforseen ways to achieve great things (okay so slight exaggeration but you get my drift).

Instead of excercising Baka-Yoke, maybe you should consider Poke-Yoke?

Poka Yoke is the practice of “mistake-proofing” work. It’s another principle from the Toyota Production System. Poka-Yoke mechanisms ensure that the user or operator can’t make a mistake. For example a plug that can only be inserted correctly (like the 3 pin UK plug) or can be inserted in two ways that are both correct (like a 2 pin plug).

Poka Yoke is not Baka-Yoke or “fool-proofing”. The goal is not to prevent idiots from doing the wrong thing, but to make intelligent people do the right thing.

From Thinking for a Change - Beyond Jidoka – Poka-Yoke

We can practise Poke-Yoke without too much extra effort in software development.  The quickest and easiest mechism we have to mistake-proof our work is testing – automated, repeatable tests that can be run to verify that the method / component / application is operating as expected.  

I think the Baka-Yoke mentality is a holdover from times before unit-testing become as openly accepted as it is today (at least in the .NET world).  I think the fastest way past this mindset is the complete and utter acceptance of testing as an integral part of any development work – in essence the application of Poke-Yoke.

if you want me to see your advertisements, stop making them in your face, attention grabbing distractions.

Nearly every day I visit a NZ news site called Stuff, it’s a good way to get a quick snapshot of the days headlines and give my brains some downtime from coding.  I used to use IE, it was there and I didn’t have to think about it, but then a couple of years ago Stuff started adding those annoying fly out ads that forced me to interact with them.  I resented having such an intrusive ad so I went looking and found Firefox and Adblock, I haven’t looked back… until recently.

With the advent of Google Chrome I found a nice clean browser that does what I need and does it pretty well, except it doesn’t block ads.  I went back to the Stuff site today – this time I was using Chrome, and I was assaulted by annoying in your face adds that distracted me from my true purpose once again.  I wouldn’t mind the ads, except the incessant moving / blinking / changing keeps dragging my focus away from what I was reading ( most ads seem to act like that fluorescent light fitting in your office with the broken starter ).

I’m now back using Firefox to peruse the Stuff site and none of their advertisers get me eyeballing their ads, the only downside for me is I don’t get to choose the browser I use.

End rant.

PS If you’re still using IE in any shape or form – go grab Firefox (and maybe even Chrome).  Microsoft dropped the ball with IE long ago and still haven’t figured how to pick it up again.

Recently I was reading a post about using a fizzbuzz test to find developers that grok coding.  Some of the comments also talked about using a simple swap test (i.e. swap the values of these two variables) and how this could be done without resorting to the use of a third variable.

While I can appreciate the”geek factor” or XORing variables together such that you can swap their values without requiring the use of a third, I would not want to use this approach anywhere except where memory was extremely limted, it is horribly unclear what is happening to someone that does not know about or understand the approach.  This set me to thinking, how could you swap to variables around in a reasonably clear manner without resorting to the use of a third.  The following is what I came up with.

using NUnit.Framework;
using NUnit.Framework.SyntaxHelpers;

namespace Swap
{
    public class Swap
    {
        public static void DoSwap(int a, int b, out int swappedA, out int swappedB)
        {
            swappedA = b;
            swappedB = a;
        }
    }

    [TestFixture]
    public class SwapTest
    {
        [Test]
        public void DoSwap_Should_Swap_A_And_B()
        {
            int a = 3;
            int b = 5;
            Swap.DoSwap( a, b, out a, out b );

            Assert.That( a, Is.EqualTo( 5 ) );
            Assert.That( b, Is.EqualTo( 3 ) );
        }
    }
}

Simple, effective, completely pointless and fun to solve.

I’ve just been reading a post by Jeremy Miller called Evolution of a Developer (in regards to DI/IoC) (I’ll wait here while you go and read it).  I started to comment on the post but decided to add my thoughts here instead.

Jeremy talks about the chasm from step 1 to step 2 and makes the following observation:

I think the leap from #1 to #2 is huge chasm that many developers will fail to cross in their careers, but every following transition becomes easier.

I wanted to add my observations about this (and expand the context slightly) from personal experience…

I think the step from 1 to 2 is such a chasm because it requires so many things to be in place before it can occur.  The developer has to want to do things better, they must be open to the opportunities to make things better and they need to be in an environment that makes taking this leap as pain free as possible.  If the developer really wants to change, the best thing for them is to start using a container as soon as possible, it accelerates understanding and acceptance while (generally) reducing pain.

I think there are 4 broad categories of developer that start down this path (and not all of them make the leap – some are quite content on their side of the chasm):

1. The Hacker

The hacker usually has no respect for his code (or his workmates) and is solely focussede on just getting it done.  Hackers will generally never rise above creating a big ball of mud without a significant investment of time an effort from the team around them.  A lot of the hackers I have seen started out developing web applications using scripting languages (like PHP or ASP – often self taught) and migrated to .NET without understanding that it is a paradigm shift they are making, not just a language change.

There is no easy way to help hackers evolve – they are focussed on just getting it done, no matter the cost.  I think that large amounts of pair-programming + reducing the ceremony as much as possible is the key with these developers, if you can appeal to their sense of pride in getting something done and getting it done fast, you may just win them over.

2.  The Ostrich

The ostrich is similar to the hacker in that he will generally never rise above creating a big ball of mud.  The key difference being that rather than not caring, like the hacker, the ostrich lacks the motivation to do better so places his head in the sand and carries on as normal.  This lack of motivation can be caused by the atmosphere of the team or the situation the developer is working in – the code has won, the developers are beaten down and simply push the mud around (back up the hill?) because trying to do any different seems hopeless.

If it is only a single developer that lacks motivation, you can treat them much the same as a hacker (although you will need to understand their motivating factors).  If the issue of motivation lies with the team, the problem is much harder to address and often requires a combination of new blood + a new project to motivate the developers and get them to a place where they can see that things can be better.

3. The Blind Man

The “blind man” is one of those developers who does the best with what he knows, but doesn’t know that there are better ways of doing things.  I think there are less developers around like this now because the .NET community has grown significantly in the past few years (I used to be one of these developers).

Sometimes the blind man will eventually stumble into the light, but more often than not it requires a gentle shove in the right direction.  I “saw the light” when someone sent me an email with a to JetBrains OmeaReader and their OPML (thanks AP / JD).  Reading blogs will not make you a better developer, but it opens your mind to the opportunities that are out there and makes takign the leap a lot easier.

4. The Natural Developer

These are the guys who just seem to “get it”.  If they aren’t using DI / IoC right now, send them a link and they’ll be all over it tomorrow.

From my perspective…

I went from having a vague idea of the concepts of DI / IoC to building a web application using MonoRail / Castle Windsor / NHibernate.  It hurt some, but at the end of the day my understanding increased exponentially by jumping from step 2 to 4 (and now I’m starting to understand step 5).  I would attribute a lot of my initial understanding and desire to take the leap to reading blogs of guys like Jeremy Miller and Ayende Rahien, but at the end of the day you have to want it.

If you have the opportunity – take the leap!

Unless you are living in a deep dark hole, you’re bound to have heard about Git.  What I haven’t understood until now is why Git, or more correctly why distribute version control and why would I even consider using it?

Today I stumbled over this video of Linus Torvalds giving a talk at Google about Git. It’s a little long (just over an hour), but well worth watching.  I can now at least appreciate the power of a distributed source control system (even if I probably wouldn’t use one in the forseeable future).

I was doing my usual morning troll through my rss reader when I tripped over this post from Jeremy Miller about the Entity Framework and the vote of no-confidence.  I am not qualified to comment on the EF as I haven’t even thought about looking at it yet.  While I was scanning his post I came across this link to a post by Stephen Forte (follow this link to find out who he is – I had never heard of him till today, but I have heard rave reviews about Telerik of which he is the Chief Strategy Officer).   I normally wouldn’t respond to a post on something I consider myself a novice at but the comment (below) pissed me off enough to warrant a reply.

My second major problem with ORMs is that ORMs are a solution to a problem that should not be solved. Developers who write object oriented and procedural code like C# and Java have trouble learning the set-based mathematics theory that govern the SQL language. Developers are just plain old lazy and don’t want to code SQL since it is too “hard.” That is why you see bad T-SQL: developers try to solve it their way, not in a set-based way.

First, lets get the pissed off, insulted developer response out the way…

I know and understand set based math.  I have written some pretty complex SQL to solve some rather hairy problems.  I have used various dataset / code-generated driven table gateway approaches.  The best data access layer (as opposed to object access layer or ORM) I have ever used is the one I never had to use.  NHibernate / Rhino Commons / NHQG and a little bit of glue gives me business object that contain all my rules (behaviour) and the associated data (state) and they do it in a consistent, performant and elegant manner.  I do not consider myself lazy or inept, I want to solve the problem in the best possible way in the shortest possible time and for any system with more than a little logic using domain objects is more often than not the best approach.

Now we can deal with the argument presented in the orginal post.

My first problem with ORMs in general is that they force you into a “objects first” box.

Object first design allows you to focus on the business concerns without worrying about the database constraints – yes you have to be aware of them butyou can optimise where there is a performance issue (premature performance optimisation must rank as one of the seven deadly sins of software design and development).

Database first design often constrains your system and forces it to contort to meet changing business requirements that crop up during development (been there done that), it wasn’t that the database was poorly designed in the first place, we just didn’t forsee certain needs that cropped up later.  Database first approaches are valid, particularly where you are working over a legacy database, however I think that in the general case you get a better result if you can ignore the database initially.

IMHO focusing on both database and object design at the same time requires too much of a split in concentration and way to much context switching.  I would argue it degrades the design process by reducing coherent trains of thought and interupts the building of that (all important) internal view of the business model with which you are working.

Design your application and then click a button and magically all the data modeling and data access code will work itself out.

Any developer who is looking for a “magic button” approach is most likely a highly skilled “Microsoft Developer” who really wanted a visual designer but couldn’t find it so has to resort to “clicking a button and magically have the data modelling and data access code worked out”.  I’d rather not have one of these developers on any team I work in, thanks.

This is wrong because it makes you very application centric and a lot of times a database model is going to support far more than your application.

I find it interesting that ORM is equated with “application centric”, looking around at most of the people using ORMs like nHibernate, I’d hazard a guess they are more focused on delivering business value than the guy sitting at his visual designer trying to make sure all the aspects of his dataset diagram line up just right.  I think using an ORM frees you from the database, this allows you to concentrate on the business aspects of the system, which allows you to deliver business value, not just a pretty digaram and a place to store a bunch of state.  Modern applications designed to support businesses are more than just the data in the database, they are the rules that govern that data and the transitions the data go through.  Without these rules it’s all just data, with these rules it is a goldmine of information and a treasure trove of process automation and increasing efficiency.  The application is not just the database or just the code, it is the synergistic coupling of both parts to create something truly useful.

In addition an SOA environment will also conflict with ORM.

Why? Where will the conflict occur? What will cause the conflict? As I said above, the database is simply a state repository, it isn’t the application. In an SOA environment the web services should be leveraging the objects to achieve the business purpose being exposed via http and angle-brackets. Yes there are issues associated with shipping objects on the wire, but they can be worked around. The benefits of providing the client with a rich business object that contains the rules required for working with it far outweigh the amount of work you have to put in to get those objects onto and off the wire.

I’m going to ignore the second problem (I’ve already had my rant on that).  From what I have seen to date, it is usually the enlighted developers who seek out ORMs, these are the ones who have been through dataset and stored procedure wars and come out the other side wiser (and battle scarred).

The sad thing about this post is that one very valid point is made but lost in the noise …

an ORM will not solve all of your data-access needs

however with a bit of work and a good understanding, I think you can get pretty damn close.

• There’s more orange in ReSharper’s gutter than there is grey.
• Code analysis for the current file takes longer than solutionwide error analysis of your last “good” project.

I’m back to working on legacy code written by hamfisted monkeys with little regard for anything vaguely related to good coding practices – 2500+ line codebehind classes anyone!?!

Feel free to add other “You know you’re working on bad code” signs in the comments – I’m in desperate need of a laugh :s

For the past couple of months I have been building a web based surveying application designed to allow employers to carry out lifecycle surveying of their employees (e.g. when they start, annual reviews, exit surveys).  When I started building this application, I was given complete control over how it was to be built and I chose to use MonoRail.  After a while I integrated Windsor, NHibernate and Rhino.Commons.  All of my unit tests have been written using NUnit.

After spending the previous 5 or so years fighting working with ASP.NET and various incarnations of MVP and MVC, hand writing data access code and stored procedures and not really leveraging any kind of dependency injection, using this stack has been bloody marvelous and a true breath of fresh air.  The learning curve is steep but rarely treacherous, and there is plenty of support in the community.  Even better,  I can peer into the inner working to see why something is (or isn’t) working.

To list all the contributors to those projects would require a rather long blog post (although you all deserve a huge round of applause), but there is generally one or two people who are “responsible” for these projects and spending large amounts of time and effort keeping them going.  So here’s a thank you to Hamilton Verissimo aka Hammett for the Castle stack ( MonoRail / Windsor and a whole lot more );  Karl Chu and Sergey Koshcheyev for NHibernate; Oren Eini aka Ayende for Rhino.Commons ( although his name appears a lot in conjunction with both Castle and NHibernate ); and Charlie Poole, Jamie Cansdale and Gary Feldman for NUnit.

All of these projects are the results of a large number of people donating their time and expertise, so I just wanted to throw a resounding THANK YOU! out into the ether in the hope that they might see it and know my gratitude.