

Coding backwards - jobeirne
http://jameso.be/2011/08/19/coding-backwards.html

======
gte910h
This is just top down development.

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
I acknowledge that what I'm doing is "about as top-down as you can get" in the
article.

~~~
rhizome
Concepts without context are merely jargon. It's not apparent from your words
that you are referencing the pre-exisiting idea of top-down/bottom-up, and
thus read as your own personal slang.

People probably gloss right over it while reading unless they're personally
familiar with the practice, but still have to post to HN for clarification
(hint hint).

~~~
gte910h
You sure he knew of top down development before I mentioned it?

~~~
rhizome
Nope. It could just as easily been lucky word usage letting him play it off
("of course I was using it that way!") as much as being decontextualized
jargon ("of course I was using it that way!").

------
shaggyfrog
Amazon takes this to the extreme and writes the press release for the product
first.

[http://www.quora.com/What-is-Amazons-approach-to-product-
dev...](http://www.quora.com/What-is-Amazons-approach-to-product-development-
and-product-management)

~~~
qntm
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).

------
nickolai
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

[http://science.ksc.nasa.gov/shuttle/missions/51-l/docs/roger...](http://science.ksc.nasa.gov/shuttle/missions/51-l/docs/rogers-
commission/Appendix-F.txt)

    
    
            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.

~~~
gte910h
> 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.

------
Breefield
I found this a while back, (<https://zetabee.com/cashflow/demo>) Quite useful,
exactly what he's proposing too.

<http://news.ycombinator.com/item?id=2333570>

~~~
jobeirne
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.

~~~
raintrees
Happy to see you reference Django - This is also what I got when an article
suggested designing a Django site by implementing the URLs first, then the
rest of the app to implement the URLs.

------
viraptor
Why does this appear again and again? Why isn't it on every single programming
related course:

    
    
        amount = 14.,
    

Is just asking for trouble...

~~~
law
Maybe he's referring to bitcoin :)

But yes, money doesn't require floating point precision. Represent it as an
integer (of cents) and add the decimal in yourself.

~~~
mattmanser
It's quite common to need more precision than that. Interest is a good
example.

Also 0.025 cents per widget. Perhaps in your world 1 cent is the minimum
anything in the world can cost. The rest of us, alas, live in the real world.

~~~
law
OP said this is for personal finance...very rarely would you need more
precision than that. Also, 1 cent _is_ the minimum that anything can _cost_.
Do you happen to have any 1/10 cent pieces lying around? That's a financial
fiction.

~~~
viraptor
Telephony providers quite often deal with fractions of the smallest amounts. A
Skype call to UK will cost you 1.4p/min for example. It's quite normal for the
actual company to have per-second rate and keep it as a 1000th of a penny
number.

You might not have a 1/2p coin, but you can have 1/2p on your account.

------
jerf
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.

~~~
gabebw
Take this as faddishness or not, but this sounds like README-driven
development from Tom Preston-Werner: [http://tom.preston-
werner.com/2010/08/23/readme-driven-devel...](http://tom.preston-
werner.com/2010/08/23/readme-driven-development.html)

~~~
jerf
Similar, but I shield myself from "DDD" turning into waterfall by doing this
on modules, not projects. It's sort of like how capitalism thrives by
embedding a lot of top-down control economies ("corporations") within the
larger framework of freedom; a top-level bottom-up "Agile" framework can
benefit from the occasional use of a top-down design process embedded within
it, and you aren't obligated to angst about the internal contradictions,
because there really aren't any.

------
kaylarose
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).

~~~
phamilton
In an MVC setting (be it webapp or normal app) I find that I frequently write
my Controller Last.

I design the View (top down), then I design the Model (bottom up) and connect
them up with the Controller.

~~~
alttab
This comment is under rated. Think about the intteraction (view), write tests
and document the model, then fill it out. Correct tests, fixtures/factories
and model as necessary.

The controller should be thin, make 1 or 2 calls to the model while mapping or
cleaning input, then the response. If your controller actions are thick then
your model sucks and isn't encapsulated or you have complicated response
logic. Avoid these by writing great encapsulated models. understand the
presenter pattern.

I've worked in sections of code that doesn't consider my opinion as advice and
dechipering wtf was going on was anything but quick, and I probably introduced
bugs because I couldn't understand how everything worked.

Tldr, controllers are glue code. Applications made entirely of glue doesn't
even sound right saying it.

------
ww520
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.

~~~
xtracto
>This is basically test driven development

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
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 ;)

------
stdbrouw
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...](http://tom.preston-
werner.com/2010/08/23/readme-driven-development.html)) 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
It's an interesting thought, but doing this for anything on any real scale is
going to bite you in the ass when it comes to use cases.

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
Congratulations. You've discovered TDD without the tests.

~~~
gte910h
Top down development existed far before test driven development. This is just
top down development instead of bottom up development.

~~~
wccrawford
Oh, I know. But tests make it so much easier.

~~~
gte910h
There is an cultural non-acceptance of pre-testing methodologies in some
organizations.

People are angered at the number of tests relative to the size of the code
base, especially if you go with something like strict 100% coverage of
whitebox style tests, etc, where you're virtually guaranteed to have as many
tests as function branches and then some.

Top down is an approach that has value outside the permanent test suite. You
can make a more temporary suite that you use to then fill in the top down
design as well, and then do not maintain.

( _I_ am not sayings tests are bad. I'm just saying functional code is over-
prioritized by some employers/customers, a well tested system is usually a
good thing).

------
toadstone
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?

~~~
Xlythe
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.

------
petercooper
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).

------
njharman
> I’d reverse-engineer a good design by pretending I’d already written one!

Um, I call that tdd.

------
cincinnatus
Always write the user docs first.

