I am computer engineering student. I've been thinking about how I can handle a big project. What should be my first step to reach my goal in a more efficient and effective way?
When I come up with a project, I don't know how I should start working on it. Many times, I just ignore it. However, I don't want to ignore my project ideas anymore.
Now, I am asking to all of you, can anyone share his/her experiences? How should I start a project when all I have is an idea?
Forget coding and setting up a development environment for a moment. If you want to embark on a big project, the first thing you need to do is get a handle on the purpose and scope of the project.
What I recommend is opening up a word processor, and writing out a 'project goals' document. Describe what the idea is all about, and the general purpose of the software you want to write. Then list out the functionality goals of the project. I don't mean spec it out, but rather describe the different pieces of functionality that the finished product should support. So, if you were writing software to run a school, you might list 'teachers management' as a piece of functionality, and then describe what that functionality would include (track contact info, class schedule, etc).
Then the toughest part: It's not something you need to do right up front, but as you go along. Every bit as important as listing features you want to add is reviewing the functionality you described in your goals document, and note those features you can live without in the first version of the program. This is key to managing scope.
One of the main reasons people fail at larger projects is that they don't know when to stop working on it. They don't feel it is 'done' because the ideas keep coming, and it never gets released. Eventually they lose interest, and you have yet another half finished masterpiece. So you want to make sure you have a good handle on the functionality that is truly important to achieve the basic part of your goal. That is your first target.
This is how I start all non-trivial projects now. It helps me keeping the focus, and helps keeping the scope and purpose from 'evolving' during development.
I think Linus put it best
Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed. And don't expect people to jump in and help you. That's not how these things work. You need to get something half-way useful first, and then others will say "hey, that almost works for me", and they'll get involved in the project. -- Linus Torvalds
What should be my first step to reach my goal in more efficient and effective way?
I assume you've done projects before and that you're in a college/university that doesn't teach version/source control. If you want to see some projects you can always go to open source repositories such as Github (uses Git), Bitbucket (uses Mercurial), Google Code (uses Mercurial, Git, and Subversion), CodePlex (Mercurial and Subversion/TFS), SourceForge (Many), etc and have a look at their code base. The thing they have in common is that they're using source control software.
There is a lot of information regarding how to use them, so I suggest you learn how to use this, because this is standard industry practice. Here is some visual guides to get you going:
You know, when one project is came my mind, I don't know what I should do. Many times, I ignore it.
There is only so much you can do on your free time. Start small: Create a project from scratch, put it to a source code repository. Commit changes to your source code repository whenever you want to add something to your small project. In time it will become big and if you ever want to go back, you can always revert or roll back the changes you've made with the version control system.
It's perfectly normal to be hit by the "blank paper" syndrome.
You have a great project in mind, which looks fantastic, but when you sit down at the desk trying to do something, you suddenly block and are not able to do anything. Then you open up solitaire and make a new record.
You actually need to start doing something related to the project, so that you feel like it's born.
You may not want to write code immediately. You can start by writing what your project actually must do, or you would like it to do. Take a pen and paper and start writing. You can start from the details or from a bigger picture. Try both, see what is best.
You can try to define the functionalities of the project, the different parts, how those parts communicate between them. I feel myself comfortable with post-it, they are fun and you can change them as you progress. Let them follow your mind and ideas.
Or maybe you can start prototype some function or classes. You can use whatever language you prefer for this, even one that doesn't exist and you just invented.
After some time you will have something to work on, and your project will be not only on your mind. You actually did something.
When you feel comfortable to actually start the development process, it's time for a careful planning, documenting, prototyping, gathering of all required technologies and software, and so on.
But don't start until you actually feel it's the right time!
Large projects are formed from many smaller projects or pieces. You may have one big idea or project requirement - say, an application that manages contacts.
Break it down; ask yourself, 'what are the smaller pieces I need in order to do this?'
Once you have defined your smaller parts, repeat; you may find that some parts need to be broken down further. The idea is that you define the most manageable goals for each of the smaller pieces. Learn to use disciplined principles in design and development (such as Agile-TDD) and the smaller, more manageable goals will be fulfilled.
You have a big idea, but don't know how you are going to go about accomplishing your task. Create an outline of what you are going to do. Write down the steps you will take, what you will need, what languages you will be using, etc.. Make sure you have everything organized, or the project will be a complete wreck.
I mentioned this before, but it is really important. If you have time mapped out, you can have an estimated finish date of when your project will be finished, and how long any steps of the project will take. This is, again, organization and will keep you running.
If you are going to start a big project, you will need some help. For code organization, and a good Version Control System, Git is great because it keeps all of your code in a single repository. For more info on Git, see the link I gave you.
You will also need to make sure you are using languages that will help you do what you are trying to do. Make sure you are able to create your project before you start. I'm not saying don't learn anything new, but learn before you start.
Big projects are not usually done alone. Contact fellow students, people in your community who can program, and anyone else you think can help you before starting. Do not be afraid to ask.
Don't lollygag around, waiting for someone else to start your project and then say " I had that idea!". It will forever haunt you...
My definition of "big project" is "a project where the major problem is the coordination of participants and the communication between them" (a medium project is when the management is as difficult as the technical problems, a small one is when the technical problems are more important than the management one; note that a long term one person project can be a big project -- coordinating and communicating with your future self isn't very different than doing the same with someone else).
The first step in being able to handle (with a "have a leading role") a big project is to participate to some big project without having a leading role. The second step is to reach the leading role level while being mentored by someone which has experience with it.
An alternative approach is to increase progressively the size of the projects and learn from your experience...
Maybe it is full of cliches but ... I'll submit.
To be able to handle a big project you need mainly one thing: experience. Experience gives you everything you need:
So you can do two things:
I hope that helps.
Some ideas are ripe for an engineer just to jump right in and begin writing code. These projects might be big or they might be small, but what they all have one thing in common: a well defined problem to solve. I have started projects like this countless times, and it is just a matter of me building a discipline around writing good documentation up front, and following best practices with regards to source code control, communication and collaboration.
Big projects for which all I have is the germ of an idea takes a little more preparation in my experience. The first thing I do is start talking about my idea with others to see if anyone shares my understanding of the problem I am solving, and to validate my planned approach in solving the problem. So take a friend or two out for a beer, or invite them to your dorm room for Cheetos. But have fun with this process because it is through this process that you might better understand the problem you are solving, find other great ideas you can bring to bear in solving the problem, practice selling your idea to others, and maybe even begin building a team of people to help you solve it.
Split big things into smaller things.
You cannot work on "achieving world peace". Instead you work on banning Weapons Of Mass Destruction, you encourage democracy, you provide development aid, you encourage cultural and scientifical exchange and so on.
I think something a lot of these answers don't touch on is getting something tangible done, and forcing yourself to get it done.
Sometimes you get stuck in 'thinking land' where you feel like all that's left is the tedium of typing things out ,but actually start on a bite sized chunk of your project and the implementation is both fun and challenging.
I know a lot of people who are like this, including me, until I actually get going I get nothing done, I can't -just- think and plan to start a project. I have to pick a piece that I can readily implement, and get to it and then the flow starts.
there is no reason to do anything without a purpose. You need user stories that show the need for the code you want to write. You should frame these user stories in the following format:
As a [X]
I want [Y]
so that [Z]
This may seem over simplistic, but it gives you the framework to not only define the user, but to also specify the need and what the end result is in a single sentence. You will have many of these. You will come up with more as time progresses. After you have some you can begin development on your code. When you have more ideas or figure out other things. You go back and write more user stories so that you don't forget them. That is the best place to start.
Behavior Driven Development uses this approach and the site at the link has several examples of using this format to express user stories.
I think it will be the quickest and most organized way to get from idea to code.
I would grab a stack of yellow stickies and a magic marker and sit in a room where there's a big white board so I could brainstorm.
I would just just start writing down simple phrases that came to mind such as Main Menu, Reports, Database, Authentication etc. I'd stick these on the white board and just stare and get more ideas say for example how the main menu should look:
File Open, File Save, File Save As, Print etc and stick these on the white board under main menu.
As ideas pop into your head write them down... good, bad, stupid whatever just get ceative. Stick them on the board. As you look at the board more ideas will surface and patterns will emerge. At some point you will start to get a feel for what you plan on developing.
Yellow stickies are great they can be moved around fairly quickly.
Once things start coming together, you split these thought into groups. Then you can brainstorm at a single group level. I'd take pictures of the white board at various stages in case you want to see what it looked like twenty minutes ago before things got shifted around.
Eventually, you will have a pretty good idea of the main chunks of stuff that has to get done. You could get a single folder for each of these chunks and just keep tossing ideas into them as they come to you.
Since you're a student I'm going to assume you mean student-big and not professional-big. The latter requires additional business and collaboration considerations. I just started a new project last week, so the process is fresh in my mind.
The first thing I do is research existing solutions and libraries. I don't like to reinvent the wheel whenever possible. This research is also a big factor in choosing a language for the project. Some languages have better existing code for certain tasks.
The next thing I do is create a folder and put it under source control. This is as simple as a git init . nowadays.
Next I get "hello world" working. This lets me know my development environment is set up properly.
Next I get "hello world" for third-party libraries working. This is the bare minimum necessary to show I'm linking to and using the library correctly. For a database library, it's connecting and running a simple query, for example. For a GUI toolkit, it's displaying a window.
Next I set up build scripts and testing frameworks. This is ant or makefiles or whatever, and is much easier to set up when your project is still small.
Next I create data structures. Also called the "model" layer. This is the part that stores everything your program needs to remember in order to do its job. I do a lot of design on paper, then just add stubs in. This part of the design is usually the easiest. For example, a chess program is going to need objects to store the game grid, the players, the pieces, sequences of moves, etc.
At this point, I have a pretty good base for a program and it's usually fairly obvious what the next step is going to be for that particular project. Then I just take it one small step at a time, with code that works to some degree all along the way.
If all you have is a "Big Idea", you will need a lot of things (that are very well described in other answers), and particularly these 2 : time and motivation.
The biggest difficulty when you work alone on a personal project is that, usually, you don't have much time to spend on it every week and so you don't see much progress and quickly start loosing motivation.
So as it has already been said, take small steps, that's the key.
But this is not all, you have to take small and rewarding steps ! That is, steps that will bring you the biggest value and demonstrate the key concepts of your big idea.
For example, if you work on a new super todo list software with great user interactions. Don't start with the storage and database stuff until you really need it. Start with the innovative user interface : that is fun and has value. That'll make you proud, keep you motivated and allow you to check very soon is your idea really is good.
The very first thing you need to do is sit down and describe that idea in writing. It will not become a project until then, and even then, you have some work to take it from being something as ephemeral as an idea to something as tangible as a project.
Once you have gotten that far, you can start looking at turning it into a project, identifying how you might break it down into discrete steps which can be implemented in a logical manner.
Then outline a timeline for implementing those steps. Revisit progress at given intervals so that you retain some control of that process - rather than having creeping ideas you never thought of in the first place and adding them to the mix.
Identify an initial finish line and aim for that. The less you adhere to that, the more the project is likely to sink beneath the weight of additional ideas, and the more discouraged you may get about completing it as it seems to live forever.
Code effort is typically about 20% (+-10%) of a project budget. Focusing on getting code correct is pointless, theres 80% of the effort that you have not addressed, so getting perfect code managment still leaves you with only 20 of the work done.
What if your project has no users? What if it's perfect but published one week after "Acme Patent Trolls" file for a patent on the idea, and it turns out to be the next Facebook?
Look at the following standard project lifecycle issues Requirements, Design, Code, Test, Integration, Deployment, Defect tracking and correction, requirement change management (enhancement requests). Release plans, resource allocation (how many hours are day are you planning to, and will you actually do on the project), Legal (Freedon to operate) etc.
If all the above are in place, even very bad code will be successful. If none of the above are in place, the best code will fail.
I am not a betting man, but I would put money on it your first "big" project will fail, in many and varied ways you can't imagine. Don't worry, go ahead and fail, learn from it and do the next. Not starting would be the real crime. If you do succeed first time, you have a solid career in business management, not programming.
So to answer you question, put away the software tools, and pull out your "business planning" tools. Work out WHY you are doing it, for WHO then WHY and WHEN they want it. (You can be your own customer, but do the exercise anyway). Write this down in a "Business plan" and build from their.
repeat the last step until the project is done; accept that it may take years, and keep moving forward
All the answers here are nice and all, but in all honesty, it doesn't matter how much version control, gitting, flow-chart and mark-ups you make, all that matters is that you have a functional application, a functional application is defined as one which solves the problem for which it was concieved, all the other things are pretty much irrelevant.
Start coding, code it to a functional phase, run some tests, debug, launch and re-iterate with new features and functionality (if you deem it necessary), much in the way of a lean startup - which is an agile method of managment and development to create less waste (or as someone defined: half finished masterpieces).
List of things to do when starting a new project: