Being Slow to Criticise

from Hacker News https://ift.tt/3dxRu5G

Monitoring software that deliberately killed the servers was an interesting idea. The programmer/engineer involved wasn't able to fix the underlying problem, so an overlay solution was devised that (a) worked, and (b) was feasible. The story I read had the details, and it was an intriguing read. The story was submitted to a forum I occasionally read, where one of the comments was: "You should just fix the real problem: the software is garbage." I've met this before, both a situation where there is software we can see is not up to current standards, and the attitude of those who look at it with the benefit not only of hindsight, but of 20 years of advances in software, toolkits, libraries, and hardware. Related: "Don't ever take a fence down until you know the reason why it was put up," -- John F Kennedy, paraphrasing G.K.Chesterton. But I try to be slow to jump to that conclusion, that the software is garbage. So often there are reasons for things to be the way they are. The software tools and the hardware capabilities were very, very different in the aughties, and many people currently writing software don't really seem to appreciate by just how much. Additionally, there might be time pressures, political pressures, engineering constraints, access problems, and more. It may be the case that things could have been done differently, perhaps better, but then again, once you know the full story and the full context, maybe not. Some time ago I wrote up a war story from the mid-nineties and had some current software people crap all over it. When I started to explain about the machine limitations of the time, the bluster increased, and among the replies I got was "The software was crap". Ever since then I've been interested in the contexts for these stories. So often I hear "Well you shouldn't have done it like that!" rather than an enquiring: "OK, let's assume some clever people wrote this. I wonder what the pressures were that made them come out with that solution." I've learned a lot by approaching things that way, instead of assuming the people involved were ignorant, unskilled, idiots, or otherwise incompetent, and simply declaring: The software was garbage. You might be right, but equally, it may be that you haven't put in enough time to understand the realities. Send us a comment ...