Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Akin's Laws of Spacecraft Design (2011) [pdf]

ece.uvic.ca

Post reply on HN
Print view View original

21–30 of 114 posts

Re: Akin's Laws of Spacecraft Design (2011) [pdf]

#21

Post by sho_hn »

martin-t wrote: post #16
barishnamazov wrote: post #10

Law 20 seems to express the state of most startups these days: > "A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."

I'd add to that: If you recognize a good design presented poorly, be the one to stand up and present it well, otherwise you will be stuck with the bad one.

This is key to fulfilling a senior tech leadership role and substantially what people expect to pay you for, if you ever wonder what the mysterious "impact" really means.

Re: Akin's Laws of Spacecraft Design (2011) [pdf]

#23

Post by karaterobot »

I've been quoting von Tiesenhausen's Law of Engineering Design for over a decade, since it is a great summary of why I switched from engineering to product design mid-career. That law is the one that says engineers always wind up designing the vehicle to look like the initial artist's concept. I didn't engineer spacecraft, but on web projects I noticed that whoever made the documents furthest upstream had a ridiculous amount of influence over the outcome of the product. Even just being the one taking notes in the first meeting gives you leverage in a process which, despite claims of being agile, is definitively path-dependent most of the time.

Re: Akin's Laws of Spacecraft Design (2011) [pdf]

#26

Post by AnimalMuppet »

My contributions/spins on this:

The most general problem cannot be solved. (If you don't limit scope, you will never finish. You won't even finish the design.)

If you want it bad, that's how you're going to get it. (That is, rushing a project means you get crummy results. This may be "Hanka's Law", because I first heard it from Steve Hanka, but it may not be original to him.)

Re: Akin's Laws of Spacecraft Design (2011) [pdf]

#27

Post by rawgabbit »

z3t4 wrote: post #5

I like systems that are maintence free and easily replaceable. My experience so far in software engineering is that technologies die, so it should also be easy to replace the tecnology, like the hardware it runs on, the platform/os, the programming language and the framework.

In the big companies I worked, it was easier to replace a system with all its dependencies than to remove a part of it. This had nothing to with tech. It was about getting buy in from the business stakeholders and the internal risk compliance department.

Re: Akin's Laws of Spacecraft Design (2011) [pdf]

#28

Post by sbondaryev »

Law 20: A good design with a bad presentation is doomed immediately

I definitely struggle with this. I run a math education site and I usually focus heavily on technical accuracy but underestimate the presentation.

Hard lesson that being "right" isn't enough if the delivery is clunky.

Re: Akin's Laws of Spacecraft Design (2011) [pdf]

#29

Post by Geonode »

einrealist wrote: post #18

> The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it. (Law 23) So will Musk finally be fired in 2026?

He promises 10, gives the world 4, but everybody else has 1, and he's hated for it.

Re: Akin's Laws of Spacecraft Design (2011) [pdf]

#30

Post by erikig »

Geonode wrote: post #29
einrealist wrote: post #18

> The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it. (Law 23) So will Musk finally be fired in 2026?

He promises 10, gives the world 4, but everybody else has 1, and he's hated for it.

It's been interesting to see how often Elon is chided (even by his supporters) because his reach always seems to somehow exceed his grasp knowing full well that this is by design and not by fault.
Post reply on HN