When you start thinking about a programming project what do you do first?

Question

When you start thinking about a programming project what do you do first? Do you pull out a piece of paper and start sketching out the architecture? Do you have a notebook for ideas? Do you start coding something? Or do you model the software in a fancy package. Come, come, elucidate your thoughts...

Answer 1

In order to start thinking about architecture or design, I tend to write hypothetical snippets of code that I would like to "just work" in order to address the core problem of the application.

For instance, when designing my database, I usually try to think of some example queries I expect to write rather than think abstractly about the data entities and relationships.

This approach helps me (personally) avoid going too far with abstraction for the first pass.

Answer 2

I almost always start by drawing a rough object model to give me a visual idea of the structure of the system. then build from there.

Answer 3

I sit down and start coding...then I delete all the project files and go to the whiteboard and start mapping objects and relationships.

Answer 4

I write down a feature list, then go into it with a bit of detail, then I start some scribbling of my objects and how they'll interact with each other, kind of a half-arsed DFD.. all my drawings are a mess!

Answer 5

I will google it first to see something exists in the same way/or even closer and learn more about it. With the power of the languages and frameworks available nowadays, any average programmer could write the code but the quality will really depend on how much 'best practices' you have used to achieve that solution. And how fast you achieve the result also matters.

So I think Googling is going to be an important cycle in SDLC process :)

Answer 6

See this question: http://stackoverflow.com/questions/284578/design-or-prototype-first.

Answer 7

I grab a pad and pen and start sketching notes and flow diagrams, nothing fancy, just visualising the conceptual model, from that I try to break each part down in simpler and simpler tasks.

Once I can't simplify the tasks any further, I begin writing lose pseudo code and rough out a database scheme. Only then do I start coding sample/test code.

Answer 8

I keep a notebook that I write all the ideas I have in. I generally write a page or two of dense notes about the project/product/etc and then leave it alone, cuz I don't have time to do anything with it. When it's time to actually design the thing, I'll reread my notes and attempt to create a class diagram in UML. Usually this fails, which results in more pages of notes refining the idea, solving weird edge cases and undefined things, etc. Rinse and repeat. Once I have a class diagram that documents all the major players, I start coding.

Answer 9

I think about the users and what they want and what they'll get.

They don't care about backends or fancy languages, and until you've worked out exactly what your program will do and why someone would want to use it, nothing else really matters.

Answer 10

By programming project I am going to assume "for a client" and not a hobby/personal project.

I start first by having the customer describe to me, in high-level language what they want. I look for things like "I want a ticket system that has multiple departments and allows response/updates via email". Something quick and simple.

From there, I begin the first draft of a specification document. I start to ask the customer questions to help refine the original draft and get down to a more granular level until eventually the system is fully specced out. And by fully, I mean the customer is not able to give me any more information on what they want.

For a personal or hobby type project, I typically spend several days rolling things around in my head, designing some basic database schemas on paper or in my modeling program. I like to sleep on it a few nights to see if it is something I will continue to have the interest to develop and not abandon before it is complete. Once I have determined it is something I will see through, I go continue by drafting up my own spec and going from there.

Answer 11

Attempt to analyze the buisiness domain. i.e., the strucitre of the busienss problem that the application is attempting to solve. What entities does it need to manipulate/manage, Are they mutable/immutable? What processes (from a business perspective) does the application need to implement? Which of the entities does each process require, and for each, what does the process do to that entity? etc..

Answer 12

1. Collect requrements
2. Define priorities
3. Estimate effort
4. Start work
5. Track and evaluate progress

Answer 13

I'd start documenting a vision, a short document describing the project, the business around it and it's success criteria.

This helps prioritizing features, and gives the same direction to everyone working on the project.