Man, and here I thought that documentation-driven development was the top of the ladder (above test-driven development, above just writing the code first).
Top Down approach works great for smaller or exploratory projects, yet i have had a few unpleasant cases of "cornering myself" - cases where a significant rewrite was pretty much required because a crucial implementation constraint was not visible from the top.
With small or ill defined projects, throwing out bits here and there is expected - but i suspect the method can pose serious issues to larger ones.
Example : Quote of Feynman's report on the space shuttle
The Space Shuttle Main Engine [design] was handled in a different manner,
top down, we might say. The engine was designed and put together all
at once with relatively little detailed preliminary study of the
material and components. Then when troubles are found in the
bearings, turbine blades, coolant pipes, etc., it is more expensive
and difficult to discover the causes and make changes. For example,
cracks have been found in the turbine blades of the high pressure
oxygen turbopump. Are they caused by flaws in the material, the effect
of the oxygen atmosphere on the properties of the material, the
thermal stresses of startup or shutdown, the vibration and stresses of
steady running, or mainly at some resonance at certain speeds, etc.?
How long can we run from crack initiation to crack failure, and how
does this depend on power level? Using the completed engine as a test
bed to resolve such questions is extremely expensive. One does not
wish to lose an entire engine in order to find out where and how
failure occurs. Yet, an accurate knowledge of this information is
essential to acquire a confidence in the engine reliability in use.
Without detailed understanding, confidence can not be attained.
A further disadvantage of the top-down method is that, if an
understanding of a fault is obtained, a simple fix, such as a new
shape for the turbine housing, may be impossible to implement without
a redesign of the entire engine.
> cases where a significant rewrite was pretty much required because a crucial implementation constraint was not visible from the top.
That happens sometimes no matter which way you go. I've had the assumptions of what lower level libraries work off have to be completely rewritten as well because the top level system didn't make sense with the verbs and nouns given to it when you looked at it full on in the end.
The difference between redoing code gluing together lower level modules and redesigning a spacecraft make that anecdote perhaps a bit of an exaggeration on the details of work required when Top down fails.
Awesome! While I'm a little bummed that I no longer have a good excuse to implement this and brush up on my Django/JavaScript, this is exactly what I was looking for. Thanks.
I sometimes like to write the documentation for the module, to varying degrees of completeness, before I write any code. I find that for infrastructure modules it really helps to make sure that you're writing an API that serves the API user, instead of serving the API designer, because you discover right away if you're writing an idiotic API.
If you want to smear a thin patina of faddishness over it, you could declare the documentation is a form of TDD, except that we're testing something that automated testing simply can't, which is the effective usability of the API from a human point of view. But then, I'm not too worried about yon thin patina of faddishness. Sometimes it's the right tool for the job, often it isn't.
This is how I approach project design as well (after the POC phase): Top down (API first). Then (not covered in parent article) bottom-up, (a.k.a. what building blocks does that API need?). _Everything else is just glue._
If you exclusively do one or the other, you end up in bad territory. Top-Down: Results in excessively bloated API logic. Bottom-Up: You end up with a muddy API, that is overly complicated & hard to use (it's more of a RPC lib than an API).
Good work in coming up a unknown design approach by yourself.
This is basically test driven development, or before that the object orient analysis. That guy interviewing you was following the object orient analysis approach. OO is sort of out of favor with all the functional fads in force.
OO Analysis is actually quite elegant, despite all the complication added later on. It can simply go by this:
1. Describe in English what your system will do. Be specific about the actors involved and their actions.
e.g. Let a user projects earnings and expenses over a period of time; summarize net effect.
2. Pick out all the interesting nouns and all the verbs. The nouns become your classes and the verbs become the methods.
3. Pick out the interactions between the nouns. Added those as methods on the receiving classes. Figure out the data of the interaction, which becomes the method parameters.
From that you can do the TDD approach to build the tests to exercise the skeleton code according to your system description. And from that fill out the actual functionality of each method as you run each unit test.
I thought the same thing. Just a week ago I finished reading the "Pragmatic Unit Testing in Java" book and after skimming through the article I remembered the "design unit tests first" approach which forces you to think about the API (or exported methods).
I have not used it myself, but it seems quite sound.
I'm but a lowly humble indie developer unschooled in techniques such as test driven development, yet I often find myself doing something like what the author describes.
The bit that rings true for me is that he decided to "write out a script using the yet unwritten API".
I have found my designs to be much more succinct & workable when instead of writing a bunch of classes then figuring out how to get them all to play together, write the code where the proverbial tyres hit the road & then go back to fill in the details.
I'm sure the more experienced software engineers out there would facePalm at this method & it's obviousness, but it gets the job done ;)
We're really coming full circle here, eh? Next thing you now people will start advocating the waterfall method again.
More seriously though, it all depends on what you're writing. Sometimes TDD works best, README-driven development (http://tom.preston-werner.com/2010/08/23/readme-driven-devel...) is really nice for certain projects, sometimes top-down is a good thing and sometimes just hacking away without having a clue about what you're doing turns out surprisingly well.
There's way too much discussion about methodologies and way too little about when they shine.
I'm more curious about what the alternative is because this is my default mode of programming. I don't see what's backwards about it. You establish what you need in the module first, then code. What else can you do?
The way I'm most comfortable programming is a sort of head-first approach. You have a feature you need and an idea of how to design it and then you just start writing. It should compile at any time (within reason), and you'll see the bits and pieces of your feature come to life. You'll catch bugs quickly because you won't have written much at any one time.
It's usually messier, though. An hour of just cleaning the code really helps as I always end up with a method that should have been broken up into 2 or more.
This is quite a common approach in the Ruby world, where issues of API design and readability frequently trump other concerns (with both good and bad outcomes).
[+] [-] gte910h|14 years ago|reply
Works great in many cases instead of bottom up development. It really is a design methodology:
http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design
You just happened to be designing as you were going along coding
[+] [-] jobeirne|14 years ago|reply
[+] [-] shaggyfrog|14 years ago|reply
http://www.quora.com/What-is-Amazons-approach-to-product-dev...
[+] [-] qntm|14 years ago|reply
[+] [-] nickolai|14 years ago|reply
With small or ill defined projects, throwing out bits here and there is expected - but i suspect the method can pose serious issues to larger ones.
Example : Quote of Feynman's report on the space shuttle
http://science.ksc.nasa.gov/shuttle/missions/51-l/docs/roger...
[+] [-] gte910h|14 years ago|reply
That happens sometimes no matter which way you go. I've had the assumptions of what lower level libraries work off have to be completely rewritten as well because the top level system didn't make sense with the verbs and nouns given to it when you looked at it full on in the end.
The difference between redoing code gluing together lower level modules and redesigning a spacecraft make that anecdote perhaps a bit of an exaggeration on the details of work required when Top down fails.
[+] [-] Breefield|14 years ago|reply
http://news.ycombinator.com/item?id=2333570
[+] [-] jobeirne|14 years ago|reply
[+] [-] viraptor|14 years ago|reply
[+] [-] law|14 years ago|reply
But yes, money doesn't require floating point precision. Represent it as an integer (of cents) and add the decimal in yourself.
[+] [-] jerf|14 years ago|reply
If you want to smear a thin patina of faddishness over it, you could declare the documentation is a form of TDD, except that we're testing something that automated testing simply can't, which is the effective usability of the API from a human point of view. But then, I'm not too worried about yon thin patina of faddishness. Sometimes it's the right tool for the job, often it isn't.
[+] [-] gabebw|14 years ago|reply
[+] [-] kaylarose|14 years ago|reply
If you exclusively do one or the other, you end up in bad territory. Top-Down: Results in excessively bloated API logic. Bottom-Up: You end up with a muddy API, that is overly complicated & hard to use (it's more of a RPC lib than an API).
[+] [-] phamilton|14 years ago|reply
I design the View (top down), then I design the Model (bottom up) and connect them up with the Controller.
[+] [-] ww520|14 years ago|reply
This is basically test driven development, or before that the object orient analysis. That guy interviewing you was following the object orient analysis approach. OO is sort of out of favor with all the functional fads in force.
OO Analysis is actually quite elegant, despite all the complication added later on. It can simply go by this:
1. Describe in English what your system will do. Be specific about the actors involved and their actions. e.g. Let a user projects earnings and expenses over a period of time; summarize net effect.
2. Pick out all the interesting nouns and all the verbs. The nouns become your classes and the verbs become the methods.
3. Pick out the interactions between the nouns. Added those as methods on the receiving classes. Figure out the data of the interaction, which becomes the method parameters.
From that you can do the TDD approach to build the tests to exercise the skeleton code according to your system description. And from that fill out the actual functionality of each method as you run each unit test.
[+] [-] xtracto|14 years ago|reply
I thought the same thing. Just a week ago I finished reading the "Pragmatic Unit Testing in Java" book and after skimming through the article I remembered the "design unit tests first" approach which forces you to think about the API (or exported methods).
I have not used it myself, but it seems quite sound.
[+] [-] 5hoom|14 years ago|reply
The bit that rings true for me is that he decided to "write out a script using the yet unwritten API".
I have found my designs to be much more succinct & workable when instead of writing a bunch of classes then figuring out how to get them all to play together, write the code where the proverbial tyres hit the road & then go back to fill in the details.
I'm sure the more experienced software engineers out there would facePalm at this method & it's obviousness, but it gets the job done ;)
[+] [-] stdbrouw|14 years ago|reply
More seriously though, it all depends on what you're writing. Sometimes TDD works best, README-driven development (http://tom.preston-werner.com/2010/08/23/readme-driven-devel...) is really nice for certain projects, sometimes top-down is a good thing and sometimes just hacking away without having a clue about what you're doing turns out surprisingly well.
There's way too much discussion about methodologies and way too little about when they shine.
[+] [-] pseudonym|14 years ago|reply
Unless you program every single view/controller out with no model, which means you're throwing together reams of code with no way to test it.
Interesting as a first step if you're stuck, though, but I don't see a lot of worth in this over pseudocoding the app as a design step, either.
[+] [-] wccrawford|14 years ago|reply
[+] [-] gte910h|14 years ago|reply
[+] [-] bryanlarsen|14 years ago|reply
[+] [-] emehrkay|14 years ago|reply
[+] [-] toadstone|14 years ago|reply
[+] [-] Xlythe|14 years ago|reply
It's usually messier, though. An hour of just cleaning the code really helps as I always end up with a method that should have been broken up into 2 or more.
[+] [-] petercooper|14 years ago|reply
[+] [-] njharman|14 years ago|reply
Um, I call that tdd.
[+] [-] cincinnatus|14 years ago|reply
[+] [-] sfgfdhgfdshdhhd|14 years ago|reply
[deleted]