Skip to main content
Tag

NASA

Luna USA Field Trip: the lunar lander – minimum viable product

By Agile, Space, TechnologyNo Comments

Field trips to the Smithsonian are highly recommended by Luna Tractor! The lunar lander LM-2 is stored in the Washington DC Air and Space Museum.

We’ve already referred to the Lunar landing Module (LM in NASA parlance) as the greatest machine ever built. The chance to see a replica in Washington DC was very exciting.

So imagine my amazement to discover that the machine is NOT a replica. It is LM-2, the module they built as a spare unit in anticipation of something going wrong with one of the others. As it happened, things went smoothly (if you don’t count Apollo 13) and it stayed in the shed at Cape Canaveral.

The lesson that the Lunar Module teaches us is fitness for purpose – an old definition of quality that has stood the test of time. Take a close look at the panels on the module – it is riveted together with the bare minimum of materials to keep it light.

“Why isn’t it shaped like a plane” asked my traveling agile assistant, whom we shall call ‘Retro-Boy’. The answer lies in the fact that aerodynamics are somewhat irrelevant in a vacuum.

The modular design of these craft allowed the lessons of the previous Apollo mission to be incorporated quickly into the next mission.

Challenger 1986: NASA’s most explosive retrospective.

By Agile, Communication, People, Space, TechnologyNo Comments

Space Shuttle Challenger in one of the most famous (and chilling) space photos of all time.

As I read this week’s Telegraph obituary of a great American rocket scientist, I was moved to thinking about how we deal with the whistleblowers and truth-tellers in an agile world.

How can we strike a balance between encouraging transparency and realism, while managing the impact on the morale of tight-knit teams from Negative Nigels and Whining Winifreds?

I’ll be the first to say that the command and control culture of committed waterfallers (like NASA) is a fast track to secrets being kept, and problems being swept under the carpet. When “failure is not an option” on a project racing toward a fixed launch date, with scope being secretly trimmed off Gantt charts to ensure compliance with public commitments and budgets, and all-nighters pulled by tech heroes, we are just hiding failure.

Is agile any different? If it is effective, yes. But agile zombies, with their card carrying undead marching into retrospectives and standups ritually chanting out their obligations so they can get back to their desks as quickly as possible, is probably just as bad as waterfall.

This tragic tale of an ignored voice is a stern reminder of the consequences of avoiding talking about engineering issues.

When I arrived at Lonely Planet in 2007, and proceeded to shut down a failed waterfall-delivered website program, the HR team had already initiated a training program called Effective Conversations. It seemed uncomfortably basic and quaint in intent – teaching people to get good information across quickly and confidently when in meetings, in casual conversations, one on ones, or in the lunch queue.

A month later, I knew it was gold – I had yet to find a person who did not say “I knew that would happen”. People had just not managed to get the complexity and interdependence of the hairball of product and architecture problems across to Steering Committees and executives. And after a few public scoldings for being naysayers, they learned to shut up and soldier on.

Edward Tufte tackled this same issue of communicating complexity for NASA after the second major shuttle program disaster – Columbia in 2003. This $7 report from his website is one of the best training guides for agilists to invest in around effective written communication.

The constraints put upon Boeing and NASA engineers to explain the complexity of the situation where chunks of insulation had broken off the booster rockets and damaged the heat protective tiles on the leading edge of the wing, using Powerpoint slides with bullets points and a constrained number of words per line, was too great. The wrong decision was made to not space walk and inspect the damage.

I wonder if that was a ‘didn’t work’ or just a ‘puzzles us’ in a retro sense? Either way it signaled the beginning of the end for the second great chapter of the USA’s space exploration efforts. If you are facing an ever increasing complexity in your product and IT architecture, our advice is to put as much investment into improving everyone’s communication skills as you are any engineering effort.

Buy your copy of Edward Tufte’s handbook from his website here.

A Photographic History of the Space Shuttle

By UncategorizedNo Comments

As the last shuttle flight landed a few days ago it seems like a good time to post this magnificent set of photographs via the quirky site www.cracktwo.com – A couple to wet your appetite and a link to the full series is at the bottom.

Columbia lifting off April 12, 1981

On the back of a 747 being transported back to the Kennedy Space Center.

And that’s a long way down, see the rest of the series at Crack Two

Lessons from a Martian Mission

By UncategorizedNo Comments

NASA has just announced the end of the Spirit Rover mission on Mars after no successful contacts since it’s last communication on the 22nd of March 2010. Not a bad effort for what was planned as a 3 month mission starting in January 2004.  There are some great lessons that come out of these missions.

1) Their goal was simple and easy for everyone to understand – “Wear the rovers out exploring, to leave no unutilized capability on the surface of Mars”

