Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Even though I work as a programmer, I've never actually been trained as one. Everything I know is self-taught. As part of my continual process of self-improvement, I want to develop better habits/techniques. I'm wondering how most of you design your code before you actually begin coding? Right now, I write an empty program with all my methods and variables commented, and pseudo-code in place of blocks of logic. Do you guys have other tricks/techniques you can share?

Right now, most of my work is in client-side Javascript development but of course, these techniques should be global.


migration rejected from Nov 10 '14 at 9:58

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as too broad by MichaelT, Bart van Ingen Schenau, gnat, GlenH7, Kilian Foth Nov 10 '14 at 9:58

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Read Martin Fowlers papers on agile design, esp. - whether you are interested in agile development or not, this is an interesting paper that's likely to influence your view of what software design means. – Steve314 Jun 15 '11 at 6:22

The only thing which works for me is to work in very small incremental steps. Instead of working out the system on paper or in pseudo-code beforehand I let the system emerge. I know that sounds fancy, but it actually works.

  • I write the simplest possible code required to make the next tiny step work.
  • Once that is proven to work, I see if the code starts to smell (complex, too long) and then refactor until it looks nice.
  • This process then repeats until the whole system is complete.

Note that the refactoring step is incredibly important for this to work. If you skip it, you're gonna end up with a big-ball-of-mud.

+1 This is a great way to make sure your code is not over/under engineered. – Gary Buyn Jun 14 '11 at 9:09
Agree completely especially about the "smell" test and refactoring. Not only to ensure it LOOKS nice, but you should always use your God given talent of intuition. You will know if you have just injected a "kludge" or if your solution will will stand the test of time. Be a bit critial on your code. – Catchops Jun 14 '11 at 12:44
+1 I do the same, but this actually works if your nose is trained enough to recognize when code starts to look too complex or overengineered. Junior programmers can't do this easily. – Pastronio Faruglio Jun 14 '11 at 14:02

I must admit I hate pseudo-code! My technique, such as it is:

  • think for a bit, or for a long while if the project is complicated
  • possibly write an initial spec for things like communications protocols
  • draw some simple block diagrams outlining the architecture
  • make sure I have a development environment set up (VCS, test tools etc.)
  • start writing code
