[anomie]

I've found the authors proposed approach at the end of the article to be a very useful one, even if you're not using TDD. A very regular piece of advice I give to new developers is "breadth-first not depth-first" - i.e. write a whole function at a consistent level of abstraction before you dive into writing the other classes etc. you need to support those few lines of high level code.

I find that most new developers instinct is to do exactly the opposite - i.e. write the first line of their main function, then realise it needs, say, an argument-parsing class, so start writing that, then realise that needs a logging class, so start writing that, etc. which means you have to keep much more stuff in your head at once, you end up writing much more code in each commit than you should, and the distinction between bits of code at different levels of abstraction often ends up much blurrier which leads to messier design.

This seems to be quite easily countered though - just pointing out to people the difference between breadth-first and depth-first styles can have quite an immediate effect

[dragonwriter]

Is "top down" vs. "bottom up" programming/design really not a set of terms and concepts that is still taught in nearly every introductory programming course such that people mentoring "new developers" need to introduce the concepts and invent new terminology for them?

[_asummers]

It definitely is. The problem, I think, is that people forget these fundamental concepts when they're shoved into a giant legacy code base that clearly didn't follow that process. They seem to get overwhelmed by the spaghetti and forget their entire undergrad curriculum.

As a side note, I find it helpful to think of what the high level business objects will be at the beginning, but build a bunch of utility functions from the bottom up, working towards a DSL of sorts at the various abstraction levels. As you explore the solution, the end location of those functions usually becomes abundantly clear.

[colin_jack]

> As a side note, I find it helpful to think of what the high level business objects will be at the beginning, but build a bunch of utility functions from the bottom up

Yeah I think this is a reasonable approach, especially as if you do end up completing this, and get to a design you are happy with, it will probably be very different (and hopefully infinitely superior) to your original high level design.

You've probably already heard of it but the mikado method can also be useful in some of these situations.

[_asummers]

I had not heard of this before. I will have to investigate. I found an InfoQ[0] talk on it that I will watch after work.

[0] http://www.infoq.com/interviews/mikado-method-restrurcture-s...

[mcguire]

The "depth-first" approach (I've seen it as well) is a mistake that is largely orthogonal to a top-down/bottom-up style. It looks top-down, but immediately goes off into the weeds and can easily be recognized by statements of the form, "I need an X, so I'm building a Y." As in, "I need a reporting application, so I'm building a logging module", or the '90s Japanese 5th generation computing project, "We need intelligent, communicating systems, so we'll build a Prolog machine."

[moron4hire]

The problem is students don't listen. The majority of people see course work as a necessary evil, to be gotten through, and forgotten after passing the final exam.

[Retra]

"Students don't listen" is never the problem. "Teachers don't teach" is more like it.

[s73v3r]

No, students not listening can often be the problem. You can be the greatest teacher in the world, and still there will be a few students who don't want to listen.

[Retra]

But you can't be the greatest teacher in the world.