Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 7 down vote favorite
2

What are the first 5 things you do before starting a new project?

Do you always spend a day researching new frameworks? Or, using similar or competing products?

share|improve this question
8  
Why 5 things? Why not 3 or 7? – Lorenzo Sep 5 '10 at 14:42
1  
@Lorenzo I agree it's a bit arbitrary. However, after 5 the "things" will become too "project specific" and < 5 limits the scope too much. – rjstelling Sep 5 '10 at 14:47
I like fishtoaster's answer. I'm guessing that by "before starting" you mean "before starting development"... although you might want to test some things before settling on specific technologies... – Alison Dec 12 '10 at 2:52

closed as not constructive by Walter, gnat, DeveloperDon, Jalayn, Thomas Owens♦ Nov 15 '12 at 14:13

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.

2 Answers

up vote 5 down vote

This is pretty project-dependent. Is this a project I'm starting with the intent of selling, or a project for a specific customer? Also, what constitutes "starting"? Is that before or after requirements gathering? A rough list, though:

  1. Get a context for the project. That is, figure out what your customer or potential user is trying to accomplish and why. If you're building a hotel registration system, what's wrong with OTS options, for example.

  2. Gather requirements. Meet with stakeholders. Meet with users. Meet with anyone who has a say in the project, if you can. Look at existing solutions that this project will replace, either that the customer is using or that exist in the market place. From there, write it all down in a non-technical language as you can- a good reqs doc should describe what's to be done but not how to do it. Then discuss this doc with the customer and iterate until they agree with it. This step can be less formal for smaller projects (possibly even entirely verbal).

  3. Start making technical decisions. Pick languages, frameworks, ORMs, databases, etc that best solve the problem, whether this means sticking with something you know or learning something new.

  4. Analyze the risks for this project. If this is a government contract, you probably want a 100 page leather-bound risk report. If it's a 3-man 4-month project, you might be fine with some notes in a text file or a spreadsheet. Either way, you want to figure out what can go wrong with the project, how likely it is to happen, how much it'll hurt, and what you are going to do to prepare for it, handle it, and/or mitigate it's effects after the fact. A common one, for example, is "One of the devs gets hit by a bus, quits, gets sick, etc." So you might mitigate that by pair programming to share knowledge, using good source control practices to keep code centralized, etc. Overall, the process of sitting and thinking about what could go wrong and being prepared for the possibilities is more important than actually writing out all the contingency plans.

  5. Set up the technology. It's the sort of thing that no one wants to do once you're in the thick of actually coding, so set up your repo, your build server, your build system, your wikis, your bug tracker, or whatever you intend to use for your project.

share|improve this answer
up vote 3 down vote

I'm just going to answer this part of the question, because it's the only part I could relate to:

Do you always spend a day researching new frameworks?

No. I seriously doubt that could even work... How could someone research new frameworks in just one day, before each project, and learn something relevant? It just doesn't happen that way. Instead, I spend parts of my day, every day, researching different technology (not only new frameworks). Research it's not something I do when I need to. It's something I do all the time and that's already there when I need it to be there. Programming is fun, that's why I am in this business. You can't keep me from trying out different stuff every day.

Does a writer spend a day collecting ideas before starting a new book?

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.