Field Expedients, or why "I don't have the tools" is not an acceptable answer

time to read 4 min | 626 words

Recently I had a few conversations about tooling, lack thereof and the impact that this has on the overall system.

I don’t think that someone can argue that starting from scratch is a very good idea in most scenarios. This is especially true when you are talking about any significantly complicate system, which we all do.

There is still a place for quick & dirty solutions, but that is for throwaway utilities. Hell, even calc.exe isn’t simple (arbitrary precision numbers) anymore.

Therefore, I am constantly surprise by people that chose to go without. I could understand that if they chose that path out of ignorance, but all too often a conscious decision.

It is based on reasons such as: “It would take me too long to get approval to buy this tool”, or “I have to go through the Proper Channels to use that tool”.

I don’t like those reasons, but they are real, and I had encountered them several times.

By now you have probably understood that I have firm opinions about how to go about building successful software systems.

Those opinions are backed by the tools that I am using, but are not constrained to them (just check the commit logs when I am doing something new J ).


So, where is this headed?

Right now I am working on top of the  Naked CLR, which means that I am mostly cannot use my usual stack. This is not fun, and I assure you that I bitch about this more than enough.

Nevertheless, the inaccessibility of my usual stack doesn’t mean that I can just ignore my experience so far. I have the aforementioned opinions for a reason.

IoC and AoP are two simple concepts that I have embraced whole heartedly. Auto registration and letting the application figure it out is paramount to the way I develop software.

I tried to do it otherwise, and I have myself constrained and annoyed.

How do I solve this issue? By using Field Expedients replacements.

What do I mean by that?

A container, auto registration, method interception and AoP are fairly easy to build. You can take a look at those implementations, to get some ideas.

I implore you, however, that you will not use those. They are replacements, hacks and temporary. They are there so I can work using familiar methods and practices, although not using my familiar tools.

If you’ll tell me the implementation is bad, I’ll agree. But it is there, and it can be used. As a scaffolding if nothing else, but it can be used.

This post is mostly to note that not having the tools is not a good enough reason. You can build the tools.

This post is written to make a point that most people seems to miss. You don’t need to get it perfect. You don’t need to drop down to assembly to get every erg of speed you need. You don’t need it to be functional for the general case, you don’t even need it to be pretty.

The so called container that I have created is a good candidate for the Daily WTF.


I think that it took about 4 hours overall to build everything that I needed. I didn’t build it all in one go, just as I needed it. You can actually take a look at the history and see how it went.


Don’t mistake what I am saying, however. I am calling those Field Expedients for a reason. They are crutches, and are not nearly as capable as the real things. But they are close enough, and I am told that I am good at mocking.