Yes, I’ve not blogged, nor produced the requested DargoReader screenies (they’re coming I promise) - but it’s been crunch time this last week or so - hopefully I’ll have more spare time this coming week to get some decent work done. Tonight for a quick change of pace, I’d like to talk about project planning and the inevitable clash that happens between developers and managers when it comes to timing.
Every developer has experienced the dread that accompanies delivering your estimated time to completion, only to have management cut it in half - usually for the worst reasons. It happens. Some times it happens because of promises management has made to the client, or a general feeling that “it shouldn’t take that long”. Whatever the case, it’s a fairly common problem. This means that developers end up taking short cuts or not adequately designing or testing their software. The end result is bad code and an unhappy client.
To illustrate this point in all of it’s glory I present this story about the DART spacecraft. A $110 million dollar project to demonstrate autonomous docking with a satellite which fails and instead collides with the thing. You’d think that on a $110 million dollar project, you’d fix ALL known bugs and that you’d test EVERYTHING you could before launch. Let me quote: “That error was worsened by a known computational bug in the navigational software that the DART team had never fixed” and “But the gain was changed to place an inappropriately high level of weight on the GPS measurements late in the spacecraft’s development and was not properly tested“.
Why would the software team not fix the bug and not properly test the gain? Were they incompetent? I doubt it. Most likely they had a strict launch window that they could not miss. So instead they rushed to get the job done. The result? Bad code and $110 million dollars down the tube.
As always, your comments welcome.