Fog Creek Software
Discussion Board

How to plan a web app


I have been envolved with web applications for a year now, mostly doing Perl + MySQL stuff. And now i come to realize that i just can't figure out how to implement all the good software creation practices that are discussed by Joel and on this forum.

I am now trying to actually make a detailed plan for the app that i am going to write. Let's assume that this is a Weblog. I just don't know how to break all the work that i have to do into small tasks that can be put into task management software, etc.

I always come up with a detailed step by step description of what a user do and what the app do, how they interact, but it seems to me that i miss the big picture, it just doesn't feel right to me and I never finish this planning work and just go on with the code, without actual planning.

Can somebody please explain me on a simple Weblog example how to plan software development? I am searching for a simple straightforward technique, but any real world example would be great!

Monday, May 20, 2002

People frequently confuse planning with scheduling. 

Planning is an ongoing, day-to-day process of decision making when new information comes to light. 

The belief that anyone can produce a detailed schedule without knowing everything on a new development project is just another management fantasy.

It also ignores changes that are bound to occur as the project progresses.  Sticking to a detailed schedule when new information is known is merely stupidity in action. 

Management is not the practice of forcing conformance to schedule... it is the day-to-day planning and making those hard decisions.

But I commend you for trying... it's one way to totally understand the limitations.

Joe AA.
Monday, May 20, 2002

Start with Use case analysis.

1:  Who are the people that use the application.  Usually you will have at least 2, the everyday user and the administrator.  Figure out what kind of things tey want to do.  For a web log, you may start with two use cases:  Read message, add a message.  POsbbily a fourth for adding a new topic.  Sketch out a simple UI to support each of the uses cases.  Don't be afraid to break use cases down into smaller ones, as this is the primary place where you do top down design. At this point, start your data model.  Figure out what tables you are going to need to support the UI you have just sketched out.  Keep things in the highest normal form you can denormalize later using Code/Views etc. 

Keep things simple.  start out with the absoute minimum amount of functionality you will need to get a wortking app.  Actual;ly, start with Hello World, and work towards a functional app.  Build unit tests for everything.  Don't over design.  Don't try to do too much at once.  Implemnet your most important use case first.

Monday, May 20, 2002

I stumbled onto this several days ago at Borders:

"Building Web Applications with UML" by Jim Conallen
ISBN: 0-201-61577-0

I can't truly recommend it (yet), since I haven't completed it, but I'm about 1/2 way through and, although simplistic at times for the more seasoned developer, it's given me some great ideas on how to tackle some of the challenges you appear to be facing.

Any other recommendations from the group would be great, as well.

Jeff MacDonald
Monday, May 20, 2002

I tried to use that book (I happen to be teaching UML BTW).

Using the stereotypes for any kind of real app is impossible.

Use case modeling is fine if you want to get a rough sketch.

Domain modeling is also good for UML, as well as state machines modeling (the diagram is quite extensive).

But for the spec itself, do yourself a favor and sketch the screens on paper and connect them with arrows.

First of all, use a decent framework for the web app (I use struts, which is now really useful with its 'Tiles' extension). So you have a decent architecture at a low price (and benefit from the improvements others are making).

One good thing to keep in sight is the data access stuff. I would love to use for the data access layer but they don't (yet) have the Java version. So, you have to go back to one of those lower grade frameworks like JRF (Java Relational Framework) for the persistence.
For any real web dev, use the Java Servlets platform, they are maintainable and can scale.

Just my EUR .02... But they proved to be working in production applications (especially with a good caching mechanism - you may want to look at oscache for that).

Philippe Back
Tuesday, May 21, 2002

As for the application, have a look at your actors:

- guest (the guy reading your prose)
- registered user
- administrator (you may want to have some delegates)

[for the weblog, you may end up being the only user, so you have guests and administrator]

As for those actors, have a look at their goals towards the system and which events they will generate or receive, as well as which data flows in and out of the system.

Then chunk the list down into pieces.

- Log entries management:
  - create new log entry
  - preview log entry
  - publish entry
  - remove entry
  - modify entry
- Reports:
      - daily report
      - weekly report
      - ...
- User management
      - modify password
      - lock user
      - unlock user
      - ...
- Authentication
    - login
    - logout
    - ...


  - Weblog usage:
    - Home page:
      - Main news
      - Sidebar
      - Online people on the site
    - Detailed view


Then you take the nice excel sheet from Joel and you give an estimate for creating every single part of the above list.
Remember, you have to create the development environment (directories, CVS entry, ant tasks, appserver environment, editor) and the basic structure of the app (e.g. have struts working properly with a clean blank application). So be sure to plan for it.

Then feature by feature, put a time estimate for (and this for every single screen in the feature):

- screen creation
- objects supporting the screens (formsBeans, domain beans)
- logic for managing the screen (state machines, acces control etc)
- database tables and constraints and indexes (+initial data rows to get the ball rolling)
- database access code and queries (SQL SELECT|UPDATE|INSERTS) or triggers or stored procs.

Then you will see that it will lead you to spend an awful lot of time to get the thing done and that's where you will put priorities ! ... and do the simplest thing that you can get running. After that, this should build your motivation to spend all your nights on the beast :-)

Have a check at for something better than excel to arrange your tasks. Well he moved that here: and I guess that you will now have to pay for it.

Hope it helps,


Philippe Back
Tuesday, May 21, 2002

*  Recent Topics

*  Fog Creek Home