I wrote that article in 2007, and I am stunned, but not entirely surprised, to hear that three years later “the vast majority” of so-called programmers who apply for a programming job interview are unable to write the smallest of programs.

To some extent, I think he’s being unfair, although I actually agree with him completely.  One thing I’ve noticed recently is that there seems to be a bit of a step function in developer ability.  Below this demarcation, developers seem to think of the value of their code entirely in terms of what they can get some library or another to do.  Their programming is almost entirely manipulating objects written by others.  Above this line, developers start thinking of the value of their code primarily being in what they write – and the code written by others that they have to deal with is, at best, an annoyance.

It’s not even entirely based on programmer ability.  There can be very good developers capable of doing a lot of things by that kind of manipulation.  There can also be developers that focus on their own code that are very much in the learning stages.  It almost seems to be more about scope, or level of abstraction, than it seems to be about effectiveness or experience.

Taking it a bit further, there seems to be at least 4 of these developmental “jumps” that I’ve recognized.  There’s probably more – and the fact that I can’t see them probably means that I haven’t achieved them myself, yet.

1. Manipulation of code created by others.  Typified by “call this library, put the results into this other library.”
2. Algorithmic ability – primarily defines programs by the data transformations done.  Library manipulation is assumed.
3. Structural ability – primarily defines work done by the internal structure of the program developed.  Algorithmic ability assumed.
4. Systems design – primarily defines value by the overall design of the system, spanning multiple programs.  Structural ability assumed.

So the problem with things like the FizzBuzz test, and the number of developers that can’t hack it, is that FizzBuzz is a “level 2 developer” problem.  Developers at the first level, why they might be great at a huge number of tasks, simply don’t have the tools to solve it, and don’t usually think it’s worth solving.  They also tend to think that problems like “find the least common multiple” are obscure math problems, and don’t get that it’s a test of algorithmic thinking.

A similar problem exists with design patterns.  These operate at the third level or higher.  A developer at the first or second level really has no use for them, or even really the capability to understand them.  Telling a developer at one of those levels that design patterns are “good” is just asking for trouble – without the required understanding, they’ll try to apply patterns to the wrong problems.

Again, this is not really a value judgement.  There’s  alot of value in experienced devs who are at that first level – since they value libraries written by others, they’ll tend to know the ins and outs of them very well, will know which ones are useful, and will be able to pull things together to make something blindingly fast.  If you want someone to develop a pretty typical CRUD app, that’s probably what you need.  Guys at the “higher” levels probably aren’t what you want – since they don’t care as much about other peoples code, they won’t be as up on the intricacies or latest libraries.  But, once you get off into areas that aren’t well-tread, that’s where you’ll start to need them.

So are things like FizzBuzz good tests for developers?  Depends.  If you really need a guy to tie some libraries together in a useful way, well, probably not.  You’re applying a second-level test when you need a first-level developer – you’re testing the wrong thing.  But at least it explains how so many programmers “can’t program.”

There’s a pretty common pattern for them, so common that it’s a part of the whole Behavior-Driven Development idea.  It’s just:  “As <role>, I want <feature> so that <benefit>.”

A lot of people seem to think that this is overly simplistic.  I respectfully disagree.  What this simple format does is tell us the most important things about anything we do, in a way that pages of details about the implementation don’t.

As <role>:  Tells me who the customer is.  And who the customer is tells me a lot about how I need to expose functionality.

I want to <feature>:  describes what the customer wants.  This is typically where we spend the most effort.

so that <benefit>:  The business value of what we’re doing – why it’s important.

Simplistic?  Maybe, but it does a much better job of reminding us of who our customers are, and what the business value that we’re trying to produce is, than any other format I’ve seen.

And, frankly, forgetting who our customers are, and not focusing on business value seems to be a far more frequent problem than not spec-ing features sufficiently up front.

After writing the list, I noticed that, as typical for prioritization systems, I ended up with a bunch of stuff in P1, some stuff in P2, and almost nothing in P3.  Since I’ve seen this anti-pattern before, I decided that I would split them up into groups of equal size.

Boy, was that hard.  Even without complete stack-ranking, coming up with equally-sized groups forced me to think about which of the items were important, and why, in a way that just arbitrarily assigning priorities did not.

