When you're starting a new project, how do you plan for it or how long does it take?
Pseudocode? Flowcharts?
Do you try to think of all the classes in advance?
TBH, i never plan anything. I get straight to it and think of solutions as problems arise. Mostly because the few times i tried planning in advance, i would always forget something major, and thus the logic of the planning would be flawed.
Alot less than I should
I always dive in, get dirty and then realize that I have made a mess. Then go back and plan, and do it right.
but the messy mistakes phase gives me great ideas that I wouldn't have though of through a formal design process.
Edit I mainly get in these kind of smash the keyboard messes when playing with larger/complex. Interesting to see how far things get before you realize that your 'it's in my head so it is ok' design is 100% flawed.
It depends. Most things I write are fairly straightforward and a larger design gets built step by step and I notice what's still missing and what's already complete. There were a few more hairy things that required extensive sketching and thought to get right, though I've not yet came across many architectural problems that required so (still young and stuff). Mostly those were tricky arithmetic things.
At my internship last year, my manager was pleasantly surprised I used flow charts for a problem. He thought it was a lost art with students these days. I was not-so-pleasantly surprised that they were considered dated.
Anyway, it depends on the timeline of the project for me, deadlines are the most important thing of course.
Probably not the best technique... but... I plan in code.
I often discover class/methods/etc. that I need just by doing it this way. With that said, I always assume that my planning code is not going to be the final solution.
Additionally I will write down notes detailing "major features" and "minor/wish features".
When taking on a problem of any size, I always plan on writing it at least twice.
It all depends on how large the project it. Sometimes it could take months to just gather all the requirements and know exactly what it needs to do.
When it comes down to the coding part, it all depends on how complicated it is. If it is extremely complicated, I wills start by simply drawing out what I want it to do. Then I will type out my pseudo code in comments. Then I will code around those comments.
However, if it is simple coding. I will usually just write out what's on my mind and test it.
We use a very agile approach in that we will work on major parts and of course things are always coming to pop up in the requirements. So we will accomodate for those as they come up. You're never going to fully know exactly what you want to create at the beginning of the creation cycle.
That's my opinion.
Most of the time, I at least try to have a overall diagram (even just in my head) of how the module/system is going to work. I like knowing what I am going to do before I do it. It makes the programming easier and faster (we are generally under tight deadlines where I work). Every time that I don't, I run into problems that generally leads me to pulling out code and putting is somewhere else. I will admit, my process came through bitter experience and I got really really good at using regex in code along with global find and replace.
Someone else brought up a good point, sometimes you have a really large system and that gets difficult. I try and break it down into chunks. I'll work on something and get it fleshed out, and work on something else for a little while and see how they interact. Even with planning ahead, I miss things and have to refactor code, but at least I am not redoing everything since I at least had some sort of a working plan.
It depends on how complex the problem is you are trying to solve. If you are taking on a big programming project, you need to have a certain degree of planning before you start. If you don't, you'll get horribly lost in details of stuff that doesn't quite communicate with the other parts in no time.
Basicly, try to get a birds-eye view of the problems you need to solve. See if any of the problems are small enough that you can solve them and figure out what it might need to communicate with the rest of your solution. Think of it as a black-box with an API to the outside world.
After you have all your blocks figured out, see if you need to split the problem into smaller sub-problems, or that you have a detailed enough view of the whole project that you can start with the code.
My experience is that planning helps you prevent problems in the future, make you think more about how the code is supposed to grow in the future if you need to add anything etc.
In most of the cases you will save the time you spent on planning when you are debugging or extending the project. Also, having a rough layout of the project means it will be easier to get help building the black-boxes you need, so you can work on it with more people than just yourself.
Depending on the complexity of the project, I usually start out with pad and paper, and write up a spec, and some pseudo code of the control flow. Then I can always refer back to that while I am coding. It makes it easier and requires less refactoring because you didn't think the problem through.
Personally it depends on the scope & complexity of the project, how many people I'm working with on it, and the overall expectations on delivery.
It is quite important to understand the overall expectations of the parties who will be using the software. Everyone involved in the project should have a common understanding of what is being worked on -- how that is communicated goes in many directions.
Too often, parties involved in software development do not realize that communication among the parties is oftentimes the most critical and undervalued part of the project -- and the leading cause of project mishaps.
After experience of a LOT of unfinished projects, I tend to implement a simplified version of my business processes into my personal development methodology.
They generally follow the following structure:
I brew some coffee and craft a couple sandwiches.
Really it depends on the project. I've worked on some projects in the defense industry that took 2 years of detailed planning before writing a single line of code, and I've sat down and churned out some small utilities from just a few requests in an email from a 3D or texture artist in a single sitting with a bag of pretzels and a cup of Joe.
Being able to develop flowcharts, UML diagrams, use-case dictionaries, and extensive coding standards before hand is a nice way to keep things organized, and is certainly worth doing on larger projects, larger teams, and mission-critical projects. But these things do take time, and are often overkill for smaller projects.
The only thing you really have to ensure is that you have an adequate understanding of the problem domain. If not, spending the time up front to research it until you do is always worth the time.
When I was into the "waterfall" way of doing things I would write several hundred page documents showing all the details that could be uncovered during research. To get to this massive tome of documentation I would generally
For the past few years I have been following along with Agile (SCRUM) and have taken a totally different approach.
I have to say that Agile reduces the amount of time spent writing documents that decay as soon as the ink drys. The product owner gets to see results in a much more rapid manner. Which means that they get to keep the project going in the right direction over time - even if that direction changes as we are developing.
Keep in mind that there is a time and a place for both ways of developing. I wouldn't want to build Jet software using Agile!
I'm still at university and I don't yet have experience with creating large scale software systems, but...
The first thing that needs to be done is to work out what's wanted. So far for me, this is normally an assignment specification, but in the real world it involves talking to the client. A lot.
Then I work out how to do what is required. For the relatively small programs that I've been working on, I normally form in my mind a rough idea of what my program's going to look like (what the important parts of the program are and how they interact with each other). This may involve spikes if I have no idea how some part of the program will work. I don't think this approach (do it all in my mind) will scale very well, but the question was asking what we actually do...
Once I know more or less what I'm trying to do, I sit down and write the code. It is here that I discover any problems in what I was thinking.
I don't think I've every used pseudocode to design an algorithm. I think pseudocode is too low level to design large chunks of the program.
I have only used a flowchart on one occasion to help with designing a program - back when I was learning assembly and was quite new to programming (and it was helpful). The Mythical Man-Month says the following: "The detailed blow-by-blow flow chart, however, is an obsolete nuisance, suitable only for initiating beginners into algorithmic thinking. ... I have never seen an experienced programmer who routinely made detailed flow charts before beginning to write programs."
IMO 5 minutes of planning ahead = 1 hour of coding....
So many times we have to go back and rethink the whole situation , because we did not plan anything.
The most important part should be the FLOWCHART.
The other details sometimes can be taken care of on the fly.