2) Their planning was Agile – As the rovers lasted longer and longer the mission team kept rewriting their play book and planning new experiments – “What we initially conceived as a fairly simple geologic experiment on Mars ultimately turned into humanity’s first real overland expedition across another planet.”

3) Sometimes the greatest discoveries come in the most unexpected ways. After the front right wheel stopped working it started to act as a plow when the rover went into reverse; This unplanned ‘feature’ dug up bright white soil enabling one of the most exciting discoveries of the mission, pure silica deposits just under the surface indicating that previously the conditions required for microbe life existed.

You can read more here about Spirit and Opportunity, perhaps NASAs most successful and cost effective missions ever.

Getting a job *should* be hard.

By UncategorizedNo Comments

Today I gave a reference for a long time colleague and friend, most of the time the questions people ask when checking CV references are barely more sincere than the standard 4 questions real-estate agents ask when checking potential tenants. It’s a fait accompli.

A real employment exam: this 1964 photo shows a NASA scientist testing astronaut John Glenn’s inner ear balance mechanism by running cool water into his ear and measuring the effect on Glenn’s eye motions.

This time was different, it took 20+ min and they asked deep probing questions. We quickly got beyond the basics of establishing my colleague was capable and moved into questions about the best environment, growth areas and how to get the best out of this person. These guys really cared about getting the right person, but also that the job was right for them as well. They also wanted to know how to make it the best possible engagement for everyone. For them hiring was a long and through process which required a significant commitment from everyone involved, myself included.

When you audition to join the Berlin Philharmonic Orchestra, widely regarded as one of the very best in the world you play the equivalent of a full recital in front of the entire orchestra. It’s very very hard to get in, but when you do, everyone knows how hard it was and knows you’ve earned your place. After all, they were part of the group that picked.

If you’re hiring staff, be ruthless – it should be hard to get in. Stop and think about how much time you spend with an individual making a decision which has consequences (good or bad) which both you and your potential employee will live with for many years to come. Is a 45 min interview with someone from HR and one manager really enough ?

I often hear discussions of how arduous the hiring process at some companies is, and how it turns people off from applying. Google is (in)famous for it’s complicated and exhaustive hiring process. Turning people away because the process might be hard is a good thing. As a potential employee if you’re not prepared to invest a few hours, maybe even a few days in finding out if a job is right for you, are you really excited enough about working for the company ? Wouldn’t you rather know that everyone who you might be working with has had to step up and deliver against the same set of challenges, interview and interrogations.

Getting a job should be hard.

Akin’s Laws of Spacecraft Design

By Uncategorized

Akins has collected a wonderful set of laws for Spacecraft Design, most of them are equally relevant for other engineering projects.  Just be glad that rule 40 doesn’t apply to your project.

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 he has 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. The three keys to keeping a new manned space program affordable and on schedule:       1)  No new launch vehicles.       2)  No new launch vehicles.       3)  Whatever you do, don’t decide to develop any new launch vehicles.
40. 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…)
(source – http://spacecraft.ssl.umd.edu/akins_laws.html)

Why Luna Tractor?

By Moon, Uncategorized6 Comments

An ingenius solution driven by re-framing the question.

While the Americans were busy landing men on the moon for a few days at a time and playing a little golf the Russian space agency was taking a different approach in their race to the moon.  They built and successfully deployed the first remote-controlled robot to explore another body in space.

Landing in 1970, Lunokhod 1 significantly out lasted its original 3 month mission, sending back images for 11 months after traveling over 10km on the lunar surface.  A second mission Lunokhod 2 was sent in 1973 and covered 37km, operating for 4 months.  To this day it holds the record for the longest distance of surface travel by any extra-terrestrial vehicle.

Some perspective on the Russian achievement: the Mars Rovers have covered less than half the distance and transmitted back about the same number of images using technology some 40 years more mature.

The Apollo program racked up a final bill of $25.4b in 1973 ($170b adjusted to present day).  Each Mars rover has cost the US $400m, so in 1970 the Lunokhod program would have cost Russia perhaps $50 million in 1970 dollars? Personally I think the Apollo program is just magnificent, one of humanity’s great engineering achievements, but the little Lunokhod got rather better bang for buck.

So why Luna Tractor? The Lunokhod – or our English version, Luna Tractor – is a reminder to think laterally about problems, have some imagination and shoot for the moon by being a little bit different.

PS: It is of course still up there, recently photographed by the NASA Lunar Reconnaissance Orbiter.  Thanks to reader Ross for the link.

Subscribe to the Luna Newsletter

Close Menu

Quote of the week

The new competitive advantage is the ability to anticipate, respond and adapt to change.

Recent Luna Posts

Become Remarkable.