Before I begin let me say that what I'm asking probably has a whole science to it that is not easily learned in a few hours or even days, but nonetheless, here I go asking anyway.

What tips, ideas, suggestions, ideas for things I shouls read/learn do you have for someone who has not done bery much programming and is beginning a reasonably large project.

My main problem really is getting my head around all the different parts that I want to put together (many of which I am not sire yet even of what they're going to look like or work).

Should I have a big diagramme in UML that I have planned already, should I just "make it up as Io go along" and wing it.

Any pearl of wisdom for anyone to share.

The classic approach is start from teh high-level overview, then break the project down into its critical parts, divide those parts down into functions or procedures that can be coded, then code those elements that are easy first. By the time you get to the more difficult ones you will more experience, more ideas for dividing them down into smaller and easier to code functions, and a better feel for how the whole thing will work when you have it finished.

Top down design, bottom up coding.

Rarely does the actual execution of the project continue to fit that model, but it gets you started and gives you a methodology for dealing with the occasional coding block. (Like writers block for engineers.) Actually getting started and making progress without wasting your energies or stressing yourself to death is key.

Luck!

1 members found this post helpful.

I admit that this is only tangentially related, but related it is:

The Architecture of Open Source Applications (free ebook)

1 members found this post helpful.

Could not agree more.

With that in mind:
Absolutely not. For a quick, small project: fly by the seat of your pants all you like. For anything else, put some thought into it beforehand.

There's a bit of a catch-22 involved though that wpeckham touched on in his quote above. The catch-22 is, if this is a first-time approach to a programming task, you cannot properly design a system--because you have no experience/knowledge of the difficulties or problems you are likely to encounter. You end up programming-as-you-go because unanticipated problems pop up as often as not.

For those instances, my suggestion would be to write some basic, minimally-effective, skeleton version of the final program (or pieces of the final program). Then discard it--seriously. The purpose is to gain that initial experience about the problem. With that experience, develop a plan/specification/whatever and start over. Resist the temptation to "improve" your first-attempt-learning code. Start fresh.

So, in a nutshell, you should plan and document when starting a large project. If you're not familiar with the task to be confident in a plan you create, cut your teeth on a simplified version so you can go back and have a more competent plan.

It's ok to deviate from your plan. It's not set in stone, but make sure you have a good reason.

If you don't plan, you will end up rewriting your code. Not once, not twice, but probably many times as you refine your approach. There's no bigger motivation killer than realizing you need to make a fundamental change that trickles throughout the project.

UML will hinder your progress unless you already have a plan. This is because there are rules to UML and you'll spend more time fitting into those rules than you'll spend being creative. It's a specification tool, not a creativeness tool. As far as "make it up as you go", keep in mind that every worthwhile project will change substantially over time. Your best bet regarding planning is to anticipate future requirements and figure out what sort of design will allow incorporation of those requirements without having to restructure the project. You don't have to plan out all of the requirements, and you won't know them all up front, but you can anticipate the weaknesses that will need to be improved or extended. For example, if your project involves IPC you'd want to make it easy to replace the IPC part of the system with something more robust in the future. Or if it processes flat files, you'd want to make it so you can add functionality to process more complex formats later on.

If there is only one philosophy you approach your project with, it should be to make it easy for "someone else" with more knowledge or skill to improve the weak parts of your project. For example, if your project performs computations, make it easy for someone who is better at computing things to pull out your code and put in something better. The cleverness in this philosophy is that this "more skilled person" will in most cases be you in the future.That's great advice. I usually have a "clean" source tree and a "working" source tree. In the "working" tree I mess around and get each piece of functionality to work in isolation, and once it's working well I integrate it into the "clean" tree using the "working" code only as a model.I find that rewriting is inevitable if your skill and knowledge of the problem you're solving both progress during the life of the project. Not anticipating at least component-level rewrites can seriously stagnate your project if at some future point you realize you can't overcome a barrier that you never knew could be a problem. If you sufficiently modularize your project, even structural-level rewrites don't need to be that painful.
Kevin Barry

A long walk in the park helps sometimes.

Get out a legal pad and a number-two pencil and start sketching ideas. Do not remove a single sheet of paper from that pad. Consider how the user will approach the application, and the task that the application is purposed to help him or her solve. Consider what the application has to do with regards to its files, databases, other computers, whatever.

Set up automated testing that will allow you to easily re-run all the test cases set up so far. This will include data sets designed to expose edge-cases such as null data, one of a kind, many of a kind and erroneous data.

Specify the interfaces as well as the functional requirements -- user interface, OS interface and inter-module interfaces.

Write the developers' documentation as you develop.

My (on-going) experience with large projects is that is important to have a well-thought out overall structure for your program. Drawing diagrams might be going a bit overboard, but it will help to create a "main" file with top level function calls, and then prototype those functions into some sensible arrangement of header files, with the accompanying stub implementations. Once this is in place, code tends to "fall in place" as you write it, which is a lot less stressful that constantly wondering how every line of code will fit into your overall plan.

As you create this structure, you mainly you want to be thinking about two things:

1) How will my program function on a fundamental level and how can I fit program structure to sensibly match that? Questions like: Is my program event based, or does it do batch processing? How is input related to program state? What approach will I take to handle various kinds of events?

2) How can I keep program components reasonably well isolated (while simple and efficient)? Generally, you want to be able to adjust function definitions and internal data structures without worrying that this will screw up 12 other files in ways you didn't expect. Each language typically has its own various features and nuances that can help. (In C, for example, which doesn't strictly speaking have an "object oriented" syntax, will allow you to hide a lot of internal structures and functions inside a source file, using internal linkage, while making a few interface functions available through a header.) Whatever structure or interface configuration you apply, you want to make sure it effectively isolates distinct program components, while being reasonably easy to use and allowing efficient handling of the data. The object-oriented approach can be helpful, though if you overuse it or abuse it, you might find yourself constantly moving around complex bundles of program objects, which might be difficult to understand or make optimization difficult.

Hope that helps.

I'll chip in some advice: always over-document. Especially if your project is going to grow, it's better to write more documentation than needed and waste a little time than have an under-documented project and waste a lot of time explaining to people how to use it (or maintain it).

In the real world, large projects are begun by gathering requirements. Designing how the program will interact with other systems and with its users (its interfaces) and how it will be organized (its architecture) is a separate step from defining what it needs to do.

If you're serious about learning this, you might want to check out some books on software engineering.

2 members found this post helpful.

I recently realized that there's a major difference between CS and software engineering. I'm not in either field, but not long ago what I thought was CS was actually software engineering.
Kevin Barry

That's almost how GitHub is developed. The only difference is that they use a version control system (git) to automate this workflow, and that version control system can merge branches ("integrate it into the clean tree") automatically.

Details here. Very interesting read:

http://scottchacon.com/2011/08/31/github-flow.html

Thanks guys.

I hadn't replied after the first posts because I didn't think I had anything to add, but I have read all the posts.