+972 52-548-6969
Field Expedients, or why "I don't have the tools" is not an acceptable answer
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.
Comments
One of the constraints I struggle with is using open source software in a commercial product. Even ones like log4net or DynamicProxy that are licensed under Apache or NHibernate licensed under LPGL cause the higher ups to spew fire.
Nothing is used in our application that hasn't been vetted by a lawyer. No icons that are found on the internet can be used. No free or open source software can be used (unless the lawyer says it can).
We are even told no 'cut and paste' can be used. This makes it difficult to deliver quality software because of our hands being tied. I've always worked under the assumption that I should never 'reinvent the wheel'. I'm not a great thinker so everything I know I've learned from others. I have learned to talk to our lawyer before putting anything into the product that might come from a 3rd party source.
Alan,
Ask your lawyer to explain the dangers of Apache license, I would be glad to hear it.
NHibernate's license is LGPL, it means that if you modify NHibernate, you must share _the mdifications_. Code that uses NHibernate has no restrictions.
How do you apply dependencies in the container using that autoregistration ?
Funny, these same places allow you to write tons of proprietary code but you can't use an open source project.
Personally speaking: documentation, reputation, and stability are what we look for.
Ayende,
But you cannot use files from SvnBridge either, right?
It's open source is it not?
Steve,
I don't follow the relation between dependencies and auto registration.
I just register that and let the container do the rest.
Alex,
SvnBridge is released under the MS-PL.
The MS PL was approved by the OSI:
http://www.opensource.org/licenses/ms-pl.html
You can take SvnBridge and do whatever you want, likewise for any of the files in it.
From MS-PL:
(D) If you distribute any portion of the software in source code form, you may do so only under this license by including a complete copy of this license with your distribution. If you distribute any portion of the software in compiled or object code form, you may only do so under a license that complies with this license.
Does it mean that whatever you created for your customer using files from SvnBridge shoule be redistributable royalty-free?
Alex,
That is how I read it.
You make a good point about building the tools. I think that anyone who uses tools to allow them to do things that they don't understand is like giving a table saw to an elementary school class for arts and crafts. Ajax is a good example of this; many people depend on dojo or atlas or whatever and don't really know how it works. I could build my own Ajax framework if I needed to (and I have). I think that everyone who uses any type of tool should be able to implement those tools, even if their implementations are not production quality, otherwise you have no business using tools.
"NHibernate's license is LGPL, it means that if you modify NHibernate, you must share _the mdifications_"
Huh? That would be GPL, no? If I modify and /distribute/ an LGPL lib, the modified copy of the lib must also be distributed under LGPL (or, optionally, GPL) and I must make prominent notice of the changes. Was this what you meant?
If I make changes to an LGPL lib and just use (not distribute copies of) the lib, I´m under no obligation to share my modifications with anyone.
/Mats
Even with the GPL, if you don't distribute copies of the modified code, you don't have to share the modifications.
See http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
Jeff, I disagree about having to be able to build your own tools before using an equivalent from someone else.
I couldn't write a compiler without a huge amount of study. Does that mean I shouldn't write any C# code?
I certainly couldn't write a VM with garbage collection, native interop, JIT compiling and any number of other things .NET supplies. Does that mean I shouldn't use .NET at all? After all, it's just a tool to a large extent.
Should I have to be able to write an IDE before I can use Visual Studio?
Yes, you should understand how the tools work at some level. I understand a reasonable amount about the JIT and garbage collector - but certainly not enough to implement one myself. Yes, a web developer should know enough about HTTP to be able to see what's going on, understand the impact of various options in terms of requests/responses - but should they also be able to write a web server? A web browser? A network stack?
Jon
(None of this is in any way taking away from Ayende's point that there certainly are tools which can be implemented at a reasonably simple level if necessary, by the way. Things like an IoC container, unit test framework, or logging framework are good examples.)
Re: MS-PL,
I need to clarify the earlier discussion. The MS-PL is a "BSD-like" license, which is more permissive than you (Alex) indicate above. The only caveat is that you MUST post the license somewhere if you use the code. That's it.
So specifically, you can take the code, roll it up into your Instant Billionaire Software Moneymaker product, post the license somewhere (maybe even just in the source code), and continue to charge a billion dollars for your closed-source product. You're done and in compliance with the MS-PL.
Oh, and "IANAL".
Mats, yes.
GPL means that you have to GPL both your modifications and any source code that uses them.
And yes, I am ignoring usage vs. distribution here.
@Jon - I agree with you on some of what you said but disagree in principle although I think I may have failed to articulate my point correctly. I don't think you need to fully write a tool for everything, particularly for complex tools, however you should at least basically understand what the tool is actually doing for you before you lean on it for being able to do something that you can't. For example, I can't write a compiler, but I'm familiar with how compilers work and I have written code in assembly language so I know what a compiler is doing for me. I have written a disassembler in assembly language so I know generally what the assembler is doing for me.
I strongly agree with your point that you couldn't write a compiler without a huge amount of study. However, that means that if you did study, you could write a compiler if you really wanted to. That's the kind of skill that I think every developer should have and what's dangerous is developers who rely on the compiler to do whatever magic they think it does. I think I need to blog about this in more detail, give me a day or two.
@Jeff: Yes, I completely agree with understanding what the tool is doing for you. It's just that often there's a lot involved in the implementation which doesn't actually affect the end result - I can know what a compiler is doing for me without really knowing exactly how a parser works, for instance. I need to know any implications from the parse process, but not the details of the process itself.
Being able to do something after studying for a vast amount of time applies to almost anything though: and it doesn't mean I have any of that knowledge right now.
I suspect we really are fairly close in our viewpoints though. A classic example is query expressions in C# 3. I think it's fairly important that C# 3 developers have at least some idea of what they really do - that it's a parse-time transformation into "plain" C#, which is how it can use extension methods or normal methods, can convert lambda expressions into delegate instances of expression trees, etc. There are those (including people whose views I usually respect, btw) who believe that's too close to being an implementation detail.
Without understanding that query expressions are like macros whose expansions use lambda expressions, you can get into trouble quickly. Beyond knowing that the transformation exists, however, I don't really need to know exactly how the compiler achieves it, or believe that I currently have enough knowledge to implement such a compiler myself.
Does that sound reasonable to you? I suspect we're both really arguing against cargo cult programming:
http://blogs.msdn.com/EricLippert/archive/2004/03/01/82168.aspx
I'll be interested to read your blog post :)
Comment preview