Take the 2-minute tour ×
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.

Before you start coding something, how do you prepare yourself? Do you make diagrams, pseudocode, mockups or any of that kind of stuff or you just start coding and see what comes along the way.

Personally, I prefer to jump into the code as fast as possible when I am comfortable doing what I have to do. If something is more complicated or a problem occurs, I normally take a sheet of paper and start writing pseudocode down since I have less trouble concentrating that way (I guess that's kinda weird and hard to explain, but whatever...It works!)

I guess everybody has there own strategy, so what's yours?

share|improve this question

closed as not a real question by Matthieu, gnat, Walter, ChrisF Jan 26 '12 at 23:45

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
I think you may want to elaborate a bit on the "I am comfortable..." part. Do you get a complete spec handed over, or is this how you design large scale programs? –  user1249 Nov 7 '10 at 17:19

11 Answers 11

up vote 10 down vote accepted

It depends. If it something easy that I know exactly how to do, then I just code immediately. I start by writing some pseudo-code in form of comments to get an overview of what needs to be done (unless it's a very simple problem or small function).

Writing these comments first often lets me know if I've missed something because I will stumble upon how to write them. If I can't formulate good comments or make an overview of the functionality, it means I haven't understood the problem or purpose of the function completely. If that happens I take a step back and think about the problem some more before continuing. If I get stuck I treat it as a difficult problem.

If it's a difficult problem I try to solve it anyway which seems fit or will lead to a solution: if I can use a visual approach I try to draw the solution with pen and paper; if it's a manner of knowing what library functions to call I read the manuals; etc. Most importantly, if I think that this is something someone else must already have solved, I ask around my fellow colleagues, google it or visit StackOverflow.

Mostly I've done this subconsciously, but I try to always think about what I'm doing and see if there's something I can do better. For instance, I didn't bother writing overview comments or pseudo-code until after reading Code Complete.

share|improve this answer

I ask myself these three questions in order

  1. What is the output?
  2. What are the inputs?
  3. Is there enough input to create the output?

For very simple stuff I do this in my head.

For the more complicated stuff I'll get mockups of Step 1 from the customer or if the customer doesn't know what they want then I'll take a stab at creating something. This usually leads to a discussion of what the customer really wants. Discovery can be a lot of fun.

Once the customer knows what they want then it's a matter of getting the inputs.

  • Data
  • Formulas
  • Busines rules
  • Actions (What happens when I click here type stuff)

Then I'll evaluate whether I have enought information to actually produce the expected output. If not, I go back and get those answers.

share|improve this answer

I get a cup of coffee, make a strong mental image of my wife and daughter, and then imagine a tiger made of unemployment chasing my cursor down the page.

Not an "expert" answer, but all joking aside, it's a significant part of my preparation.

share|improve this answer
    
Fear is one powerful motivator –  canadiancreed Jan 26 '12 at 1:06

I used to just jump straight into the code. Sometimes this worked well but other times I'd eventually end up completely rewriting parts.

Now I sit down with a pen and paper and quickly sketch out the different screens in the app (I'm an iOS developer). I make a few notes beside the sketches on how to solve some of the problems at a high level (no pseudocode), and then start coding.

Having the sketches and basic notes is a good way to keep my thoughts organised. Without them I end up jumping around the program and forgetting things. I find it best to have some sort of order to what you're doing even if it changes.

share|improve this answer

Think about which algorithms will be used to solve the problem.

Make a Flowchart.

Make the prep code (a form of pseudo-code).

Pick up a programming-language, make real code from prep-code according to the syntax of the language.

Run , Debug.

Happy programming :)

share|improve this answer
    
+1 for algorithms... –  Sardathrion Oct 31 '11 at 9:29

Coding is all those things: design, diagrams, pseudocode, sketches, UML, whatever. Why separate physical typing from the complete process that is coding?

Because you think that you are "jumping right in" by sitting down and typing doesn't mean that essential steps like design haven't already happened, it means that those "not typing" steps are done and you just didn't notice!

So what you're really asking is "what do you do to prepare for typing a lot of words?" And the answer is that I grab a cup of coffee and stretch ;-)

And the answer to the full question of what to do before Coding is... grab a cup of coffee and stretch.

share|improve this answer
   I guess everybody has there own strategy, so what's yours?

I just write the starting code ( including header files, packages etc ) while thinking and it accelerates thinking process in my case, if its taking longer, then I delete the lines already written and repeat.


This is not at all a standard approch , it just works for me sometimes..

share|improve this answer

Well, I launch my IDE. Just kidding. Come to think of it, I don't think I have a 'standard' prep routine. Psuedo coding in my thoughts, flow-charting on papers and sometimes code right away.

However when it comes to UI for a not-so-small user base, I will definitely have mock-ups and have group/user reviews before actual coding.

share|improve this answer

Depends entirely on what I'm supposed to be coding. If I'm inheriting an existing project, I'll usually have a hand-off (me and the previous developer sat at my desk looking at the code) and then dive into the work queues.

If I'm starting a new project, we usually have a design document, just as part of our process. If it's a smaller project that is only used by us (extensions to the build tools, for example) then the design is more informal, often just an email from my boss with basic requirements.

share|improve this answer
    
What kind of design document do you use? What's in it? –  Jason Oct 23 '10 at 16:07
    
Depends on the type and scale of the project. We have an FDD (Functional Design Document) which describes, in some detail, what the software should do, what communications protocols might be used, etc. This is largely to give other developers a sneak peek, and a chance to bring up issues. A more detailed version is the SDD which describes major details about how the software will be implemented - major classes, etc. Major components will get one or the other, but not usually both. Either one would also contain an Impact section and a Risk section. –  JohnL Oct 24 '10 at 12:49

as said, depends. (note, the following is for c++ projects)

For really simple/small projects, just write the thing and run it. Fix where needed.

If I feel like Test Driven (as in test before you code) is the way for a project, I just take a paper and come up with classes I need. Then start writing interfaces and tests for those. The implement one by one.

Other times it's the other way around: come up with needed classes, implement them, write a bunch of tests and debug failures/crashes.

For really huge projects, first split up in smaller parts that can be done with the above principles. This is mostly done by writing on paper, which is after all 10x faster than having to draw diagrams on a computer.

share|improve this answer

As a data specialist, my process is probably somewhat different.

First I need to figure out which servers and which databases I need to be accessing, since just one server might have up to 150 different databases on it and we have 30 or more different servers each of which has different databases, this can take some time.

Since our product is highly different depending on the client even when they share some of the databases, I may need to review some procs and SSIS packages to see exactly where things are stored for that client. I may research some similar work for other clients especially if this is a new client or a task I know we have done in a slightly different customization for someone else. This may lead me through the morass that is our Source Control system, since each client team stores things differently (It's so much fun sometimes being a shared resource!). I may investigate if our standard SSIS imports and exports can be leveraged for this client or if I need to do custom development. Luckily for me, I have in-depth knowledge of our database and can name out of memory about 95% of the tables and databases I need to use for any particular task and can usually figure out the others in less than an hour. Takes a longer for a client I haven't worked with in a long time or one I've never seen. I may spend a day or more with the application developers trying to figure out how we are going to store stuff that the imports need to import and the reports and applocation need to display that is specific to that client alone. For a huge, complicated client, we (the application develoeprs and teh database developers) may spend a couple of months figuring out the database design before we go our separate ways to work on the actual development.

If I am going to be writing complex reporting SQL or exports, I will start by identifying which chunks of data I need in a series of comments. Those will then become the CTEs that will feed to my final large query (it is not unusual to have source queries that take hundreds or thousands of lines of SQL code and ten or 15 different CTEs). In those comments I will note some specific business rules I will need to implement. If it is complex enough, I will write a tech spec that will tell me exactly where each field I need to get is stored. That reduces the time to actually create the complex SQL a good bit.

For Imports, I do a quick import of any new file to a staging table, just to see what is in it (you don't really want to open a 20 million record file directly!). Then I scroll through the data deciding what kind of information is in each column (Often not what they told us would be in it either in terms of actual columns or type of data) and what problems might be in the data. Then I run a lot of ad hoc queries to get an idea of what I might find, especially where there are too many records to really scroll through a big percentage. Once I have seen the file and the data problems it might contain, I sketch out a line of attack often on a whiteboard. Then I usually start with either building a parent package to run our standard imports (using the parent package to massage the data into a from the child package can accept when what they send doesn't match our specs for the standard pacakage (which happenes about 98% of the time) or building a separate import if the client will have unusual business rules and the standard package won't work.

In general I usually spend much more time preparing to write code than actually writing code. Once you really know what you want and have a solid design, development time is usually much less.

Of course when the project is a relatively simple - fix this bad data that got entered into the database (Either through bad data entry or incorrect data sent in the import file), I usually just start writing SQL. Because I know the database structures so well, I can construct the adhoc SQL to fix a serious data problem very quickly.

share|improve this answer

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