After doing this, I’ve become even more convinced that prioritizing is a waste of time, and that stack ranking in some form is, really, what is needed.  Prioritization alone does not force you to really think about your requirements and what is really important, and seems to inevitably end up with a “top priority is everything we think we’ll do, second priority is everything we’ll do if we have time, and third priority won’t get done” schema.

I don’t know if total stack ranking of every possible feature or work item is necessary, but I think that, at the minimum, you need to have small groups of equal size (probably no more than 5-10 items), and those need to be ranked.  This gives some flexibility in terms of not overly worrying about whether items 1 and 2 should swap (since they’re both likely to get done), but still acts as a forcing function in that you’re limited to ‘n’ top-priority items.

So, code that can easily be changed is better than code that can’t be changed.  But how do we know how easy it is to change code?

Difficulty of changing code is best measured at the class/interface level.

If you have a lot of classes that are each easily changed, you will be able to change your code easily.  If you have a few classes that are each difficult to change, it will be difficult to change your code.  Even if the total work done is the same.

The primary measure of difficulty of changing code is the number of consumers it has.

The more things that know about your code, the harder it is to change.  This is a reason why the universally-loved concept of “the one place that does all X’ almost always fails.

It is easier to change an interface that has one consumer than one with three consumers.  It is easier to change an interface with three consumers than one with twenty consumers.  And if you have one hundred consumers, forget about it.

By consumers, I do not necessarily refer to applications or individuals, rather I refer to classes that refer to any individual class.

It’s easier to change internal code than public-facing code.

This is a restatement of the first point.  Published, public-facing code has an infinite number of consumers, making it nearly impossible to change.

The more implementation details you expose, the harder it is to change your code.

Public-facing code should, as much as possible, not leak implementation details.  It should reflect the user-facing concepts that are being exposed, and not the implementation details of those concepts.

Not exposing raw types is a good way to do this as well.  If you have a user ID that’s an int right now, it may be somewhat painful to change it to a long later.  However, if you wrap the int in a UserID class, changing it to use a long or even a GUID will become much, much easier.

The more scenarios you support, the harder it is to change

If you support a large number of scenarios, it is almost inevitable that assumptions needed for one will spill over into others.

The more well-defined your code is, the easier it is to change

If your code has well-defined inputs and outputs, and doesn’t have side effects, it is much easier to change.  While the public entry points may remain difficult to change if they have many consumers, any internal details can be changed arbitrarily, and the correctness of the final code can be verified.

On the other hand, if the behavior of the code is not well-defined, then changing it can become extremely difficult, as consumers may be relying upon existing behavior that is either in error, undocumented (and so likely to change if you touch the implementation), or simply a side effect of the “real” work being done.

This seems to be somewhat of a controversial subject.

On the one hand, we have Java, which forces exceptions to be caught and potentially rethrown.  This is, certainly, something of a pain.

On the other hand, C# doesn’t require anything, and any method can potentially throw any kind of exception.

I can see the points on both sides.  Nothing is  uglier than a bunch of arbitrary try/catch statements in code that do nothing more than rethrow exceptions.  And just blindly swallowing exceptions is even worse.

On the other hand, not really knowing what a method might throw in C# can be really, really annoying at times.

Let’s start with versioning, because the issues are pretty easy to see there. Let’s say I create a method foo that declares it throws exceptions A, B, and C. In version two of foo, I want to add a bunch of features, and now foo might throw exception D. It is a breaking change for me to add D to the throws clause of that method, because existing caller of that method will almost certainly not handle that exception.

Well, that’s certainly reasonable.  But, I have to wonder if it’s the right answer?  If you add a bunch of functionality to a class, is it perhaps better to make some new ReallySpiffyFoo class that contains the new functionality, and leave the existing class as it is?

Then again, I’m not a huge fan of growing classes over time – in most cases, I believe you’re better off leaving a well-defined class as-is except for bug fixes, and putting new functionality into a new class (which might internally use the old one).

Now, each time you walk up the ladder of aggregation, you have this exponential hierarchy below you of exceptions you have to deal with. You end up having to declare 40 exceptions that you might throw. And once you aggregate that with another subsystem you’ve got 80 exceptions in your throws clause. It just balloons out of control.

