5 ms·

Ask HN: Before I write a single line of code, I

13 points by relaunched 11y ago

I'm about to start coding a new project, that is a little more sophisticated than my usual tinkering. So, I've been thinking about the primary use case, sequence diagrams of the systems, the data structures and the like, and I still haven't written a line of code. How do you organize yourself before starting to write code? What works and what doesn't? Why? Or, is it just better to start coding and figure it all out on the fly?

weinzierl 11y ago
... set up version control. Thankfully nowadays this is basically git init for me. In the past it involved much more.
jmnicolas 11y ago
I always model the database first then I start coding. In my experience if the DB is right the rest is easy.
- collyw 11y ago
  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.
deleted 11y ago
[deleted]
rman666 11y ago
Get a Mt. Dew
philippnagel 11y ago
… prepare lots of tea.
bjourne 11y ago
> 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 11y ago
  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 11y ago
    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 11y ago
      You must do some poor planning.
krapp 11y ago
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.
EdSharkey 11y ago
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 11y ago
  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 11y ago
    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.
allendoerfer 11y ago
… write down the features of some extremely restricted version of an MVP and finish that first, applying YAGNI as strict as I can.
rhapsodic 11y ago
Think.
e19293001 11y ago
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
d23 11y ago
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.
Mizza 11y ago
README.md http://tom.preston-werner.com/2010/08/23/readme-driven-development.html http://tom.preston-werner.com/2010/08/23/readme-driven-devel...
1arity 11y ago
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.
zakvyn 11y ago
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)

13 points by relaunched 11y ago

weinzierl 11y ago

... set up version control. Thankfully nowadays this is basically git init for me. In the past it involved much more.

jmnicolas 11y ago

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

collyw 11y ago
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.

deleted 11y ago

[deleted]

rman666 11y ago

Get a Mt. Dew

philippnagel 11y ago

… prepare lots of tea.

bjourne 11y ago

> 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 11y ago
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 11y ago
  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 11y ago
    You must do some poor planning.

krapp 11y ago

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.

EdSharkey 11y ago

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 11y ago
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 11y ago
  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.

allendoerfer 11y ago

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

rhapsodic 11y ago

Think.

e19293001 11y ago

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

d23 11y ago

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.

Mizza 11y ago

README.md http://tom.preston-werner.com/2010/08/23/readme-driven-development.html http://tom.preston-werner.com/2010/08/23/readme-driven-devel...

1arity 11y ago

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.

zakvyn 11y ago

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)