
Ask HN: Before I write a single line of code, I - relaunched
I&#x27;m about to start coding a new project, that is a little more sophisticated than my usual tinkering. So, I&#x27;ve been thinking about the primary use case, sequence diagrams of the systems, the data structures and the like, and I still haven&#x27;t written a line of code.<p>How do you organize yourself before starting to write code? What works and what doesn&#x27;t? Why? Or, is it just better to start coding and figure it all out on the fly?
======
d23
More advice: think in terms of iterations. You might be thinking of everything
in terms of some holy grail platonic ideal of the project, when in fact you
will hit a number of road bumps and change your mind along the way that may
completely change that.

So start smaller. What's a key piece of functionality that might set a good
foundation you can build off of? Building this has the dual benefit of giving
you a cognitive "win" while starting to work the "bones" of the project into
your muscle memory. You'll have a much clearer idea of what the next step you
need to take is to get it to that larger end-goal.

------
jmnicolas
I always model the database first then I start coding. In my experience if the
DB is right the rest is easy.

~~~
collyw
Pretty much what I was thinking. If there is too much logic at the app level,
its often worth revising your database models. Though a lot of the youngsters
these days don't seem to bother with relational databases.

------
EdSharkey
I'm tired of working for years on hobbies that ultimately get big and I think
can turn into businesses only to find I have built this huge unmaintainable
edifice of untested spaghetti that I have to shelve.

So now, whether it's on the job or on my home project time, I get the git repo
and build scripts squared away with some awesome testing framework that
constantly watches the file system and rebuilds and running my test suite as
I'm working on the code. This way I can do TDD and get higher quality code
more consistently.

~~~
bbcbasic
Is that the obstacle to turning them into businesses? I think getting paying
customers is the hard piece of the puzzle? The cashflow will help solve the
spag-bowl problem. You can hire a chief refactoring officer :-)

~~~
EdSharkey
There are a lot of obstacles to me turning my ideas/hobbies into businesses.
Yes, getting paying customers is the hardest piece of the puzzle. On my last
endeavor, I got way into the server-side weeds with profiles and accounts and
billing. It was a neverending spiral because I had designed something far too
complicated without a test suite; I decided it could never be completed.

I think my biggest challenge was my consistent inability to form functioning
teams around my ideas. I've usually flown solo or been taken advantage of by
my team (me doing all the work, them contributing nothing, waiting to see it
reach "critical mass".) On the last go, I even offered a guy an equal
partnership, but that was not enough and he never committed. It tempts me to
think my ideas were not viable when I could never convince my peers to jump on
the bandwagon. I always had users who seemed to get value out of my services,
and that kept me going.

I've never gotten a huge amount of attention or gotten funded, and frankly I
like the autonomy, so I have never sought any funding. Of course, that means
if I have any hope of getting financial rewards from bootstrapping my hobby
work, I've got to be very organized, which I never have been on past projects.

For my current project, I've decided to open source my new codebase with the
AGPL. In the business I'm looking at getting into, open source is common with
the popular services, but these projects rarely get any outside contributors.
Hopefully I can at least get code reviews, bug reports, and maybe even some
code contributions if followers don't mind assigning their copyrights to me.

On this new project, I've got a really tricked out client-side JavaScript
development environment with Gulp, Webpack, Karma, and Closure Compiler. I'm
really happy with how simple and powerful the build system is, and I'm hoping
that by making it easy to build and test, I can attract devs to join my team.

~~~
brianwawok
Why do you think you need TDD to write logical and tight code? It's one way,
but there are less drastic ways to the same ends.

~~~
EdSharkey
Just for me (YMMV) I find that when I write untested code, I make too many
large cognitive leaps in my changes. My code looks good at the time and it
usually looks well-factored, but entropy and shortcuts always seem to creep in
there. Pile all those errors up over a 5 year timespan on code that slowly
accretes since I'm maintaining it on my leisure time, and I always wind up
with really untrustworthy code and occasional frustrating regressions when I
make changes.

The test suite with good coverage gives me confidence that the code continues
to work as I make changes (no regression bugs.) It's about having complete
trust in my code, no second guessing, and no time ever wasted in a debugger
chasing down issues.

And, I want to be able to cut a build at any time as long as all of my tests
pass and feel confident I'm not shipping a broken build. I've never been able
to do that on any project in the past, and I think it will be one mark of
success on this new project. I've implemented a mini feature toggle system in
my build scripts to make that possible.

Finally, I'm using Closure Compiler with full optimizations in my production
build to do minification. Closure Compiler itself can (theoretically) break
the build with its over-aggressive optimizations, so part of having a complete
coverage test suite is being able to run the tests against the production
build and catch any bad optimizations that CC makes. Because of my
architectural choices, I REALLY need that test suite.

Do I need to write the tests before the production code (do full TDD) or can I
write tests after? Well, I am the type of guy who won't write the tests after
because I always want to move on to the next fun thing. I just force myself to
do it, and take my medicine up front.

~~~
brianwawok
There is a big difference between "untested code" and "tdd code"

There are two different ways to test code.

1) Do the TDD thing. Write 1 test. Code to pass. Repeat.

2) Write code that works. Iterate on it. Refactor, clean it up. Then write
some tests that test the final product.

You can have tested code in both cases, but I claim the code from #2 will look
cleaner than the code from #1.

------
1arity
Check all the news I can find.

And when I'm not procrastinating, I write up a kind of spec, which I then
revise into code sketches, and what I would like APIs to look like.

And then I fill it in. Rinse and repeat.

------
krapp
I think there comes a point beyond which planning can be used to avoid having
the purity of your ideas corrupted by the inevitable messiness of their
implementation. I've recognized it in myself, at least.

The only thing I can suggest is that you put your notes aside, set up a repo,
branch and just write some code.

------
e19293001
Start your project with a plan on a piece of paper and without a computer in
front of you.

Not sure if this comment by edw519 can help you though it works for me.

[https://news.ycombinator.com/item?id=191275](https://news.ycombinator.com/item?id=191275)

------
Mizza
README.md

[http://tom.preston-werner.com/2010/08/23/readme-driven-
devel...](http://tom.preston-werner.com/2010/08/23/readme-driven-
development.html)

------
bjourne
> Why? Or, is it just better to start coding and figure it all out on the fly?

Yes it is. Write code towards the solution and see what it leads you. Then you
might get into a "writers block" and can't decide whether data structure A or
B is best. So you think about it some, decide which one you like and write
more code. Then you might find out that you thought A was best but it turns
out B was better. So you refactor your code base, write some more code and so
on.

~~~
collyw
In my experience it will lead to some half thought through design and a load
of technical debt.

"Weeks of coding can save you hours of planning".

~~~
bjourne
In my experience, you would have gotten just as much technical debt and bad
designs if you so had spent months of planning before typing the first
character of your code.

~~~
collyw
You must do some poor planning.

------
zakvyn
1\. write down business requirement (Break to small stores that you can finish
each story in a day) 2\. write down technical requirement (over all) 3\. write
down expect test cases in English. (When something happen, what is expected)

------
allendoerfer
… write down the features of some extremely restricted version of an MVP and
finish that first, applying YAGNI as strict as I can.

------
weinzierl
... set up version control.

Thankfully nowadays this is basically _git init_ for me. In the past it
involved much more.

------
philippnagel
… prepare lots of tea.

------
rman666
Get a Mt. Dew

------
rhapsodic
Think.

