How do you design code?

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.

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

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.

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 !!

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.

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

• The Pragmatic Programmer
• Code Complete, 2nd Edition, link to the design chapter

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,