views:

375

answers:

10

What is the best way, you have developed, to approach / brainstorm / look at new assigned projects?

  • read relevant books, blogs?
  • discuss problems with fellow programmers?
  • ask questions on StackOverflow? :)
  • search for similar open source projects?

What are your first lines of code and how much time does it take you till you fire up your IDE?

+2  A: 

It depends on the project, but quite frequently I'll read up on relevant algorithms in Wikipedia, and search using Google for similar ideas that have already been implemented.

Certaonly I'd discuss ideas with colleagues, even with people not on my team that I know would be interested in the topic.

I haven't tried StackOverflow yet, but it seems to me to be better to get answers to simpler non-subjective technical questions here than for brainstorming ideas for tricky projects.

I'll jump into the IDE at the first opportunity, starting with "Hello World" type programs to check all the technology stack is working, and start building from there. I'll try to do the simplest possible thing that does something vaguely useful and then work out what problems that has and use that as input for further brainstorming.

Mark Byers
+3  A: 

For me it takes 1 hour to reach my job, and I go there using public transportation which gives me a lot of time to listen to podcasts, read, think, plan (and even sleep sometimes :D) I usually think about new ideas while sitting on the metro & the tram.

It takes almost one or two weeks of planning, I think about the idea, and think about it over and over and over, sometimes I get ideas that I think are great but then after one day the enthusiasm disappears. After two weeks I start brainstorming intensively on piece of papers, and attach everything on the wall, on the closet, and on the fridge, so I keep seeing them around me in the house.

After the brainstorming, I get to decide, is it good? really good? and if yes, I fire eclipse and start prototyping.

For me the best place to get ideas is work, you see bad things, and see they are done bad, and try to find solutions.

Omar Al Kababji
I can not agree more with the 1hr job transportation.. Hovewer with bus full of people it's hard to focus sometimes
Juraj Blahunka
Well after a short period of time you get used to it, and if not you can always turn on your iPod and isolate yourself ;-)
Omar Al Kababji
+5  A: 

The book Coders at Work contains interviews with some great programmers. They go away from the computer for months, they begin exploring the problem in throw-away code. and they begin working towards a code solution from day one. The approaches are all over the map.

So the answer seems to be do whatever works for you.

John Knoeller
+2  A: 

If I am doing things right, my first lines of code would be from existing programs.

When wrapping my head around a new project, I look for similarities in new assignment with stuff I've done before. Can I adapt a parser? Generalize it? Can I use sqlite again, or do I need a more powerful database?

If the technology required is new to me, I seek help from other departments that might have done this type of work before. For example, I know C/C++, but Java not so well. I ask the java developers about a netbeans and their eyes pop open with horror. :) I also consult with friends in the business and colleagues outside my company.

If I can't find help from people in other groups, then I search the internet. I go to the usual places -- Stackoverflow and Google. But for an internet search to be fruitful, you have to be very specific with your question, so you have to understand the scope of the new assignment pretty well. That means even before writing a line of code, you need to get into the head of the user.

Mike Yam
+1  A: 

I start by recognizing that the first thing I do will almost certainly be wrong.

Second, I try to get a grasp on the real problem being solved. This can either be the core conceptual model of the problem, or sometimes just the first step. This is often the biggest problem. I don't necessarily try to understand every detail and facet of the problem, but to try to get the 'essence' of the problem for lack of a better word. A big part of this is usually figuring out what the inputs and outputs of the problem are, and what data is known and unknown. I find that viewing problems as being fundamentally about data transformations and dataflow often makes it much easier to groke what is really happening.

Third, I try to get something up and running to give me feedback (since I know the first thing I do will be wrong, I'd like to find out how it's wrong as quickly as possible). This might be adapting existing code, it might be writing new code.

kyoryu
+1  A: 

First, for any large project/task I would prefer to start by putting together a quick design paper to document the high-level approach. This document does not have to set all of the details in stone, it is mainly for planning purposes to help me better understand the development work and finer details up-front. That way when coding begins it can be more focused. Of course, this step can be more or less detailed depending upon the project scope. This process will also involve discussions with fellow programmers and domain/business "experts".

In conjunction with the design, it is helpful to conceptualize what the overall system will look like by putting together some quick diagrams of the high-level architecture such as data flow diagrams.

While planning my approach, if there are any areas of the project that are unknowns (for example, I will need to use a framework I have never used before), it helps to build a small prototype to answer any questions I may have about a specific piece of technology. It is critical to have some familiarity/experience with the tools you are going to use before you are fully committed to the code. Plus, I will often find that this helps me refine the code during implementation, almost like you are writing it for the second time. Anyway, Stack Overflow is a great resource for any prototyping/research questions :).

One last thing. I would not generally search for a similar open source project, but I recommend spending time researching to find open source libraries and frameworks. The ones that are solid and a good fit for your project will make your life that much easier.

Justin Ethier
A: 

Last semester on Extreme Programming we were assigned a project, where we had to pair up in front of one computer and take rounds by the keyboard. The assigned project itself wasn't that immense, hovewer pairing up and sharing one computer proved to be very mind refreshing and encouraging.

While collaborating with others, one get so much ideas it's unbelievable. First I thought, that "what can 1 programmer do in 1 day, 2 programmers can do in 2" is true, however after we synchronised, programming was fun and I recommend pairing to everyone.

Juraj Blahunka
+1  A: 

The first step should be asking someone who has more domain experience..whether that someone is at work or on stackoverflow.com :) Or now, you can try to use social engine search vark.com to ask opinions in your social circle.

portoalet
+1  A: 

I start by conceptualizing the problem as a set of components. Each component is then broken up into a series of smaller components, until each component performs one task only. I try to keep myself considering only generic components, represented by interfaces and abstract classes. Sometimes I create graphs of these, and sometimes I do not.

I also consider items which have "state", what those states are, and what causes them to transition from one to the next.

Fairly soon, though, I'll start coding. This is because the real world always impinges on any theoretical design, and I must eventually adapt my vision to a concrete solution.

Mike Hanson
+1  A: 

What I usually do:

Jump into my IDE as soon as it loads, throwing together code as and when it comes into my head!

In fairness I don't necessarily think this is such a bad approach - after all this is the part of programming that I enjoy the most and so probably what I'd choose to do if I'm working on something myself just for fun, however its not the most productive way to get started - I usually end up having to stop and rethink what I'm doing quite often with this approach.

What I should do:

  • Do some research to see if anyone else has already done exactly the same thing / something similar before.
  • Do some more research to see if there are any projects which might help.
  • Throw together a quick functional speicfication so that you know how the basic functionality is going to work.
  • Look at how each part of the project might be implemented and check for obvious problems
  • Maybe do some quick prototyping to experiement with any libraries / other projects I found in step 2.
  • Rinse and repeat from step 3 until you have an overview in your head of how everything is roughly going to work.

I don't necessarily think that using a more structured approach will produce better code, but it will probably produce better code faster because you don't have to constantly interrupt your coding / debugging cycle to think "how exactly should this work?", or even things like "Should the user be able to do this?".

Kragen