"Look Ma! I'm inventing my own buzzwords!"

The problem

A little while ago, some of us at Macadamian held discussions on behaviors we would like to encourage among younger developers. One thing we agreed was that "stubbing" (coming up with methods containing as little code as possible, in order to stabilize the API interactions faster) was becoming a "lost art". And so we resolved to start encouraging "top-down development", as we were used to call it.

So far, we've met with little success. Despite our explicit encouragements, it seems hard for people to adopt a "top-down" approach.

And lately, I've been wondering: what if we're not communicating right? After all, "top-down" is a pretty generic term. After all, it's even used to describe an entire programming methodology which predates Object-Oriented Design. So perhaps some of the people in our teams are thinking: "Of course I'm going from top to bottom, what are they complaining about!?"

That's when I thought of something...

Mandatory flashback to the author's younger days

Back at school, I followed this neat AI course which taught me some general problem-solving heuristics. Overall, it showed two ways to attack a problem by brute force: breadth-first and depth-first.

Let's say we're looking for a file within a directory structure. A depth-first approach will recursively explore each solution by first going to the lowest node possible. Only then will it work its way back up, before going down again.



A breadth-first approach, on the other hand, would attempt to fully explore one level of nodes before jumping to the next one.



For additional details, you check out breadth-first search and depth-first search on Wikipedia (where I borrowed these graphs from).

And so...

I'm beginning to think that younger developers show a natural tendency to code depth-first. They pick a single feature/functionality/API call, then implement it down to the lowest level, at which point they consider to have a "valid iteration". Then they go back up a few levels, and start again. Doing things that way can make you feel good because you've added a lot of code, but it makes things harder to test, and might complicate future integration.

We'd like people to try out breadth-first coding, which would mean getting a wider range of partly-implemented methods in the early stages.



First, you'd define the APIs of the first layer, providing a "bare-bone" implementation of each method. Then you'd define the second layer, once again with a minimal implementation, at which point you'd be able to properly implement the first layer. Repeat for each layer of implementation.

So, as my first step, I'll start using the term "breadth-first" when talking about this approach. I'm hoping that by using this term instead of "top-down", I'll get a few "Huh? WTF?" responses, which may be just what we need in order to break some old habits...