Ask HN: How do you begin the process of developing a web application?

That's pretty much where my webdev style comes from too --- library design --- so that, how I write C library code (foo_new(), foo_release(), foo_get(), foo_put(), etc) just gets expressed as (say) Sinatra handlers.

Then I call the library in different ways to build something useful out of it.

Never thought of it that way, but that makes sense to me.

I buy a $1 project notebook, put the name of the project on the front page, and start jotting down things in the notebook. This could be database tables, paper mockups, notes on features to add, roadmap, whatever.

Eventually, on a day I'm feeling particularly inspired, I can't stop myself from coding. This sees me make a quickie Rails development environment and push hard to get One Cool Thing accomplished. As long as I have one thing done, further attempts at coding don't feel like breaking ground (hard work!), they're just extensions to existing functional code.

You'll laugh, but the One Cool Thing I did with Appointment Reminder was making it so the logged in user can switch the color scheme for her pages. This has rather little practical utility but it was quick to do and satisfied my monkey brain: "visual changes == making progress, ergo, five visual changes == LOTS of progress."

Often the first thing I do is something with domain logic that I can only execute through the console to start out with. Crikey I love my Rails console. Right now for client work I have a program which goes to a particular government agency, slurps down a gigabyte of data, does some number crunching, and then tells you things any well-informed high schooler knows about a particular subject. The difference between the program and the well-informed high schooler is that the high schooler would get bored after listing 5 or 10 of the facts but the program can punch through thousands.

After following the anti-planning approach for a long time, with dozens of half-finished pet projects to show for it, it seems approximately as good as procrastination (for me). If I get excited about something and start tapping away at the keyboard, I'm often left with a couple thousand lines of code and the realization that there are some major components that could have been thought out much better. The joy I originally had in creating it takes a major blow when faced with major rewrites (and the thought of all of the wasted time that could have been better spent thinking about it).

Nowadays, I'll let a project incubate in my head for a few days/weeks/months and approach the keyboard with a solid plan in mind and a well reasoned, well designed feature-set/interface.

But if you really don't have time for an incubation period, write your schema out first. This exposes so many design flaws in the beginning while it's still very easy to manipulate. This should be the "contract" you sign with your blood for the vast majority of apps you'll write for the web, and you should be spending a good deal of time thinking about it (for any non-trivial app) then, not later when you're atop a few thousands lines of uselessness.

Many project float around my head for a bit of time. If something seems persistent I tend to make some notes on it to track ideas, features, core concepts, whatever.

If I decide to actually do it, I kick off a Ramaze project. This lets me start fast, light and simple while giving me a solid migration path should the app get complex. Last thing I want to do is have to change frameworks midway through; it'll be an excuse to not do stuff. I can start with a single-file app and build out as much as needed.

I use Rhesus to jumpstart such things, with personalized templates for assorted needs. I get the layout I want with the core files I know I use, skip the cruft.

Then I iterate. I put pretty much every app into a git repo so I can easily try stuff and not get lost down some dead end.

I also like using Selenium to drive test cases from a user perspective, see that I have important site-wide behavior in place and working. And it lets me automatically "walk" an app and mull over the big picture.

I like to start with the underlying structure of the data as well, which for database-driven web sites means the schema.

"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious." -- Fred Brooks.