Discussions

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

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.

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.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.