Software Best Practices

Let’s start with definitions of software design, or at least attempts.

• Definition #1: Software design is a strategy to reduce the complexity of problem. 
• Definition #2: Software design is an arrangement of a million moving parts into something that will make sense in a year from now. 
• Definition #3: Software design is a plan to use known tools (“code”) to solve a known problem.

I’m sure there are many other, better definitions.  I present these three because there are at least three different levels of software design that each needs a slightly different definition:

System Level Design: (i.e. Architecture,” Big Picture”, multi-program/system, 100k LOC)

Here the primary goal is to divide and conquer into smaller units via a clear definition of scope, responsibility and interfaces. See definition #1.

Program Level Design: (i.e. single large program, 30k LOC)

Here the primary goal is, arguably, understandability.  Software design at this level is concerned about data representation, coupling and cohesion, encapsulation and other similar concepts. See definition #2.

Module Level Design: (i.e. class design, function design, 1k LOC)

Design here is concern about performance, robustness, and correctness. See definition #3

I’ve mixed a lot of material here: software design definitions, goals (e.g. “reduction of complexity”, “understandability”), and core techniques (e.g. divide and conquer).  Hopefully this will serve to promote further discussion, which is what this is all about.

Software Design is an answer to the user requirements -- most probably the problem -- with well defined boundaries.

Software Design is an answer in terms of "How to do ..." to address the problematic area.

Hi Scarnegie, Welcome to the Conversation!

Whoa! Don't get me started on this one :-)  I mostly agree Shahid on this one. However, I don't find the answer as useful as it could be. Let's try to take it a bit farther.

Earl Definition: Design is the decisions made about what you are asked to solve at the level of detail necessary to take you to the next step.

Background: I see requirements and design are essential similar items. Both are decisions about something. Requirements are decisions about the problem or opportunity. Designs are decisions about the solution to solve the problem or take advantage of the opportunity. The real question that separates requirements from design is what are you being asked to solve?

If I ask you to build an automobile, then all the decisions about the automobile itself are designs. My lifestyle, family, work, recreation, favorite colors, etc. are part of the opportunity and so are requirements. The actual car color, its shape, its engine, are all design.

If I ask you to build a transmission, then the all the decisions about the transmission itself are designs. All the other components of the car are now part of the opportunity/problem and become requirements.

So the trick is, I think, is knowing what are you asked to solve. Design them becomes the process of making decisions about that.

The second part of necessary detail is then what are you going to do with those decisions? I don't need to decide low level detail stuff if all I am trying to do is to get a conceptual picture of the project in order to allocate to sub-teams. So the question of design levels, I think, rest solely on what actions are we wanting to take with the decisions we make. Make appropriate decisions.

Some additional thoughts I'd throw onto the good ideas in this thread:

• Shared Understanding. A big part of design is about achieving a shared understanding of how the system will be constructed by those who will be doing the construction. The nature, depth, detail, structure, timeline, and formality of your design can be scaled in many ways to adjust for this goal.
• Design as an Art. Good design is both an art and science, and should not be reduced to rigid methodology. For example, although it often makes sense to leave performance optimization until later, some aspects of system performance may need to be dealt with early in the design process to ensure success (e.g., scalability or response time of a distributed system).
• Tradeoffs.  Much of the art of design is deciding between tradeoffs. There is no perfect or right design, only tradeoffs. Sometimes the art is realizing when a coin flip is better than a long exploration of competing (but ultimately equivalent from an economic perspective) tradeoffs.
• Technology. Technology selection and how technology will be used is an important part of design, particularly architecture.
• Multiple Views. The more views you can get into a design space the better. Seeing the same things from different angles, perspectives, and levels of abstraction can greatling enhance shared understanding.

Quite a challenging task: to delineate and to set the limits of the essential quality for software design. Why do we need to define something? Perhaps to understand it, and then explain it, and then reflect on it as we move ahead.

Let’s say: Software design is a solution for a problem in a given context and also it is the process to get from the definition of such a problem all the way through its solution.

http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

http://www.developerdotstar.com/mag/articles/reeves_13yearslater.html

