DIP is not for reuse

The Dependency Inversion Principle is this wonderfully clever concept for decoupling layers. I've written a bit about it before here.

To summarize, the idea is that your high layers define interfaces that your low layers implement. Thus insulating the high layer from the low layer. This fits in very nicely with TDD as you can write/test the high layers first and mock out the low layers.

So DIP is good stuff. But it doesn't play well with reusable component architectures. That is, if you're designing software components which you intend to use in many different places (some of which may be as yet unknown), you can't use DIP between them.

Maybe it's time for an example. Suppose we have a Component A and a Component B. Now we're writing a third Component C which will use A and B. Finally, we have an Application App which will use A, B, and C.

A, B, and C may all use DIP to structure the layers within the components. But you wouldn't want to use DIP between the components. If we tried to do that, we would have to define two interfaces in C that described how it used A and B. And three more interfaces in App that described how it used C, B, and A. Then A and B would both have to implement interfaces defined in C and App. Plus C would have to implement interfaces defined in App. And now you can't reuse A, B, or C in another App (without including App).


So what do we do if we want our COMPONENTS to be independent, just like our layers? Just change it slightly. Create an assembly for each component that contains interfaces used to interact with the component (ex: A.Contracts). Make A implement these interfaces, and let anyone who wants to use the component reference the Contracts assembly.


If you have another approach, or a similar issue, or you know, stuff to talk about... Let me hear it.

Users don't want help

This may be one of those obvious, everyone already knows it, stop repeating it like you're the first person to think of it, topics. But it's still true. And it's still important to remember.

Users don't want help.

This blanket statement applies to both types of users: software and drugs. I'm going to focus on the software type.

Think of three programs you use frequently. Lets pretend you're thinking: Internet Explorer, Microsoft Outlook, and Microsoft Office (you're clearly very into Microsoft software arn't you?). Have you ever in the entire time you've been using those used the help system?

If you're like me, the answer is no. While writing this I realized I didn't even know if Internet Explorer HAD help (I checked, it does).

Now have you ever had a problem in any of those programs? Of course you have. But you didn't go to the help. Why not?

Some people will answer by saying that the help is useless. Mostly this is true. But I know there was a time when that wasn't true. For example, I've been told that the help in the old DOS Word Perfect was fantastic. I think this is a chicken and the egg problem. What came first, bad help, or people not reading the help?

My guess is that software vendors actually realized no one was reading the help and so started putting less effort into it. Then people in desperate situations tried using the help and discovered it wasn't very good, so they stopped referring to it even in the most dire circumstances. The vendors still have to provide some kind of help of course. It's expected of them. But they certainly don't have to waste their time making it good!

It all comes back to the fact that users don't want help. When I'm trying to do something, I don't want help doing it. I just want to be able to figure out how do it. Right there. On the spot. And if I fail at that, I want someone else to do it for me. (That's why Linux forums are always full of "RTFM!")

If you can't give people help to get them to understand your application, how do you do it? In Steve Krug's awesome book, "Don't Make Me Think" he has this advice: If you can't make it self evident, make it self describing.

It's much harder than it sounds. But it's also more important than it seems. After all, if your users can't figure it out and they're not going to ask for help, they have only one option left: To make like a tree and get the heck out of there. I mean, leave.