Anyone know of any good resources for learning about the programming process. I would like to start doing some programming but I say if you are going do something it is worth doing right. Learning the languages isn't my problem. I would like to know what is the best practice process for going about creating an application from scratch. Looking into doing some Linux Programming and maybe create some php/perl based applications.

I know that subversion will help me keep tracking of code changes and a bug tracker will help me organize any errors that need to be fixed. But where does one start when deciding to develop an app?. Currently in my brainstorming stage so i know that is first step.

I have heard some people say to code your application to your requirements of what app should accomplish but then I have also heard other say to set your requirements to the application you code? I don't know if that make sense. But I guess defining what the program should be able do would make sense first. Then you develop app around those requirements.

Any guidance into the world of programming would be greatly appreciated.

There are many schools of thought on application design, development path design, and similar subjects -- top-down design vs. bottom-up approaches always spur vigorous debate.
Both approaches have their advantages and disadvantages, I happen to use either and both, depending on the application.
There is a brief description of these approaches on wikipedia.

For drivers and other single-purpose applications, I tend to use a bottom-up approach, coding modules that perform single tasks then combining those objects to produce the result.
For desktop applications I tend to (generally) use a top-down approach.

Then there is the question of what to design first, the GUI (if applicable) or the core functions of the application that actually perform the work.
I've never subscribed to the "form follows function" theory of design, but I can't deny its merit.
Sometimes I'll design the GUI first and other times I'll code most of the core modules before deciding how to present the data.

Team environments (vs. a single developer) introduce more complexity to these issues.
There are too many facets of these subjects to be able to answer this question in a few paragraphs, there are hundreds of books about them.
In general, I examine the specifications and requirements of the tasks that the application needs to accomplish, then decide on what to code first.

There are very few absolutes in the field of application design and development path design.
I understand that I haven't answered the question "what do I do first?".
That's because I'm not sure there is a single answer.

I am not a programmer, so take this with some salt....

There are some basic steps that are pretty generic:

1. Define what the end product is supposed to do (write it down in detail)
2. Define the subsystems required (in programming, this might be called "modules", "subroutines", or something similar
3. As appropriate, lay out a flow chart describing the order in which things happen, and the relevant decision logic.
4. Develop the detailed requirements for each module.
5. Prototype and test individual modules
6. Integrate the modules into the final product.

This is all I have time for at the moment. I'll come back later.

Hi.

Mostly language agnostic, I have found these to be valuable, but I am not a novice, so I may be looking at the question from a different point of view:
Best wishes ... cheers, makyo

Richinc -

You might want to take a look at this book, "Programming from the Ground Up", by Jonathan Bartlett:

http://www.freetechbooks.com/program...d-up-t291.html

IMHO .. PSM

Form follows function.

Languages DO make a difference; some jobs are easy in some languages, hard in others, and impossible in still others.

I suggest becoming familiar with a few different languages, so that you have an awareness of their capabilities and limitations. Then, code up a few simple projects. If you are really into it, code the same project in a couple of different languages so that you can get an understanding of how those languages are different and how those differences will impact your designs.

Once you are familiar with the tools, then you can start designing real projects. You will find that if the project is larger than a trivial command line utility, then you will need to spend a lof time up front deciding how the project will be organized. When you start actually implementing the project, if your up front design decisions were right, you'll know it because your project will sort of fall together.

If your decisions were wrong, you'll know it because you'll find yourself fighting the language, the operating system, and struggling to implement the functionality you want. If you find yourself in this mode, regroup immediately and if necessary start over. The project WILL fail if you have a bad design and are so wedded to it that you force things to fit.

Design is as much an art as it is a skill, and there are several aspects to design. There is the visual aspect - a pretty GUI; there is the functional aspect - a nicely laid out GUI; there is the extendability aspect - a well organized functional code base; there is the performance aspect - a properly coded implementation. It is hard to get right and sometimes you have to make tradeoffs.

When I build a project, I won't start until I have a good overall idea of what I want the end result to look like and to do. I then will identify "critical pieces" - most commonly, interfaces to outside stuff - to the database, to a piece of hardware, whatever. I will develop those pieces first, and make sure they work and are reliable. Then and only then I'll build the rest of the application framework, plug in the pieces I built first, then flesh the whole thing out.

Right now, in fact, I am transitioning to the "build it all out" phase of a major project I am working on, and I have just managed to get a GUI piece (that commands/controls another piece across the internet) running. I am sitting here looking at a very decent spectrum analyzer display (my GUI includes this display) and waiting to see if anything crashes. Looks good so far. (happy dance...). Once I am satisfied that all of this is reliable (thus demonstrating the communications work, the piece on the remote system - which is controlling hardware - works, the GUI works...in short, the major components of the framework work), then I'll move on to flesh everything out. That'll take awhile, but I'll do it with the confidence that the basic design is right, is working, and is reliable.

In my opinion, a lot of the problems arising from overtly-friendly commercial software is that the UI is designed, then backed with logic, leaving a misalignment that must be mitigated. Also in my opinion, you should treat the user as a component of the program and determine that component's capabilities and what you can reasonably require of it. This should lead you to what sort of interaction you want the program to have with the user. This is also determined by the nature of the program and what level of outside intervention will be needed.

There's no denying that the logic will have certain requirements of the user and that the user will have certain requirements of the logic. Designing from the bottom up can result in virtually unusable software (as I know from end-user experience,) but designing from the top down can result in unrealistic masking of what's actually going on, leading to work-around based user training and workplace policy (which I also know from end-user experience.)

As pixellany pointed out, it's a lot more reliable to compartmentalize a program in to independent modules. Taking it a step further, you should design interfaces for each module so that they can be treated as objects that interact with each other. These interfaces should be very concise, with as few points of interaction as possible, yet passing as specific information as possible for the given inter-module interaction.

Something I find to be extremely important is consistency, which almost always must result from the reuse of code where it would otherwise be redundant. For example, if your program uses text fields in many different locations, they should generally behave identically and you should be able to change the behavior of all of them from a single location in the code. This is almost always a good idea, even if the result is negative; a bug in reused code will reveal itself in every place that code is used, making it easier to detect and allowing simpler backtracking to its source. Just for clarification, by "reuse" I mean that duplicate code is merged and everything requiring a certain action uses the same code (which should result in multi-level abstraction,) and not that you should rely on stolen code of similar functionality from other projects or that you should copy-and-paste a piece of code into multiple procedures.

Two years ago, after I'd been programming for ~16 years, I finally decided to design a major project from the ground up. I spent months diagramming the different modules, their interactions, their internal data representations, the different libraries and programs involved, and an extensive outline of the project's philosophy (essentially an abstract QC checklist.) I wrote very little code in the first 6 months. It's turned out to be my most successful project (in terms of objective and ease of maintenance) as a direct result.

My last point is this: Don't be afraid to scrap everything and rewrite it if you come to visualize your project more clearly. Especially as a new programmer, you'll almost always see a better way to do things once you get into the code. You need to recognize that your own vision of your project should evolve as you work through it and maintain it, and that making fixes to the same code will eventually warrant a rewrite, unless of course you're extremely experienced, you've coded something extremely similar in the past, and it will never require new features (never been in that situation myself.)
ta0kira

PS Many "how to program" books teach you things that, while good form, aren't explained well. Some also make assumptions about you as a reader (other than writing to the lowest-common-denominator,) and in doing so, attempt cute tricks or unexplained simplifications. Be careful of things you don't understand and demand of yourself that you find out why something was done a certain way; some things are just preference and style, others are well-known bug-prevention and optimization techniques. Ask questions here if you need to.

PPS jiml8 has some very good points, and it sounds like we approach things very similarly.

P3S Eventually take a class or read a book about data structures. This will normally require experience with C, C++, or Java.

Thanks everyone for you replies. This helps more then you know. I really appreciate the list makyo posted. That will really help. Currently I don't know what languages I want to try but thinking about c++. I did a bit of C++ in High School but that has been so long that I will have to relearn a bit of it. I am also looking to in some web programming languages.

I do know that I want to remain a strong advocate of open source, thus I want to gear my programming skills and languages to towards this.

For all those who posted, I again say Thank You and hope that others reading this will find it very informative and if anyone else has other suggestions please join in.