views:

141

answers:

5

As a programmer my first instinct is to start coding, but then again chapter one of every programming book says that you should NOT sit down and code.

So the question is, where to start?

I've given the project some thought, it's going to be a fairly simple web app, kind of a time logging app, to give you an idea.

Even though it's a small project I want it to have great-for-general-public-use quality, and I am willing to even cash out a bit to have a designer do a proper look and feel for the page.

This is a list of things I've thought about:

  • It's going to be in ASP.NET MVC

  • I want it to have the most dead
    simple log-in (a la Instapaper, but
    possible with option to do OpenID, a la SO)

  • Should be able to use it with no log-in too, just session cookie

  • It's going to have several "layers" of usability, from very basic, to a more "dashboard" info tracking.

  • The webpage should very simple to use.

  • Planning on using jQuery for interactivity

  • Will use Linq2Sql

  • I want to start with the MAIN time tracking function, and then add other tools that not all people might want to use, but that more advance users would like (and no is not feature-ism, they are things that really have to go there for the product I want to do)

  • If the page was a little bit successful, I'd like to add mobile apps, so I should have some sort of internal web API?

So where should I start? Class diagrams? Basic "sketch/design" of the app? Workflow Diagrams? Mission statement?

And what should I do after that? When is "good" to start coding till I fall asleep?

Thanks a lot!

+3  A: 

This question is a bit subjective but here is a very short explanation of what i do.

I always begin with my data. What do I want to store and how? Then I build my database and indexes.

I then create a data layer project and import my db as a linq2sql class.

Then I decide on the first bit of functionality i want to sign off. perhaps enter a time.

I then write my test cases in a test project. then i make each test pass by writing the code in my data repository layer.

then i write a controller and finally my views.

then i move on to the next story point or piece of functionality

griegs
So you would say work in a DataDrivenDesign? How would you differentiate that from starting to code right away? (vs starting to build database right away)?
Francisco Noriega
I've never said don't code right away. If you want to write all your tests first in a TD design then that's actually a great thing to do. As you write your tests you get a very clear picture of what your models will need to look like giving you a better model and code IMO.
griegs
+3  A: 

but then again chapter one of every programming book says that you should NOT sit down and code.
I'll humbly disagree with those books (which books, btw?).

Sure, if you plan to create a better version of Microsoft Word, you'll need some relevant experience and a bit of consideration. But creating a simple webapp with few pages isn't such a big deal: most web frameworks will already provide architecture carcass for you (like MVC pattern), you just need to 'fill in spaces'.

So, my suggestion is to start with core functionality and grow it bit by bit. Just forget about class diagrams, mission statement and all that crap :)

PS Before you start, it might be useful to check existing applications dealing with this problem: maybe you'll want to borrow some ideas.

Nikita Rybak
+1 yeah and what do you actually gain by reading everything and not trying it out? There's such a thing as refactoring because no one gets it right the first time no matter how much you read IMHO
griegs
+1 I don't agree with those books either :)
naikus
I imagine they're books for people who do software development professionally or beginners who aspire to be professional web developers. Sure, if you're only creating a small personal site, it's not going to be a big deal if you take a bottom-up approach (or write unmaintainable spaghetti code for that matter). But if you aspire to more than that, you may as well get into the habit of doing things the right way. Also, MVC frameworks do not preclude the need to design your application. There are poorly written/designed apps using every framework out there.
Lèse majesté
+1  A: 
Lèse majesté
+2  A: 

Which book(s) say that? I don't always agree with that. Also I beg to differ that you should start by data modelling, especially in case of apps that have a web user interface. Here's what I'd do:

  • First step Start with UI (prorotyping). Do it in either html or use a tool like balsamiq This will give you (and your end users) an idea what functionality you want in your application. This will drive your data model and your controllers. IMO UI is the most important feature of your app because it will be directly interacting with the user. This notion is often neglected.

  • Break down the app into modules if possible. e.g user management(registration, login, logout, roles) timekeeping, admin, etc.

  • Design your data classes or data model and data access classes. Again the UI is going to determine what data you want your data access classes to fetch, etc.

  • Start doing the UI simultaneously, with controllers. Take on each module one after the other.

  • Evolve your design constantly. This also includes the UI. Evolving does not mean put in hacks. If you think you need to re-design, do it.

  • Important: Write a bare minimum app (with only the most important fatures) that works well. Build on it.

  • Read the 37 signal's getting real for inspiration

So a good time to start coding is "Right Now!"

naikus
bump for "UI..."
annakata
+1 for the link to the getting real link , and I have a license for balsamiq so I'll be using that
Francisco Noriega
I've been reading the book, I'm finding it really good!
Francisco Noriega
@bangoker I know man, Its awesome, I go back to it again and again whenever I feel I'm loosing focus
naikus
+1  A: 

Personally, I'd suggest some pencils and a big stack of paper. Think about your use cases, rough sketch the work flow, then from work flow think about how that be done in UI. Do rough sketches of those UIs, and actually go through the flow via you're paper prototype. Is there going to be some reporting functionality in there? Are you sure you've captured all the data and functionality you want to do this go round? Build a prototype, remember, prototype means something that can be thrown away, so do it in something quick, like rails, or grails, not sure what the analog would be in the .net world, but be sure that you're using good development methodologies, like TDD. Does the prototype suck? No?

Now you're ready for round 2, refactor the prototype to your target technology, if its helpful you can create all the diagrams and such you mentioned earlier. Found something you missed? Go back to step one. But the nicest part, is in the meantime, you have working software that at least doesn't suck, while you're getting the rest going.

Repeat until either you can't stand it anymore, or you're rich enough that you can hire other people to do this for you! ;)

mezmo