I have been reading about different software methodologies. Every method has a design phase to some extent, more or less.

I am not clear on what we mean by designing. Does this mean writing your thought process on how you will code the feature? Or it is a way of saying what you have coded or will code.

The point where I am most confused is the real world, which is different than putting your thoughts in documents and saying it will work. Since coding details can change, I don't know what's the point of having a design before coding.

  • 1
    Please don't cross-post your questions verbatim to multiple SE sites.
    – Adam Lear
    Sep 12, 2011 at 13:44

10 Answers 10


First of all, the design is, in my opinion, a process of preparing / thinking over the project / software / application, so it is consistent, fulfilling the goals, meeting the requirements. Design also helps making the software production process more efficient (because it is about some really basic things in the project, how they should work etc.).

Wikipedia says:

Software design is a process of problem solving and planning for a software solution. After the purpose and specifications of software are determined, software developers will design or employ designers to develop a plan for a solution. It includes low-level component and algorithm implementation issues as well as the architectural view.

Which means that you make a plan before building the structure (in this case: software).

And why do we first design, then implement, even if many things change? Please see the following picture (source: http://www.agilemodeling.com/essays/costOfChange.htm) that clarifies this the best (at least I think so):

enter image description here


Good question! (although it's more appropriate for programmers.stackexchange)

I used to ponder this point a lot too; how can you design a program before you've coded it ? I mean you don't know what you're going to write after all!

Well, to me, it comes down to a nutshell that many great artisans of our industry have echoe'd;

A good programmer says 'I can solve this problem' and writes 100 lines of code. A great programmer says 'I've seen this problem before' and re-uses the code they wrote last time.

Designing a program is sitting down, thinking about the various issues of the problem-domain and working out in a general fashion how you might solve that issue, or how you've solved it before, and (more so I've found recently) when to decide whats important and whats not.

I guess what I'm driving at is that Design is all about visualising the bigger picture; but its hard to do so until you've been there at least once.

To use a metaphor, any programmer can write a program that mixes flour and water; but it takes further understanding to make a system that bakes a cake.

Ok, bad metaphor - but I hope you see what I'm driving at.


The intention of a software design is to fail cheap and fail early. When designing your implementation, you're forced to think things through early. It's always cheaper to find out you've made a mistake in a design phase than to realize that 80% of the work that you've done without a design has to be re-factored due to a design flaw.

Others with more experience than you will also have a chance to review your design prior to you spending time implementing your solution and point out any high level errors in your system.

It also gives those who step into your shoes in the future the ability to read something documented rather than try to figure out your code.

Of course, depending on the granularity of your design, some things may change, but the overall architecture stays the same roughly 90% of the time (with enough experience).

  • 5
    I disagree with "The intention of a software design is to fail cheap and fail early".
    – NoChance
    Sep 11, 2011 at 6:42
  • 4
    Why, exactly? The design stage is basically algorithm design and paper prototype (user flow, etc). The overarching intention is to prove all of these out on paper (cheaply) rather than proving it out while writing code. Fail cheap, fail early. Sep 11, 2011 at 6:56

Software design is a stage in a software methodology that when executed results a clear definition of how the problem at hand may be best solved. The design may go into different iterations till its complete. The design may cover different aspects of the system such as Solution Architecture, Application Structure, Database Design, Integration techniques, etc. The input of the design is the planning and analysis deliverable. Software design is not only applied at the system in general but also to each individual component of the system. Software design should be the step proceeding program coding. Different methodologies place design activities in different phases and call them different names.

One meaning of software design can be found in (among lots of others) http://en.wikipedia.org/wiki/Software_design


I find this cartoon very nice: http://www.cs.utexas.edu/users/dsb/CS378/


The IEEE Standard Glossary of Software Engineering Terminology (IEEE Std 610.12-1990) defines software design as "the process of defining the architecture, components, interfaces, and other characteristics of a system or component" and "the result of [that] process". In essence, it's the analyzing of requirements to produce some kind of description of what you intend to build. The end result of the design activities are the equivalent to blueprints for building a building.

Design is usually broken down into a high-level (or top-level) description of the system that identifies various components and how components interact with each other as well as a more detailed description of each of those components that allow them to be constructed.

When you are talking about design at any level, you begin to think of concepts such as distribution (what components will be performing what tasks and where those components will be located), concurrency and task processing, data and events, error handling and fault tolerance, data persistence, interaction and presentation. You also consider the quality attributes (such as maintainability, testability, portability, robustness) of the system and its components.

How you approach design depends on the process methodology that you are using to build the system. For example, in a sequential life cycle, you typically perform "big design up-front" (BDUF), where you take your requirements and produce a high-level design, finalize it (for the most part), use that to create detailed designs, and implement that design. In a more iterative and incremental methodologies, you need to consider all known requirements, but you focus your efforts on designing (and then implementing) a subset of those features at any given time, evolving your product and its design as your add additional features.

The specific approaches and techniques that you use to design your system will also vary depending on what the system is. For example, designing a website for your local little league team, designing a web application for Amazon, and designing software that controls aircraft are all very different in terms of formality and what you need to formally document. The specifics of inputs, activities, and outputs are part of the design activities should be specified in your project planning documentation (which again, might vary in formality from verbal agreements to a large specification, depending on the type of project).


What is Design?

There is some amount of variability what people will include under the heading of design. I think for most it includes systems structure and code structure.

System structure is the macroscopic picture of what the full solution will look like. You think through the solution and make a list of the things you know you will need. For example a common need is a datastore. You then need to decide the specifics, what kind of datastore? Does it need to be a database, what about a persistent datastructure, flat-files, etc. You weigh the needs of the project against the benefits of each implementation in order to choose the one that will best match your needs.

Code structure is also part of design. The overall architecture, and possibly even suggestions on what kind of abstractions to either stay away from or use. Should it be structured as one cohesive system. Should it be broken up in independent components that need to work together. How will the code structure run in a multi-process environment, is that even a concern? Will it be multi-threaded instead, or do we need to worry about distributing work load across different servers? These are the kind of questions you start with.

Why does it come before coding?

It doesn't always come before coding, or at least the final design doesn't. Sometimes you have to prototype to figure out if a design will work. Prototyping is essentially choosing a design you think may work because you can't or won't do the analysis during design phase. That doesn't mean all questions need to be answered up front. Design can be an iterative process, as much as writing code. You have to understand though, that certain decisions have a much broader impact, and trying to change them later will be extremely expensive. Moving a monolithic program to a component or SOA would be extremely expensive. Deciding to change languages is an extremely expensive decision. When you make design decisions you should be aware of the cost associated with rethinking those decisions later on down the line.


Most methodologies have different phases in the software life cycle. It all depends on which methodology you choose. However the gist of most of them is planning, design, coding, implementation/deployment, and then maintenance. But you'll have to look at each different one for what their worth.


Designing is to think of how you will structure your project: what subsystems, components, modules, but also what classes, functions and variables it will consist of. Before you start writing code you do some kind of design in your head, maybe on the function or class level, and maybe its very thin, but you cannot write anything without having a design in your mind.

The design that is done in the design phase is normally on the system level, where you decide what kind of subsystems your product will consist of (for instance web + database server) or what the main components will be (like a user management, audio processing, database abstraction, etc.). Those high level abstractions will help divide responsibilities, help schedule the project and provide the main structuring of the code to be written.

But design is not necessarily a specific phase, its something that is done over and over on different levels of abstraction. And as you pointed out, you will learn a lot when coding, and some parts of the design might have to change, which is perfectly fine. And the major abstractions, the one that were I mentioned before which are defined during design phase, are generally on a high enough abstraction to not be affected by issues on the code level.


In my experience, Design is one of the most important phases of software development, specially for big projects.

Wikipedia defines Software design as:

Software design is a process of problem solving and planning for a software solution. After the purpose and specifications of software are determined, software developers will design or employ designers to develop a plan for a solution. It includes low-level component and algorithm implementation issues as well as the architectural view.

I've seen running into so many problems even when the path appeared to be straightforward and clear enough in the beginning. Spending time on design saves your time by allowing you to foresee the problems that you might run into during the development.

  • I disagree with the part "one of the most important" - All stages in software development are important and critical to its success.
    – NoChance
    Sep 11, 2011 at 6:40
  • @Emmad Yes, I understand that, and that's why I said "one of the most important...". The reason why I think it's highly important is that design being an early stage is critical as flaws in design will make the later on phases of s/w development problematic.
    – Atul Goyal
    Sep 11, 2011 at 6:45
  • What would one of the least important stages be then? ;)
    – back2dos
    Sep 11, 2011 at 9:00

To be reductionist, and to take it as easy as possible but practical, you can think of analysis, design, and implementation as a chain of actions.

Analysis is when you just think about the overall aspects of your project, without thinking about specific platform. For example, should you use web services, or not. Do you want to force your users to use their email instead of user name or not? How long the trial period should be? What payment gateways should you support? These are analysis questions, which have nothing to do with platform and programming language.

When you took your decisions, the next step is to design, or to choose a programming language, a platform (Linux, Windows, iOS), to choose design patterns, to think about the overall architecture of your project (like creating Data Access Layer, etc.). Design is not abstract from platform.

Then you give your design documents to developers, and they should turn those documents into real code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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