Another reasonable point.  However, I’d tend to believe that in a case like that, you’ve got a bigger design issue at play.  Why in the world would a business object throw a FileNotFoundException or the like?  At most, it should throw something like a CouldNotLoadDataException.  The fact that the data was to be loaded from a file is completely irrelevant at that level.

I also suspect that Anders is looking at this mostly from the viewpoint of a language and framework developer.  As a framework developer, he expects code he writes to be called by other people, and they can certainly look up what exceptions are being thrown.  That’s reasonable.

However, if I’m using an interface as an extensibility point, it’s a slightly different story.  Now I’m importing someone else’s code into my application, and I have no idea of what it might throw when I call it.  If that’ doesn’t sound scary, I don’t know what would.  At this point my options are either let my app crash when I make any arbitrary call, or catch Exception directly.  Neither of those are, in my mind, really good solutions.

What I’d like to see is defined exceptions, but not necessarily checked exceptions.  I’d like to know what exceptions a method may throw, but I don’t want to necessarily be forced to catch them.  In my mind, the exceptions you throw are effectively part of your API, especially when looked at from role-based interfaces for extensibility rather than header-style interfaces.

If I define an operation in an interface, I’m basically saying that I expect to be able to make this call, with certain parameters, and get a certain type of result back.  As part of that, saying that I expect to throw (or will throw) certain exceptions is part of the definition of my API.

What I don’t see much value in is checked exceptions as in Java.  To me, there is absolutely no value in putting in boilerplate code to just rethrow exceptions that I’ve caught just to satisfy a compiler restriction.  But, knowing what exceptions can be thrown is, to me, extremely valuable.

For instance, when dealing with data across a network, you might decide that you need to know that your local copy of the data is up-to-date before you reduce a particular value by 5.  So the question, in this case, is “can I know that my data is up to date?”

And the answer for that is, generally, no.  To do so requires implementing some sort of locking mechanism, and ask the database folks how easy that is.  Hint:  It’s easy in the trivial case, but quickly becomes difficult.  Another hint:  Two words – ‘deadlock’ and ‘livelock.’

As developers, we tend to believe that we can know everything about a system.  We tend to believe that every problem is, essentially, solvable.  We hate admitting that we can’t get the answer to something.

But sometimes, we just can’t.  Sometimes, the answer to something is dependent on so many other factors that are outside of our control, and that we can’t measure, that there is no way to answer the question with 100% accuracy.

When faced with problems like this, I try to follow up the initial question of “can we know this” with another couple of questisons:  “What do we know,” “what don’t we know,” ”who knows this,” and “what is it we really want to know or do?” This will often suggest a better solution to the problem than one which requires unknowable information.

For instance, in our initial example, we don’t know if our data is up to date, because we don’t know if someone else has updated the data since our last refresh.  And we can’t know that, because it will take an amount of time for any updates to reach us – the best we can ever do is say that we know what the data looked like at some point in the past.

But, what we do know is different.  We do know that we want to decrease the value by 5.  And we know that in most cases, there’s an authoritative data source somewhere.  This suggests a solution – instead of us modifying the data locally, send a request to the source of the data not to set the value to a specific amount (what we believe the current value is, minus 5), but rather to decrease the amount by 5.  Because the data source should always have the current value, it will know what to do to decrease the current value by 5.

If we don’t ask these questions, we can easily start down the road of trying to know the unknowable – being so set that we’re going to have our local machine get the latest value and set the new value to that minus 5 that we do all sorts of crazy research into synchronization and locking mechanisms.  Generally, this results in madness.  Every solution that covers some percentage of cases leaves others broken, and you can end up chasing your tail trying to patch the corner cases, or dealing with issues that are only there in the first place because of how you’re dealing with the problem – for instance, locking issues like I discussed earlier.

“X is Y.”

That’s all.

Classes map to nouns.  They say what something is (a Person, for instance).

Interfaces map more closely to adjectives – they describe the noun (specifically, what the noun can do).

So, you wouldn’t have the class Person implement IPerson.  That’s basically saying that a person is person-y, which doesn’t make a lot of sense.

