Software design just like any other engineering design endeavor, requires a fair amount of effort, experience, patience and knowhow in order to be done right.

Based on Akin's Laws of Spacecraft Design I present our readers with a slightly modified list of what I believe are the basic "Laws of Software design" especially when you are dealing with customer oriented, "tailored" software product solutions.

As this is considered a "basic" list, let me clarify that you are more than welcome to contribute with you own experiences and comments on the matter. So lets start ...

Java Code Geeks: Laws of Software Design

Amusing list with some pearls of wisdom.  Too many pointless items, I think, though.

Right off the bat, I'm confused by the first one:

"Software design is done with numbers. Analysis without numbers is only an opinion."

Is this about design or analysis?  I'm not sure I understand what a software design "with numbers" looks like.  Something like "the average girth of the proposed classes is 2.8"?

Probably the most important to understand for teams is "There is never a single right solution. There are always multiple wrong ones, though."

My own: When your software must interface with software written by someone else.  If you wait for the other guy to figure out the (inevitable) issues, you will be waiting forever:  the other guy will be waiting for you to figure it out.

The list has some amusing items simply because it's based on spacecraft engineering tips. The first one, for example, makes sense when applied to real engineering and not so much when applied to software engineering:

1. Engineering is done with numbers. Analysis without numbers is only an opinion.

Same with "learn to draw" and some others, I guess ;-)

Amusing list with some pearls of wisdom.  Too many pointless items, I think, though.

Right off the bat, I'm confused by the first one:

"Software design is done with numbers. Analysis without numbers is only an opinion."

Is this about design or analysis?  I'm not sure I understand what a software design "with numbers" looks like.  Something like "the average girth of the proposed classes is 2.8"?

Probably the most important to understand for teams is "There is never a single right solution. There are always multiple wrong ones, though."

My own: When your software must interface with software written by someone else.  If you wait for the other guy to figure out the (inevitable) issues, you will be waiting forever:  the other guy will be waiting for you to figure it out.

My interpretation of that quote is that you need as much as possible empirical data to drive design time decisions.  Making design time decisions based on opinions, hearsay, anecdotal fables, etc.,  is very risky.

blabla blabla blabla

Design is reality, not blabla

Since we're sharing.. here's mine:  Design is only as good as the requirement.  If the requirement is wrong in the first place, you can chuck your design in the bin, same goes for the implementation.

Unfortunately, I've seen many PMs that can't seem to grasp this simple logic.

That is all.