1. Correct me if I missed it, but I did not see anywhere the striving for "elegance" in design (many other references and documentation abound discussing "elegant design")
2. Here's a few 'heuristics' to consider:
Some heuristics for building a system
The conceptual phase:
• The choice between architectures may well depend upon which set of drawbacks the client can handle best
• Extreme requirements should remain under challenge throughout system design, implementation, and operation
• Don't assume that the original statement of the problem is necessarily the best or even the right one
• No complex system can be optimum to all parties concerned, nor all functions optimized
• A model is not reality
• Complex systems will develop and evolve within an overall architecture much more rapidly if there are stable intermediate forms than if there are not
• Build in and maintain options as long as possible
• Don't make an architecture too smart for its own good
The build and test phases:
• The product and process must match
• An element good enough in a small system is unlikely to be good enough in a more complex one
• Within the same class of products and processes, the failure rate of a product is linearly proportional to its cost
• High-quality, reliable systems are produced by high-quality architecting, engineering, design, and manufacture, not by inspection, test, and rework
• Regardless of what has gone before, the acceptance criteria determine what is actually built
• To be tested, a system must be designed to be tested
• Qualification and acceptance tests must be both definitive and passable
• The cost to find and fix a failed part (or software bug) increases by an order of magnitude as that part is successively incorporated into higher levels in the system
The operations phase:
• Before the flight, it's opinion; After the flight, it's obvious
• The first quick-look failure analyses are often wrong
• For every competitive system, there is a countersystem
• Success is defined by the beholder, not the architect
• There's nothing like being the first success
Systems Architecting: Creating and Building Complex Systems, by Eberhardt Rechtin, 1991
These are very good additions. I anticipate there will be follow-on concepts to discuss from a design perspective. My goal for this essay was to get people to consider designing first let alone all the other aspects to it.
I do like elegant design and that's planned for another essay on 'Keys to Innovation' based on the book F.I.R.E. where the E in that acronym is Elegent.
Love this. My favorite line is: The problem with proofs of concept isn’t that they fail, it’s that they don’t scale
I also love your 55/5 design-to-doing ratio, which I just wrote about. HOWEVER I might add one dimension, which you certainly document nicely here: SHIPPING and STARTING OVER. That is, I think the danger of the 55/5 idea is that it might be interpreted as causing analysis paralysis, that you just sketch all day.
The longer view of creativity is more like a long assembly line of 55/5 sprints of work:
Wow. I haven’t thought about this in years. I was in Mechanical Computer Aided Engineering (MCAE) for years, (mechanical engineer here) we developed a solid modeling / plus software suite. It was used for designing things like brakes in cars and other auto parts, heat shields for NASA, America’s cup sailboat hulls. One of the biggest issues we faced with customers using the software was the lack of time defining the problem. It always amazed me how these designers completely forgot asking “why?” first. It’s one of the most important aspects of Engineering I taught my kiddo in our homeschool. He is an Aerospace Engineer working in that field now. The other two ideas I sent him out with: KISS (keep it simple stupid) and “reduce it to a known problem”. Old-timer sentiments.
I understood what you meant when you wrote “But does it scale?”, some may not. Might be a nice touch to define what “scale” means in this instance. Seems key to the ideas.
Great thoughts! Scale here is the scalability function typical to software and proofs of concept. For example, if I create a cloud software and it works for 100 users and X-volume of data, will that design work for 10x users and data?
Also proofs of concept are scaled down versions to test and idea. Too often they worked, but can't be applied back to the whole.
If your Aerospace Engineer ever wants to talk about the industry, feel free to put him in touch.
1. Correct me if I missed it, but I did not see anywhere the striving for "elegance" in design (many other references and documentation abound discussing "elegant design")
2. Here's a few 'heuristics' to consider:
Some heuristics for building a system
The conceptual phase:
• The choice between architectures may well depend upon which set of drawbacks the client can handle best
• Extreme requirements should remain under challenge throughout system design, implementation, and operation
• Don't assume that the original statement of the problem is necessarily the best or even the right one
• No complex system can be optimum to all parties concerned, nor all functions optimized
• A model is not reality
• Complex systems will develop and evolve within an overall architecture much more rapidly if there are stable intermediate forms than if there are not
• Build in and maintain options as long as possible
• Don't make an architecture too smart for its own good
The build and test phases:
• The product and process must match
• An element good enough in a small system is unlikely to be good enough in a more complex one
• Within the same class of products and processes, the failure rate of a product is linearly proportional to its cost
• High-quality, reliable systems are produced by high-quality architecting, engineering, design, and manufacture, not by inspection, test, and rework
• Regardless of what has gone before, the acceptance criteria determine what is actually built
• To be tested, a system must be designed to be tested
• Qualification and acceptance tests must be both definitive and passable
• The cost to find and fix a failed part (or software bug) increases by an order of magnitude as that part is successively incorporated into higher levels in the system
The operations phase:
• Before the flight, it's opinion; After the flight, it's obvious
• The first quick-look failure analyses are often wrong
• For every competitive system, there is a countersystem
• Success is defined by the beholder, not the architect
• There's nothing like being the first success
Systems Architecting: Creating and Building Complex Systems, by Eberhardt Rechtin, 1991
These are very good additions. I anticipate there will be follow-on concepts to discuss from a design perspective. My goal for this essay was to get people to consider designing first let alone all the other aspects to it.
I do like elegant design and that's planned for another essay on 'Keys to Innovation' based on the book F.I.R.E. where the E in that acronym is Elegent.
Love this. My favorite line is: The problem with proofs of concept isn’t that they fail, it’s that they don’t scale
I also love your 55/5 design-to-doing ratio, which I just wrote about. HOWEVER I might add one dimension, which you certainly document nicely here: SHIPPING and STARTING OVER. That is, I think the danger of the 55/5 idea is that it might be interpreted as causing analysis paralysis, that you just sketch all day.
The longer view of creativity is more like a long assembly line of 55/5 sprints of work:
55/5---55/5---55/5---55/5---55/5---55/5---55/5---55/5---55/5---55/5---55/5---55/5--------
Something like that!
That's a great point. The DevOps style rapid iteration.
Wow. I haven’t thought about this in years. I was in Mechanical Computer Aided Engineering (MCAE) for years, (mechanical engineer here) we developed a solid modeling / plus software suite. It was used for designing things like brakes in cars and other auto parts, heat shields for NASA, America’s cup sailboat hulls. One of the biggest issues we faced with customers using the software was the lack of time defining the problem. It always amazed me how these designers completely forgot asking “why?” first. It’s one of the most important aspects of Engineering I taught my kiddo in our homeschool. He is an Aerospace Engineer working in that field now. The other two ideas I sent him out with: KISS (keep it simple stupid) and “reduce it to a known problem”. Old-timer sentiments.
I understood what you meant when you wrote “But does it scale?”, some may not. Might be a nice touch to define what “scale” means in this instance. Seems key to the ideas.
Good stuff.
Great thoughts! Scale here is the scalability function typical to software and proofs of concept. For example, if I create a cloud software and it works for 100 users and X-volume of data, will that design work for 10x users and data?
Also proofs of concept are scaled down versions to test and idea. Too often they worked, but can't be applied back to the whole.
If your Aerospace Engineer ever wants to talk about the industry, feel free to put him in touch.