8

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?

Improve this question
3
  • 8
    Why 5 things? Why not 3 or 7?
    – Wizard79
    Sep 5, 2010 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.
    – Richard Stelling
    Sep 5, 2010 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...
    – Armand
    Dec 12, 2010 at 2:52

2 Answers 2

Reset to default
5

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.

Improve this answer
3

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?

Improve this answer

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