Software design as a verb and the outcome of such action, software design as a noun, have been quite interesting to cogitate about for some years now. One remarkable thing keeps on constant along the way: practicing software design is an exciting, exhilarating, electrifying activity.

There are sound principles to know-how about software design, foundational rules enforced by the underlying properties of what the software is made of. Interesting thing is that many professionals feel that software design ought to be part of a full-fledged engineering discipline; that is the desired map but, look often because the terrain could impose its own rules. We all can observe how large has been the impact of the people dimension upon software design as a verb and as a noun that, perhaps, a different approach to our bellowed activity could be better for the future to come; that is why I somehow like the paper by Jon Pincus entitled “Computer Science is Really a Social Science”.

Another curious thing about the software design concept many people take for granted is that design is about grandiose internal structures and flamboyant architectures full of technicalities, yet the software designed that way often fail at the last step, just before the end-user.

That is why some software designers know that architecture is not about scalability, not even about user, it is all about usage

Earl wrote "So the trick is, I think, is knowing what are you asked to solve. Design them becomes the process of making decisions about that."

I think that is the hardest part of software development. I do consulting so, until I get to know my client I have no idea what their business is about. Things that seem obvious and not worth mentioning are completely foreign to you. They often use ordinary words, but in their domain they have a very specific and perhaps unusual meaning.

 So you need to make sure you understand what they are asking for and that you are both talking the same language.

Then, as Earl says, you need to understand the problem you are going to solve. That makes the software so much easier to develop.

 If you understand the problem then you are closer to understanding the solution. I find that the difficulty with the actual programming is knowing what to code, not the actual coding. I have magnetic white board next to me in my office. On the white board I stick a statement of my understanding of the problem. When the stuff I am writing gets to be a bit obtuse I look at the problem and ask myself "Is this getting me closer to a solution?" I also find that to be a useful question to ask clients when they ask for additional features.
 

I believe that defining things is utterly important. We cannot understand something that we cannot put to words, and defining is the very act of putting something to an explained form. This should be obvious to anyone who has ever went to explain someone else what the problem w/a particular piece of sw is, and in the very process of forming the question into words gets the answer herself.

To what `software design' is, I'd say that first of all it is design - the willful act of reasoning and intuiting via using technologies in an artful manner to create something that fulfills a specific need. Software then - I'd see it as a structured way of writing down what you mean in a way that these instructions can be followed mechanically. So how does this combine to make up `Software design' ? It would be:  The willful act of reasoning and intuiting via using technologies in an artful manner to create something that fulfills a specific need in a structured way that allows these instructions being followed w/o will or understanding.

...

A few more comments regarding the previous posts:

1. One can never reduce the complexity of a problem, an sich. The problem has a specific complexity, and the task of the designer is to attempt to find the complexity-wise optimal solution to the problem. The KISS principle is closely related to this. Do note that sometimes the optimal solution is to use sub-optimal tools and libraries to avoid the hassle of starting solve other problems than the one at hand.

2. Finding out what-to do precedes finding out how-to. In principle.

3. Sometimes it's good to do something in a way you have done it before. That way you know a whole lot more about what you're about to do, and that helps in intuiting the hazards and making estimates of how long it's going to take.

4. Multiple Views is in contradiction w/Shared Understanding. The more designers you have the harder it is to make them agree about anything.

5. And yes, designers are like cats. Herding cats is very much what it is all about.

 My definition:

• Design is the consideration of all the different alternatives and choosing the most appropriate one.
•  It narrows the set of choices left open to you.
  
• Design is thinking about the problem and producing a plan which will eventually lead you to a solution.
  
• It isn't the end solution!
• Design is the opportunity for a software developer to apply their creativity to a problem.
• It shouldn't be a rigid process that doesn't allow any freedom - not if you want great, innovative products.
• Design isn't a 'distinct' stage - it happens throughout the software development process, albeit at different levels at different times.
  

Good software design is taking a complex problem and solving it with the simplest method or methods possible.

----

Albert Einstein, “Make things a simple as possible, no simpler”.

This is my moto for software design. As a previous reply mentioned the same idea, keep it simple.