Comments on: Unit Testing, TDD and the Shuttle Disaster

By: Dercsár Péter

Dercsár Péter — Wed, 22 Apr 2009 09:52:43 +0000

And here is a beautiful contrast (as in bottom-up vs. top-down):

http://toomanylayers.blogspot.com/2008/11/barkburn.html

Couldn’t resist to post it here.

By: Garry

Garry — Thu, 20 Nov 2008 10:16:38 +0000

Excellent post Stephen. Over the years I have come across numerous references to engineering/architecture overlapping with software development methodologies; UML, Design Patterns and now unit testing. I’m sure NASA have learnt from this and will use a bottom-up approach to the new Shuttle replacement program.

By: stephan

stephan — Tue, 18 Nov 2008 12:16:48 +0000

@Maik: Thanks for the insight. “Oh, btw: Did you know the whole “design patterns” concept was originally taken from an architecture book?” Yes I did and found that interesting, but it didn’t really catch on with architects, did it? And it seems thta the pattern hype was too big too (I’m not a pattern hater like some in the blogosphere though)

@nl0tz: Unit testing shouldn’t free you from integration testing.

By: nl0tz

nl0tz — Tue, 18 Nov 2008 12:01:01 +0000

I’m afraid that wouldn’t have helped the 1999 Mars Polar Lander: It crashed during landing because a rocket engine shut off prematurely (130 feet above ground). As it turned out, different subsystems were using different units of measurement (feet vs. meter).

The moral of the story: You should communicate more.

By: Maik

Maik — Tue, 18 Nov 2008 10:18:38 +0000

Good post. I believe most “modern” software design methods are in fact very old and understood – just not in the field of software development. I remember a similar moment not too long ago: Someone commented in a well known Scrum blog that all of this stuff (small empowered teams, quick daily meetings, backlog with well defined tasks, estimation and commitment) was exactly what his father told him how engine maintenance was done at an Air Force Base 40 years ago (and probably is today, still). There are certain patterns that just emerge when dealing with complex systems. It’s ironic we as software developers are spending so much time reinventing the wheel (process-wise) when that is exactly what we are trying to avoid in our every day (programming related) work.
Oh, btw: Did you know the whole “design patterns” concept was originally taken from an architecture book? Interesting how much can be learned from other disciplines if we just keep an open mind. We are not as special as we might like to think ;)

By: stephan

stephan — Mon, 17 Nov 2008 19:38:36 +0000

@Matt: Thanks

@Jason: I can remember that one :-)

By: Jason M.

Jason M. — Mon, 17 Nov 2008 18:31:37 +0000

“CALVIN: How do they know the load limit on bridges, Dad?
DAD: They drive bigger and bigger trucks over the bridge until it breaks. Then they weigh the last truck and rebuild the bridge.”

By: Matt Simmons

Matt Simmons — Mon, 17 Nov 2008 18:21:56 +0000

Stephan, Great post. This isn't limited to the software development and astrophysics worlds! ;-) Trackback

By: Itay Maman

Itay Maman — Mon, 17 Nov 2008 13:40:34 +0000

@Stephan: Right! I went, more or less, through the same feelings as I read your post.

By: stephan

stephan — Mon, 17 Nov 2008 13:37:38 +0000

@Itay: The Feynman article was thought provoking for me too, and then a flash hit me: This is like unit testing. I was electrified.

By: Itay Maman`

Itay Maman` — Mon, 17 Nov 2008 13:30:38 +0000

That’s a really excellent, thought-provoking, analogy. Thanks for sharing it.

Especially interesting (to me), is the issue of the negative implications of ending up “with an architecture which doesn’t fit your problems”. I used to get that a lot with my programs, before I started practicing TDD.

Back then, I used to make my design bulletproof (http://javadots.blogspot.com/2008/11/bullet-proof.html) in order to keep me away from mistakes. This resulted in rigidness, inflexibility, lack of interoperability, and downright degraded productivity.

TDD (an even unit-testing for that matter) made this problems go away.