If only it were as easy as rocket science!
Writing fast reliable multithreaded software is a harder problem than rocket science.
A famous example of this was Therac-25, an X-Ray machine that occasionally killed people due to multithreading issues.
It’s even harder now that we usually have multiple processors/cores running the same program.
I recently heard of an online sales company shipping duplicate orders to people, including $1000 camera lenses, because multiple fulfillment centers in their worldwide deployment somehow picked up the same tickets.
Reactivating the Hubble Space Telescope is complicated by the possibility the software isn’t working right.
Deadlocks and other resource contention issues are especially problematic in database-intensive programs. This is like making everyone wait in line for the bathroom, except the first person has to wash his hands afterwards and the second person is blocking the sink while waiting for the first person to finish in the stall. After some amount of time waiting for each other, both parties give up and “roll back” the transaction to the previous state. Which means they both have to pee again, or return to the dinner table with an error message.
Now add thousands of users per second using multiple types of bathrooms for hundreds of different procedures (putting on makeup, replacing the toilet paper, vomiting….) and add unreliable plumbing plus the possibility the water pressure will change when someone else flushes the toilet.
And don’t even get me started about HAL 9000 and Jurassic Park!
Is Test-Driven Development enough to detect a practically infinite combination of conditions?
I don’t think so. System testing with load/performance testing *past the failure point*, as Boeing does with new airplane designs, gives us some clue how much headroom we might have. Pair programming with experienced developers improves our odds also. I remember a great discussion with Alan Holub about design approaches to minimize multithreading risk. In aerospace we got nearly perfect determinism by limiting flexibility (programming in Ada 83, disallowing dynamic memory allocation). But the 100% deterministic nontrivial program that also run as fast as everyone wants it to is still a Hard Problem.
Download the PDF version: Programming Is Not Rocket Science blog