Back to Development

Pascal's Way of Doing Application Design

I'll break it down into, hopefully, easy to follow steps. Even if you've never written software, you should be able to at least design an application. There isn't much magic involved.

This isn't a guide for large company employees. You probably have procedures, board meeting requirements, ass kissing needs, stuff like that. You may or may not end up sending people to the moon, we'll just be doing a simple application design. I usually take several pieces of blank sheets of paper, preferably with a funny color.

Do I actually work like this?

Good question, and the answer is yes. I use these steps, but mostly in a loop. Start with one, and then loop through 2, 3, 4 and 5 until done. It is like a good massage. There is a pattern to it, but you never rigidly adhere to it. We're not machines! As you can see I do actually create the colored pieces of paper. I find them very, very helpful.

Step 1: Define The Problem.

For ObDough I started out with:
"I want to extract the invoice lines from application X and send them to the insurers."

That isn't enough to do an application, but it is a start. Write it at the top of one of the sheets. Underline, leave some space for the application name (I never know them at this point), and another line.

Step 2: Define the scope of the problem.

For ObDough, I had some history of doing a previous very similar application. This made it simpler do create a basic problem scope. Right here, you'll be tempted to ask the big question 'GUI Application', 'Web application', 'Java application', 'batch job'. Please don't do that. You have no idea what you actually need in human interaction, so how can you know what the right tool is?

At this point, list the things you want to do. Add them to the sheet you just created. I generally feel I have enough when I fill about half to two thirds of the sheet. I usually do three to four items here first, and then go to step three, four and five and then go back here to add some more.

The ObDough List:

1. extract from sybase
2. for multiple practitioners
3. create disks, accompanying letters and dymolabels to send them
4. make something we can sell
5. low to zero install and maintenance hassle. Non technical users.
6. Do reports on the declarations:
   • Open
   • Money received
   • per month, per year.
7. handle corrections:
   • resend entire (corrected) declaration
   • new based on old
   • by phone
   • mailed by insurer
8. (bulk)check patient details with insurers
9. record results back from insurer

Step 3: Choose a sword.

How you choose is wholy up to you, the amount of money you can throw at the problem, the tools you know. The list goes on.

For ObDough, I briefly considered the following four solutions:

1. Solve everything by extending the existing patient administration system.
2. Create a Tcl script to run as a batch job, use existing features in the patient administration.
3. Create a Windev GUI application
   1. as a separate application which synchronizes with patient administration
   2. grafted onto the sybase database used by the patient administration.

Why not the other solutions? Extending the existing system is not possible, as it is a COTS, closed source product with no public API. The Tcl script solution would not handle corrections easily, and would not sell easily (no sexy looks) and the Windev grafted onto the existing database would mean paying close attention to locking strategies by the existing application, would severely limit the RAD power of Windev and would incur a rather large additional license cost for database access.

Side note: I immediately discarded a web based solution (No close match, printing usually troublesome), a deplhi solution (I want to try that tool, but the ROI was too small for this project), a tcl gui application (design tools not powerful enough for me)

Of course, during the design, you may want to keep your options open. Just remember that you need to know your sword for step five.

Step 4: Roughly sketch a database model

Think of all the things you need to store in your database, put them on the sheet so you can draw boxes around them and relationship lines between them. This is a logical model, not a real table structure! I usually start by putting the one or two central pieces of data near the middle of the sheet. Don't do any actual tables yet. That will interfere with the next step!

Here is mine. The numbers indicate the order in which I added the items.

Step 5: Write down the (user) actions

For ObDough I have:

• Print dymo labels
• Add/edit practitioner details.
• Add/edit patient details
• Add/edit declarations
• Make declaration (disk)
• Print a cover letter
• Synchronize patients from patient system
• extract invoice records from patient system.
• Add/edit invoice items not found in patient system.
• (bulk)check patient details
• Make corrections to declarations
• Quickly lookup declaration (correction by phone, mailing)
• send declaration
• Print monthly, etc. reports
• show open declarations

Step 6: Define some tables

The reason I draw them is twofold: It is a sanity check for the list I made above. The number of tables is a good indication for the scope of the project. Too few and you've likely skipped some important requirements, too many and you should reconsider your budget. Additionaly, it really helps in step 7. For ObDough I came up with these tables:

1. Practitioners
2. Insurers
3. Patients
4. Declarations
5. Declaration-lines
6. Declaration-statuslines
7. declaration-runs

For me that was the confirmation that my design matches the scope of the project.

Step 7: Time requirement, the customer quote

Done that already? Go do it now.

Now you're done?

Add all the figures together on one of your sheets.

So. Now you know how much time you'll spend implementing the project. Multiply by your hourly wage, give your customer a quote and go write software. Wow. That was easy!!!

Or maybe not. The numbers, to me anyway, represent relative effort required between different features of the project. The problem is, I have found, while you figure in the individual pieces, you forget the fact that everything will be interacting with each other. That will incur at the very least 50% extra time. And then you will need some bonus multipliers for things forgotten now, unexpected problems/interactions and experience. When you just start out, this is your second or third project. Just guess some numbers, and multiply those by 5. Trust me, it may sound like a lot, but try to be realistic - you're a beginner, part of your time will be spent learning new things. Once you are more experiences, you've been doing projects on and off for the last four years now, multiply by 2 to 3. You've now learned what the real cost of a feature tends to be while wielding your worn in sword, a factor 2 to 3 will cover most other things. When you get really seasoned. Multiply by 1.5 to 2. You always need the 1.5 (once you become a Guru, which I am not, the numbers may be right as hours.)

Now multiply by your hourly wage, and then spend 30 minutes looking for a COTS solution and think of a better project if you find one which solves your needs...

Take a look at all my sheets again, the red numbers are the relative time requirements. On the tables sheet, you'll find that I multiply by 1.5. For this project, anyway.

Go Code

Back to Development

Copyright © 2006 Pascal Scheffers. Version 0.9, 28-feb-2006
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike2.5 License.