Using packages, frameworks, and libraries has made it easier to build complex applications and systems faster, but it has made maintaining and debugging them mu

Using packages, frameworks, and libraries has made it easier to build complex applications and systems faster, but it has made maintaining and debugging them much more difficult. If you are using 10 libraries, each with 100,000 to 1,000,000 lines of code, interacting with an operating system and drivers that are another million lines of code, you can't possibly understand what it is all doing, even if you have all the source code. You don't have time to even read it all. Trying to debug something you don't understand turns into trail and error to find clues as to what is going wrong. Sometimes you never figure it out. Hopefully you find a workaround. My first experience of this was in writing a 3D visualization for evaluating an electronic warfare system which used a 3D library from a third party. My aircraft would always disappear after a few minutes. The people who wrote the 3D library couldn't help me. I couldn't figure it out since I didn't know what the 3D package was doing internally. However I found that popping up a helicopter at 2000 feet for a half second fixed the problem. So from that point on all demos would be disrupted once in a while due to a helicopter popping onto and off the screen. I eventually found a way to make the helicopter invisible. It was still being popped up, but nobody could see it. I suspect there is tons of software today that works because of hacks like this, which makes them very fragile and prone to break if you make changes, and makes them almost impossible to troubleshoot (in addition to the underlying complexity).