Creating big applications obviously requires planning but do you guys plan for small applications? For example, creating a small application to record baseball games.... I finished creating DB schema in an hour but I'm not sure if I should move ahead and make changes as I write code or should I think for a day or two about it in depth.....
Absolutely. I delay coding for as long as humanly possible. Mostly because I hate having to re-do work. So I'll usually spec out my schema, sitemaps, full mockups of everything, etc. Then I write my tests, and finally my code dead last.
The point for me is to make all the creative decisions (and to do all the creative waffling and do-overs) very early on in the process, on the whiteboard instead of in the IDE (because it's faster to change functionality during the mockup stage than it is to rip out your code). Once I start coding everything should be spec'd in detail.
Thumbs Up ! I prefer the same but in the office I work in, they focus in getting the product to client as soon as possible and it's just getting tough for developers (ones who care about good practice). However, company is just getting lot of clients and earning very well. It got me thinking whether I'm not being quick to develop.....
Yes, I do. Even if it's not final, at least you have an idea of the direction you're taking. You'll find out quickly if it's the right direction or not. That's the fun about development!
Are you using an ORM? If you're writing a web app (at least in Rails, Django or Flask) you can start once you have a rough idea about your objects and properties (~= schema) and then use database migrations (e.g. with alembic) as you make changes.
If you don't care about your test data, just have your ORM create a fresh set of empty tables for you, each time you change the schema.
+1 for Alembic, it makes database schema changes a lot less painful. It's definitely good to sit down and figure out high level architecture before building, but for small one-off projects code that works today is usually worth more than better code tomorrow.
The point for me is to make all the creative decisions (and to do all the creative waffling and do-overs) very early on in the process, on the whiteboard instead of in the IDE (because it's faster to change functionality during the mockup stage than it is to rip out your code). Once I start coding everything should be spec'd in detail.