How do YOU go about designing your program

[chrisj206]

As i learnt VB when i was younger, i pretty much dived in and started typing things out and pressing F1 for MSDN and 'learnt as i went along'.

So when it comes to creating software, its generally a case of "Right i need to load a file first"...type type. "Now i need to add contents to a listbox" type type.

However im constantly retyping code "ah i need to add hidden ID numbers to these so i can remove them" etc etc.

So i wondered, whats the general "format" or 'check list' you go through when designing and then coding your applications to save time?

Although my way "feels faster" its often a case of "All haste and no speed" after i retype each function.


Looking forward to replys

[greenhorn999]

Personally, I use a whiteboard to sketch out the general flow, important structural arguments/requirements etc. There's a thousand ways to skin a cat so I stay away from specifics in the design phase. Once you have a general flow/structure, it makes the design that much faster (less undoing thing).

That's me. Check this out (Software Development Lifecycle - SDLC) for an idea to see how professionals handle this. I'm a software engineer by trade but I personally stay away from the 'pro' tag.

[BruceG]

Generally, you start with the output - i.e., what is it that your program is supposed to do or produce; and what are your users asking for? To go along with this, if this is a database-oriented app, the database design should be in place before you start coding, as that will be the foundation of your app.

Given the database design and user requirements, sketch out what needs to be on each screen, and how will each screen be navigated to (i.e., what is the "flow" of the app)?

Once you know what needs to be on each screen, I would say you can start coding.

If there are any parts of the requirements that are new to you (e.g. "how do I drag and drop within a treeview?"), do the necessary research, and maybe look at/build a sample app as a "proof of concept" to make sure you see how to do it before incorporating it into your app.

Those are the basics, IMHO. Then of course, you give your users the "first cut" of the app, they come back with changes, and the process repeats itself (generally, application development is an interative process between you and the users).

I hope this has helped.

[leinad31]

Biggest delay are the users... typically they also have a general idea of what they want (same as you) but when presented with the software they suddenly become obsessive-compulsive about it... that is why creating a prototype with important features is better than the traditional waterfall SDLC approach... in the traditional approach, review and testing is scheduled at the end... when changes need to be effected your schedule is already packed hence delays... with a prototype, you can experiment and present users with a sample they can criticize to their hearts content while there is still time to do so... then after a certain period you stop entertaining additions and focus on development and testing of what was already agreed upon.

[Hack]

Biggest delay are the users... typically they also have a general idea of what they want (same as you) but when presented with the software they suddenly become obsessive-compulsive about it... that is why creating a prototype with important features is better than the traditional waterfall SDLC approach...

This is so very true. I'm a strong believer in creating prototypes. Users seem to be visual people. If you can actually show them something, then often the "flood gates" will open, and all the specs you are been trying to get out of them for the past three months will come pouring out so fast you will actually have to slow them down.

[zeezee]

So i wondered, whats the general "format" or 'check list' you go through when designing and then coding your applications to save time?

I think the start point is Analysis

Its debateble to follow which model in Software Development, but before all the other phases, you need to know what you should develop.
I always tend to start with Requirements Gathering. Collect information about the bussiness process. Do background research, etc ...
And I think this has so many aspects if you consider the types of software you need to develop
1. Bussines
2. Entertainment
3. Scientific
4. Real Time
etc ...

Its always good to know the functionality you need in that software.
When you have got the functionality, then you can start designing.
In this you can use the traditional Water Fall Model, or adopted version of it - Iterative Development Model ???
Prototyping is another method.

Here are some resources for you

http://en.wikipedia.org/wiki/Systems...ent_Life_Cycle
http://www.pragmaticsw.com/SE_SP_sdlc.asp
http://qualityvista.blogspot.com/200...ive-model.html

And some books I've used

http://www.rspa.com/about/sepa.html
http://www.amazon.com/Software-Engin.../dp/020139815X


Hope these helps you.

[RobDog888]

Flowcharting and having some kind of basic logic will save you from major issues in design. Just code the basics of the program and if you finish under budget then place in more added features.

Thread Moved

[aikidokid]

An excellent question Chris

It's good to get the professional opinions on this.

[Hack]

Flowcharting and having some kind of basic logic will save you from major issues in design.

This is a very true statement, however, in my shop, if I got caught mucking about with charts I would asked why I was wasting my time drawing pictures and not busy writing code.

My IT people are a couple of fries short of a happy meal!

[Shaggy Hiker]

I walk alot.

I suspect that my user base has both more and less experience than most, which is a bit odd. Since I work with a bunch of scientists, they generally expect software to produce very specific products, but otherwise be poorly documented and difficult to use, as so much specialized scientific software is. We use stuff that makes the old DOS command prompt look user friendly, so people have VERY low expectations for an interface. I have yet to hear a single visionary idea about interface from any of the scientists. They have big ideas about the data, but are totally tolerant of miserable interfaces. Therefore, any easy to use interface design is greeted with astonished delight.

Because of this, I get lots of input on data, data organization, output products, and things like that. However, as to how the program should act, I get no input of any sort, which means that I spend a fair amount of time watching how people go about their jobs, look at the data they are taking and the patterns in which they take the data, then spend lots of time wandering around thinking over how an interface would fit into their routines.