Things That Scare the Bejeezus Out of Programmers 641
itwbennett writes "Software developers are, by and large, a cool and analytical bunch, but there are a handful of things that strike terror in their hearts. Phil Johnson scoured developer forums looking for an answer to the question: What's your biggest fear as a programmer? The answers clustered into 5 broad groups ranging from being forced to learn or use a specific technology to working for and with incompetents. What's your biggest fear?"
Re:Absence of a test suite (Score:4, Informative)
Automated tests do two things. They make sure you don't make the same mistake again, and they give you higher confidence levels when you refactor. They definitely improve quality when done right- which means testing what needs to be tested, not relying on your tests as documentation or correctness proofs (I'm looking at you TDD), and not spending time writing tests that aren't really useful or for modules that aren't really easily testable (for example, testing that the UI is right).
Re:Thank god for multi process (Score:2, Informative)
If you use shared memory there is no practical difference between multi-process and multi-thread. You have all the same disadvantages. It's just now you (apparently) have the illusion that you don't. This is not a recipe for success.
Contention on shared resources is contention on shared resources, no matter what OS subsystem you use to create parallelism. But now you're using heavyweight IPC mechanisms to solve contention instead of lightweight intra-process mechanisms. Yay for a kernel transition and possible context switch on every lock call.
If you'd said "assuming you do not use shared memory" - e.g. you communicate over pipes or sockets - then your statement would make more logical sense - isolated agents are a proven and robust technique in parallel programming. Except in that case fork() is exactly the wrong model.