More P/Invoke Help

One of the first things I really hammered with .NET 1.0 back in late 2000 was P/Invoke. I was used to Java, but IMO, Java always had a fatal flaw - language design hubris. Java is perfect, and C is garbage, therefore, everything should be converted to Java, or so it seemed anyway. That philosophy trickled down to how Java used existing C code - JNI (at the time) wasn't a way for Java to call C code as much as it was a way for *YOU* to write a "clean" and extensive wrapper worthy of being called by Java so that Java wouldn't have to dirty its hands with the "bad" C code. At the time, I was extremely skeptical about .NET, but one thing I did like is that it readily admitted that the enitre world was not in .NET and there was plenty of "legacy" code written in C that was.. *gasp* ... usable and useful! Furthermore, it cooperated with said C code and even had a very simple (relatively speaking) way of calling it. But a lot of people weren't used to P/Invoke, although it was similar in concept to using Declare statements in VB (just more powerful). I was really taken by how comprehensive P/Invoke was, but people who weren't used to looking at C code had a hard time translating calls. I remember writing a little tool called P/I-Spy that would take C function prototypes and convert them to P/Invoke, or do the same work via a step-by-step wizard that allowed you to describe the call. The problem is that I wanted to create a comprehensive database of calls for the Win API, and I just didn't have the time, so I was happy when someone else took up the mantle and created At that point, I let the tool slide completely and have never touched it since.

However, Microsoft just launched a tool of their own. You can find it here:, and it has some really cool features, among them, the ability to convert volume code.

Saying YAGNI to YAGNI?

I was reading a very interesting post this morning:

and I want to start by saying that I whole-heartedly agree with James at the heart of the matter. YAGNI, when intelligently applied, is not just an excuse to do stupid simplistic things. But that got me thinking (again) that YAGNI itself is probably an inadequte piece-of-jargon-turned-tool that encourages some people to use it "unintelligently". My motto is that if something isn't providing consistently good results, then there's probably something wrong with it, so here's the gist of my thoughts:

I think the problem with YAGNI is that as a concept, it works more like a binary switch. It encourages people to think in Yes or No options and concentrate on a single vector of a multi-dimentional problem. By "intelligently" applying YAGNI, the focus should really be on providing the most effective and efficient (i.e. simplist) solution that can solve the problem given all the goals that must be met. This is not a "yes I need it", or "no I don't" question - it's a question that begs us to consider a range of alternatives and evaluate them based on (not just complexity) but R.O.I, maintainability, and likelyhood of change and stability, among other factors. At this point, some agilists might argue that we're trying to do too much design upfront by taking all this into account, but most of these factors can be very quickly assessed in a matter of minutes on a "good enough" basis, which is really in keeping with the spirit of Agile, IMO. YAGNI is just a simple(istic) way of terming it, but perhaps it's too simplistic and encourages us to evaluate only one vector (complexity) of the problem that really has other dimensions that need attention. I honestly think it hurts the process to give jargon undo weight. A person who uses YAGNI intelligently is actually taking those other factors into account, so perhaps YAGNI as a concept is just putting too much focus in one area for those who are more prone to simply use the jargon at face value as opposed to "intelligently" applying a tool, which is starting to make me wonder if it's actually a good tool to begin with.