The source of most bugs is pressure. Time and money. Which results in management making bad choices.
In early stages of software development, the specs and design documens are almost always too abstract and insufficiently detailed, but development is started anyway, due to time/money constraints. This is not nessecarily a bad thing, if you follow some iterative or agile product development process, but it means some big refactoring and probably a redesign will be needed on the way. Especially when users have played around with early releases, and lots of change requests and missing features come in. Those are usually very specific, not application wide, so that changes are made haphazzerdly, all over the code. The result is that user experience becomes inconsistent, and the code gets bloated with lots of exceptions all over the place. It becomes almost impossible for the programmer to foresee all the consequences of any code changes he makes. Despite static code analysis, unit testing, funcional testing, automated testing, etc., with each new feature or bug fix, some other part of the application falls over. A good programmer will say: well this is going to take some refactoring and the analysist/users/architects should make some decisions about general design rules and specs, so we have to do this only once. But there is never time for refactoring, and the specs and designs never get updated. There is only time for new features, hacked in as quickly as possible. At the end of the development cycle, there is only time for bug fixes, but with every fix, two new bugs are introduced.
And so managment asks: can you explain where all those bugs come from? But they never like the answer.
This, by the way, makes my blood boil and sometimes steam comes out of my ears. So those EDA and EEG sensors will probably be all the way in the red, and management will think that i've ran into a complicated problem. Which is true, but the problem is not the software, it's managerment.