How do you plan your web app?

Question

I am wondering how everybody plans their web apps. Do you write out a list of functions and tick them off when done? Do you have stacks of paper with Use Cases all over them?

What is the sweet spot between not planning at all and doing so much planning that your deadline has passed before you have even started?

EDIT: Most of the web apps are relatively small and I normally use a "shoot-from-the-hip" approach. I'm looking for suggestions for small e Commerce sites, CMS's, etc. Not huge but usually with a fair amount of addons as he years go by.

Answer 1

Well it all depends on the size of your web app and the team building it. Are you planning on having 10+ developers working on it or is it just you ?

Here were there is usually just me working on an app its a matter of talking to the customer and understanding the basics of what they are wanting. Once you have that build up a basic framework and add what you think are the bare bones of the app. Once I have that I show it to the customer and find out if I'm on the right track. If I am I find out what features they want to see next and litter my PHP/J2EE code with TODO's. After that I code in those features then go back to the customer and so on. However don't do this if you are working to a strict timetable or have multiple developers as things will get messy very quickly. But this does work for me on small projects with one developer(me) who is having to work on multiple other projects and so keep many customers happy.

Answer 2

I Would say that depends on the size of your web-app, if it's a small app then I tend to go for the shoot-from-the-hip approach - where the web app tends to flow from the database structure (not recommended).

On the other hand a large app I'll tend to split it up into independent modules, find the core functionality and then plan & write that - going for the whole release & release often approach.

This approach allows for each module / section to be independent without having to plan extensively over each feature prior to build

Answer 3

I start off with developing an understanding of what it needs to do, then work out a basic class model to handle the back-end processing. Once I know the data that will be needed by each class, the database design is basically complete, so I can set that up, then write the classes (and tests for each class). Then it's just a matter of writing plugin modules for the framework I use which expose the functionality of my classes as HTML.

This all sounds very structured and proper-software-engineering-processy, but it actually works out as being very fluid and shoot-from-the-hip, because I generally work solo and have a lot of prebuilt common pieces that can be slotted into the framework for any project with only minor modifications.

As far as organizing this, I keep a straight more-or-less prioritized TODO for each project that I use as a checklist of functions/features to add.

Answer 4

At least in my current job the customers rarely know what they want. They only think they do. That's why we try to look at the features they've requested and implement them in the most generic way possible.

The clients almost always want something completely different than what we started with. As we work with several projects with similar features and we preserve the right to use our code in other projects we've ended up with a nice set of features that can be used in several projects with little or no modifications.

Answer 5

I am currently co-managing some web-Development projects. And I use Word & Excel to manage List of features, Analysis, Budget, and Team (Tasks & timeline). It’s relatively easy and simple to implement to all the team. We synchronize documents with Google DOCs. All projects are small, and the team is also small, 2 developers 2 co-Project Leaders. I know there is some tools to do this. But we manage very well with this.