Перейти к содержанию


Рекомендуемые сообщения

Законы Акина.


Перевод на Хабре:




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

2. To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong .

3. Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time.

4. Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment.

5. (Miller's Law) Three points determine a curve.

6. (Mar's Law) Everything is linear if plotted log-log with a fat magic marker.

7. At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it.

8. In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point.

9. Not having all the information you need is never a satisfactory excuse for not starting the analysis.

10. When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along.

11. Sometimes, the fastest way to get to the end is to throw everything out and start over.

12. There is never a single right solution. There are always multiple wrong ones, though.

13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate.

14. (Edison's Law) "Better" is the enemy of "good".

15. (Shea's Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up.

16. The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours.

17. The fact that an analysis appears in print has no relationship to the likelihood of its being correct.

18. Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though.

19. The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up.

20. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.

21. (Larrabee's Law) Half of everything you hear in a classroom is crap. Education is figuring out which half is which.

22. When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a program.)

23. The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it.

24. It's called a "Work Breakdown Structure" because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it.

25. (Bowden's Law) Following a testing failure, it's always possible to refine the analysis to show that you really had negative margins all along.

26. (Montemerlo's Law) Don't do nuthin' dumb.

27. (Varsi's Law) Schedules only move in one direction.

28. (Ranger's Law) There ain't no such thing as a free launch.

29. (von Tiesenhausen's Law of Program Management) To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right.

30. (von Tiesenhausen's Law of Engineering Design) If you want to have a maximum effect on the design of a new engineering system, learn to draw. Engineers always wind up designing the vehicle to look like the initial artist's concept.

31. (Mo's Law of Evolutionary Development) You can't get to the moon by climbing successively taller trees.

32. (Atkin's Law of Demonstrations) When the hardware is working perfectly, the really important visitors don't show up.

33. (Patton's Law of Program Planning) A good plan violently executed now is better than a perfect plan next week.

34. (Roosevelt's Law of Task Planning) Do what you can, where you are, with what you have.

35. (de Saint-Exupery's Law of Design) A designer knows that they have achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

36. Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective.

37. (Henshaw's Law) One key to success in a mission is establishing clear lines of blame.

38. Capabilities drive requirements, regardless of what the systems engineering textbooks say.

39. Any exploration program which "just happens" to include a new launch vehicle is, de facto, a launch vehicle program.

39. (alternate formulation) The three keys to keeping a new human space program affordable and on schedule:
       1)  No new launch vehicles.
       2)  No new launch vehicles.
       3)  Whatever you do, don't develop any new launch vehicles.

40. (McBryan's Law) You can't make it better until you make it work.

41. There's never enough time to do it right, but somehow, there's always enough time to do it over.

42. If there's not a flight program, there's no money.
      If there is a flight program, there's no time.

43. You really understand something the third time you see it (or the first time you teach it.)

44. Space is a completely unforgiving environment. If you screw up the engineering, somebody dies (and there's no partial credit because most of the analysis was right...)




1. Инженерная разработка — это цифры. Анализ без цифр — это просто мнение.
2. Создание правильной ракеты занимает бесконечное количество времени. Поэтому следует создавать ракеты, в которых что-то неправильно.
3. Конструирование — циклический процесс. Количество итераций всегда на одну больше, чем уже было. Это верно на любой стадии.
4. Ваши лучшие наработки в окончательном решении будут не нужны. Привыкните жить с этим.
5. (Закон Миллера) Три точки — это уже кривая.
6. На логарифмической бумаге всё есть прямая.
7. На начальных стадиях разработки тот, кто больше всех хочет возглавлять работу, меньше всех подходит на эту роль.
8. В природе оптимум почти всегда в середине. Не доверяйте утверждениям, в которых оптимум в районе экстремума.
9. Недостаток информации ещё не причина откладывать анализ решения.
10. Не уверен — решай приблизительно. Но обязательно вернись к решению, когда появятся настоящие цифры.
11. Иногда самый быстрый путь к выполнению проекта — всё выкинуть и начать сначала.
12. Единственно верного решения не существует. Хотя существует много неверных.
13. Разработка базируется на требованиях. Нет причины делать что-то хоть капельку «лучше», чем указано в требованиях.
14. (Закон Эдисона) «Лучшее» враг «хорошего».
15. (Закон Ши) Все возможности для улучшения решения обычно кроются в стыках. Стыки же и основное место для «косяков».
16. Люди, которые обдумывали эту задачу до вас, не имели прямой связи с мудростью предков. Поэтому не стоит думать, что их решение было лучше вашего. Тем более не стоит выдавать его за своё.
17. То, что решение было опубликовано, не делает его более верным.
18. Опыт проверяет решения в жизни. Слишком много проверки жизнью может обречь казалось бы неплохие решения.
19. Вероятность того, что вы намного умнее всех в своей области, очень невелика. Если в ваших расчётах финальная скорость вышла в две скорости света, то вы, возможно, изобрели телепорт, но скорее всего вы просто накосячили.
20. Плохое решение с хорошим отчётом — со временем будет отвергнуто. Хорошее решение с плохим отчётом будет отвергнуто сразу.
21. (Закон Ларраби) Половина того, чему вас учили преподаватели — полная чушь. Осталось разобраться, которая половина. В этом суть образования.
22. Если сомневаешься — документируй. (Потребность в документации достигает максимума вскоре после закрытия программы).
23. Расписание срока работ, которое вы составите, всегда кажется отвлечённой фантастикой, пока заказчики не уволят вас за его несоблюдение.
24. Это называется «Work Breakdown Structure» (порядок разбивки работы), потому что вы будете Work пока не настанет Breakdown, и придётся внедрить какой-то Structure.
25. (Закон Баудена) После провала испытаний, всегда можно улучшить расчёты, показав, что негативная вероятность присутствовала изначально.
26. (Закон Монтемерло) Don't do nuthin' dumb — не надо делать фигню!
27. (Закон Варси) Сроки смещаются только в одну сторону.
28. (Закон Рэнжера, иногда ошибочно Закон Хайнлайна) TANSTAAFL: There ain't no such thing as a free launch. Примерно переводится как «Бесплатно кормят только на убой» или «бесплатно просто так не покормят».
29. (Закон управления проектами фон Тисенхаузена) Чтобы получить примерно точные окончательные требования по программе, умножьте значения начальных требований на число Пи, и сдвиньте десятичную точку на одно положение вправо.
30. (Закон инженерных решений фон Тисенхаузена) Если хотите, чтобы ваш вклад в конструкторскую разработку инженерной системы был максимальным, научитесь рисовать. Инженеры всегда в конце концов делают что-то похожее на картинку концепт-художника.
31. (Закон эволюционной разработки Мо) Нельзя добраться до луны, залезая с каждым разом на более высокое дерево.
32. (Закон демонстраций Аткина) Когда всё работает как надо, действительно важные посетители не приходят.
33. (Закон планирования програм Паттона) Хороший план насильно исполненый сейчас, лучше чем идеальный на следующей неделе.
34. (Закон планирования задач Рузвельта) Делай что можешь, там где ты есть, с тем что под рукой.
35. (Закон дизайна Сент-Экзюпери) Дизайнер знает, что достиг совершенства, ни тогда когда уже нечего добавить, а когда уже нечего убрать.
36. Обычный инженер делает элегантные системы. Хороший инженер — работающие. Настоящий инженер — эффективные.
37. (Закон Хэншоу) Важнейшая вещь в успехе программы это чётко выстроить ряды виновных.
38. Возможности повышают требования, игнорируя ограничения из учебников.
39. Любая космическая программа, в которой «оказалась» разработка новой ракеты, по факту есть программа разработки новой ракеты.
39. (альтернативная формулирока) Три правила сохранения космических програм в пределах бюждета и сроков:
1) Никаких новых ракет.
2) Никаких новых ракет.
3) Делайте что угодно, только никаких новых ракет.

40. (Закон Мак-Брайена) Не надо улучшать то что ещё не заработало.
41. Никогда не хватает времени сделать всех нужных элементов, но почему-то всегда хватает времени сделать много ненужных.
42. Космос совершенно не прощает ошибок. Если инженер ошибся то кто-то погибнет (и нет такой вещи как «частичная вина», мол, в основном-то решение было правильным).



Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Ответить в этой теме...

×   Вставлено с форматированием.   Восстановить форматирование

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

  • Расскажите друзьям

    Нравится Официальный форум компании Нанософт? Расскажите друзьям!
  • Создать...