IS there a specific technique you use for diagramming the architecture? It's probably not so important for me doing client-side Javascript development but I'd like to know. – T Nguyen Jun 14 '11 at 7:28
@T Nguyen Nope, just blocks and arrows. Drawn on paper. – nbt Jun 14 '11 at 7:31
I do something similar, though the fourth step there should probably go to the start - it's really important not to get yourself in a position where you feel ready and want to write the code but can't. – Tom Clarkson Jun 14 '11 at 7:35
@Tom: A lot of people already have the environment set up anyway. – Donal Fellows Jun 14 '11 at 7:46
@Neil: +1 to your comment for “Drawn on paper”; if it's too complicated for a piece of paper, it's too complicated to understand at all. (I've been on projects where the architecture was beyond that level; they never delivered satisfactorily precisely because no developer knew exactly where they were and nobody could tell anyone outside the project properly how to deploy things.) – Donal Fellows Jun 14 '11 at 7:49

I typically follow this rough pattern:

  1. Do some rough whiteboarding of the software architecture, so a rough design of the domain model, sequence diagrams, protocols and so forth. You can use formal UML here, but I don't tend to unless there's some really complex sequence or state to follow. Perr design is a good idea at this stage.
  2. Make sure my dev environment is all set-up with CI, static code analysis etc
  3. If I'm brand new to the technology/API, I'll do some quick prototyping.
  4. Then I follow TDD (or BDD/ATDD depending) to write the code. Again pair programming at the start is valuable here.
Thanks. Can you clarify what are TDD, BDD and ATDD? I like the idea of pair programming at the beginning. – T Nguyen Jun 14 '11 at 8:36
TDD = Test Driven Development, BDD = Behaviour Driven Development, ATDD = Acceptance Test Driven Development, I'll update my answer with some links shortly – Martijn Verburg Jun 14 '11 at 9:26

Honest answer?

I just write it, until it works. Then I go back and refine / optimise it later.

I know that this isn't the right way to do things and I wouldn't advise it. It's a total pain to go back and add proper exception handling and to occasionally have to refactor everything into a new structure, but every time I try not to I end up getting so tempted to just write.

My next big programming task is not to learn another language, or a new framework, it's to learn how to stop being so tempted by writing that I don't do enough initial design work. I'm getting better at it, but it's a definite effort.


We have developped very advanced and complex software using model code generation. I mean that I define the structure of my project by creating class diagrams. Once the project structure is defined I write notes on my diagram to explain what each class is supposed to be for and create methods inside.

I then show my class diagrams to the developer team and we talk about it. Usually over 50% of the initial architecture is changed. We update our class diagrams and developers start codding in order to provide a quick delivered project.

We show the first project draft to the end users who usually change his mind and ask for something different. I again update my model and talk with the developer team. The project slowly evolve from a first draft to a stable and well designed project after 4 to 10 iterations. I always keep my UML class diagrams well documented. I don't use printed document which are never really look at by the team but directly add note in the class diagram and on each class, attribute and methods. It is easier because when a developer need to code he just has to click on the class and see it description in a note associated to the class diagram. He can also track the methods by reading it description and looking at the sequence diagram which has been added to the documentation. It is really brilliant way of working because the new code is always added at the right place and the project structure and logic is respected by all coders. I personally think that developers are not dangerous for projects but only bad communication is a threat. The click on class diagram to see what is going on and where and immediately code is better than hundred of documented pages and really very efficient !!

What kind of "advanced" applications do you produce this way? – nbt Jun 14 '11 at 8:58
We develop JEE applications with Eclipse deployed on Weblogic, Jboss or Websphere using Oracle or MySQL databases. – UML_GURU Jun 15 '11 at 8:26

You've probably noticed that sometimes things can get quite messy when you don't think over your code before you write it. Design can help you out when you're planning on how to write your software functionalities, and now you want to be able to start clearing up the mess before it becomes a problem, right? I'd start learning formal software design methods (and perhaps design patterns, but those probably won't apply to JS very often, unless you use every drop of OO programming they one can find in JS.)

You might also want to learn about code complexity and all its related topics such as Big Oh notation and stuff like that. It will provide you with some insight on how to structure your code in ways which make it better.

In practical terms it might be a help to use flowcharts to visualize how the code works.

Can you throw out some buzzwords on formal software design methods so I can Google them and read more? Thanks. – T Nguyen Jun 14 '11 at 8:37
I think all of this is bad advice. Design patterns are a shorthand for experienced programmers (though there is no reason why they should not apply to JS), formal methods are not used much in the industry and certainly won't help with design, big O notation won't help structure your code, and surely nobody uses flowcharts in this day and age? – nbt Jun 14 '11 at 8:39
Although formal methods aren't very often used as such, the knowledge of them allows for better structuring of code through the knowledge of the mechanics behind the structures which can be translated into better code anywhere. Same goes for Big Oh notation. While in itself it is a completely academic affair, using the calculations of runtime and complexity do help you understand where the bottlenecks in your code are, and where you could gain speed by refactoring. JS and UML don't play nice, so lePuss3 or flowcharts are a nice alternative – Onno Jun 14 '11 at 9:46
Knowledge of design patterns (and even better antipatterns too) is a must. They help to create well-designed software. That's why they're called design patterns. They're surely not just "a shorthand for experienced programmers". – František Žiačik Jun 16 '11 at 8:35

I suggest you some literature to give you some new ideas:

If you happen to read them, don't take what they say as absolute rules instead merge their habits with yours until you've refined your design process to be productive enough.

I believe design is a mix of engineering and art, you find the percentage of each that work well for you.


The programming language used makes a difference in design approaches.

When I code in Haskell, for example, I tend to write code top-down and declare the function types first and set the function definitions to undefined. Then I'll compile the code to make sure it type checks before writing function implementations and testing.

In Lisp, other the other hand, I'll write the code bottom-up and test each function individually before writing the next level up.

In SQL, I usually write the whole thing at once and start testing.


My technique is According to this quote “If you don't have time to do it right, how come you have time to do it twice?” First I think about notification , exceptions , error handling and unexpected cases, then start development,


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