Software amplifies everything about a business, both the good and the bad. The downside is that because so much is networked today, something "going wrong" can

Software amplifies everything about a business, both the good and the bad. The downside is that because so much is networked today, something "going wrong" can have much larger consequences (and faster) than a wrong decision carried out on paper 30 years ago. I think that's the distinction James Kwak is trying to make. He isn't saying that the business processes (in this case, buying and selling stocks) was especially clean before software. He is saying that software makes the system faster (amplifying the effects of a poor business process, as you say) while removing a human buffer. When a human order-taker sees an unexpected zero on an order sheet he or she has enough common sense to ask the person handing it to him or her whether the figure is correct. Most financial software doesn't have that "common sense", so it's easy for inadvertent slip-ups or programming errors to cascade into firm-ending chain reactions. Obviously, the solution to this isn't to go back to slow and inefficient human processes. I think the solution is to continue doing what we're starting to see today - software that asks whether we're sure we know what we're doing when it sees a variable that's out of line. In addition, I think that many software systems are way too monolithic. That is, every component of the system implicitly trusts every other component. I would like to see software broken up into smaller communicating components, where each component can make assertions about the input and output of other components, and components can fail without bringing down the whole system. The system I've seen come closest to this is Erlang's OTP, but there's no particular reason for that model to be limited to Erlang.