The only real problem with the computer was that it unnecessarily distracted the crew (and ground) at a very critical time with a comparatively minor problem -- arguably a non-problem, even. The crew was so distracted that they did not notice that the autopilot was taking them into the boulder field north of West Crater, necessitating a rather aggressive manual fly-over by Armstrong at the last minute. Had he not been distracted by the alarms, he could have redesignated his landing point earlier in the approach phase and had a much less heart-stopping landing.
As already stated, the alarms resulted when the computer ran out of real time in executing all the tasks assigned to it. The root cause was misdesigned peripheral hardware on the rendezvous radar antenna that generated high rate spurious interrupts that "stole" so many cycles from the CPU that not enough were left to perform every scheduled task. Any spurious interrupt stream would have had the same effect.
Although this was not expected, the MIT designers anticipated and designed for it. They prioritized their software; the most important tasks are run first, and then the less important tasks until nothing is left to do or the computer runs out of time.
For example, the computer periodically reads the accelerometers and IMU gimbal angles and integrates their data into the spacecraft state vector, its estimate of current position and velocity. Missing an update introduces an error. During descent, the computer kept track of the spacecraft's decreasing mass and adjusted the throttle accordingly. With the IMU data it adjusted the engine gimbal and fired the RCS engines to maintain the proper attitude And had it not responded quickly and properly to Armstrong's hand controller, he would have ordered a manual abort.
But some activities were not nearly as critical. For example, the first alarm occurred when Aldrin entered VERB 16 NOUN 68 to display the difference between the landing radar altitude and that from the computer's estimated state vector. The extra load of this calculation was the "straw that broke the camel's back", as Aldrin immediately and correctly suspected. But the only effect of the 16-68 command was to show some numbers on the DSKY. Skipping the calculation merely updated the display less frequently. Not ideal, but certainly far less serious than skipping the more critical functions already listed. So when the computer ran out of time, it automatically "triaged" the workload and kept the critical functions going -- just as MIT had designed it.
In so doing, it turned on the PROGRAM ALARM light and Aldrin had to key in a sequence to determine its type. It meant nothing to the crew so they had to wait for the ground to tell them that it could be ignored. It distracted both of them unnecessarily at a critical time.
In retrospect, a better design would have implemented one or more "computer overload" lights that flash momentarily whenever the system runs out of real time and is forced to skip less important tasks. Yellow indicates a slight overload dropping only minor tasks; red indicates a more severe problem. The lights would be on only while the problem persists, making it easy to see the effect of changing the computer's workload.
An even more general purpose fix would be an analog meter showing CPU utilization with yellow and red zones. Such meters were actually standard equipment on many of the IBM mainframes of the day, and operators used them to adjust their job mix to more fully utilize the CPU, or just to entertain themselves during a boring shift.