A person might implement IFeedable, IHirable, etc.

One thing that occurs to me as I write this post is that interfaces don’t describe what their nouns can do so much as they describe what can be done to the nouns.  This gets into the idea I have that most languages are very good at describing incoming messages to an object, but don’t do a very good job at describing outgoing messages.  But, that’s a topic for another day.

If this is true, then interfaces and classes serve very different purposes.  An interface shouldn’t be simply seen as the ultimate abstract base class.

If an interface is used to describe what can be done to a class (a Person might be IHirable), then in many cases, a class may implement multiple interfaces.  If that’s the case, then each interface should consist only of the actions that are atomic with that concept.  Actions that only make sense together, and don’t ever make sense without each other.

For instance, IHirable obviously needs some sort of Hire() method.  And, it might make sense for it to have a Fire() method.  It doesn’t make sense (legal reasons and internal politics aside) to be able to hire someone without being able to fire them.  And, similarly, you can’t fire someone that wasn’t able to be hired in the first place.  So, Fire() should go in IHirable, as it’s tightly coupled to Hire().

What about Pay()?  It doesn’t make sense that you can hire someone and not pay them, so it might make sense to put it in IHirable.  But, there are a lot of people that you pay that you don’t hire, and in fact, can’t hire.  The pizza delivery guy, the water company, etc.  So, maybe Pay just belongs in IPayable, which IHirable can extend.

Here’s a statement I’ll put forth, but I’m not backing 100% yet:

Having an interface with the same name as a class is a design smell.

The other way to define value types is by storage – stack vs. heap.  I really don’t like this, though, as one of the advantages of value types is that it’s safe to pass them by reference.  I would say a string in C# is a value type, even though it’s a class (and therefore passed by reference).

So, here’s a set of criteria to determine if something is a value type or not.  These criteria don’t specify whether a particular type could be implemented as a value type, only whether or not they are a value type as implemented.

1. The type must be immutable.  Any methods called on the type cannot change its members.  If a modification is desired, the method should create a new object of the same type, and return that object.
2. The type must only reference other value types.

If your type follows these two rules, it is guaranteed to be side-effect free.

Rule #2 might be relaxed, if the reference type that the type holds is guaranteed to never be exposed (so nothing can ever modify it), and the object never modifies it itself.

Edit a year later:  Another exemption is that a type can be a value type if it never acts upon any reference types that it contains.  A list can be a value tpe, then, as it doesn’t actually act on any of its contents.

Conceptually, objects are these things that sit in space and receive and spit out messages.  And if we look at our User class in that way, it kind of makes sense.  We define the behavior of the User object as receiving a message to set its name, and when it does so, it should then emit a message that it should be saved.

And this is a pretty convenient way to think of objects.  It also isn’t modeled well by most object-oriented languages.

C++-derived languages handle relationships of "is-a" and "has-a" types very well.  But, what we really want here is a "talks-to-a" relationship.  There’s no real first-class way to do that.

Also, they handle incoming messages very well, by means of the public interface of an object.  But, outgoing messages are a little tougher.  Sure, you can do all sorts of things with message receivers and emitters, but realistically, people are going to use the built-in constructs of the language.  So, if we want to model objects as message receivers (easy) and emitters (not easy), we should do it in as basic a way as possible.

And now we get back to "getting-stuff-done-land."  Looking at our User class from the past two entries, we can look at the interface we define as the outgoing messages that the object can emit.  Viewed in that way, it makes sense that the object would own that interface – who else would?  And why would an outgoing message from a user know anything about a database?

There’s other ways to model an outgoing message, and they all pretty much boil down to function pointers.

First, you can use virtual protected methods to define messages, and then override them in derived classes to translate them to the incoming messages that are desired by another component/object.  This method has the advantages of looking more traditional, but the disadvantage of not being able to mix-and-match receivers at runtime.

Secondly, you can use events and delegates.  Combined with lambda expressions in C# 3, this can be an effective way to define outgoing messages.  It has the advantage of not requiring additional classes, but the disadvantage is that you have to hook up each event individually.  Also, events can provide multiple dispatch, but that can become wonky if you want to remove individual anonymous delegates, so I’m counting that as a neutral.