5 ms·

It daunts me how much software is getting unreliable, but trying to shame people to hold them accountable is naive. The root of the problem is the uncontrolled

• jacquesm 8y ago
  We have the cycles to burn, which causes waste to approximately eat up all excess cycles. This has been observed since the 80's, so there is not much new here. Computer programs tend to fill up all available memory, use all available cycles and eat up all available storage no matter how far Moore's law has helped us come.
• adamcharnock 8y ago
  It daunts me too, and reminds me of the early-days of commercial flight. I hope we'll have a similar "we cannot continue like this moment". However, I don't think shaming is what this is about though. To me it seems the objective is to learn from mistakes, and for that we need to be honest about what happened, and it is going to be pretty hard to be honest if we tip-toe around who did what and why. I also agree that complexity is a problem. But I don't think acknowledging this gives us any path forwards. I don't think going back to the 'good old days' is going to be a solution. I therefore see this leaning process as helping us figure out how to move forwards, and to provide a motivation to the industry as a whole. It is this industry-wide motivation that will be needed to address some of the systematic complexity issues. I don't think this would be enough on its own (and implementation is a whole other question), but I think it could be a step in the right direction.
  • benashford 8y ago
    > It daunts me too, and reminds me of the early-days of commercial flight. I hope we'll have a similar "we cannot continue like this moment". The first citation of the words "Software Crisis" meaning the inherent difficulty of writing high-quality software in a predictable way was from a NATO conference fifty years ago: https://en.wikipedia.org/wiki/Software_crisis https://en.wikipedia.org/wiki/Software_crisis It is taking a long time for good practices to be discovered and win-out, and even when obvious improvements have been made, they're not necessarily used effectively. I suspect a large part of the reason why the software industry isn't maturing at the same speed that other industries have had to, is that in software, failure is much easier to hide.
• zby 8y ago
  OK - I think we can all agree that it is hard - but still we need to do something about it. The question is who is in the best position to improve it. Customers will not put any meaningful pressure because they are too ignorant about what is responsible - it is only the programmers who have any knowledge about the source of the problems and they need to be incentivized.
• closeparen 8y ago
  What makes you think dependencies are relevant to a discussion of IT project failures? Many organizations can't even manage to write the first-party code to any approximation of the requirements without going years and hundreds of millions over-budget. Getting tripped up by subtle bugs in dependencies would be a fantastic state of affairs compared to today.
• magicalhippo 8y ago
  > The root of the problem is the uncontrolled complexity of modern software products. > Because of this complexity responsibilities are diluted, most of your code is in your dependencies nowadays. That doesn't resonate much with me. Yes maybe in terms of LOC most of our code is in dependencies. But most of our _important_ code is our own, in the business logic. The reason our product is unreliable is mostly down to complexity as you note, but that complexity is driven by our users who want better integration and automation. Add one more optional behavior ("when X I need to do this tedious task Y, could your program do this for me?") and you've increased the testing surface exponentially. On the other hand those additions is what sets us apart from our competition, and what makes the eyes pop when we show off our product to potential new clients. So it's a balancing act. The complexity makes our users extremely productive[1], but it also makes our software more fragile[2]. [1]: For example, one client went from almost an entire day of manual data entry for certain orders to less than half an hour due to a "smart" Excel importer I wrote. [2]: Users now want the Excel importer to behave in conflicting ways, and trying to cater to that without breaking one of the use-cases is very difficult.
• benashford 8y ago
  > It daunts me how much software is getting unreliable, but trying to shame people to hold them accountable is naive. > The root of the problem is the uncontrolled complexity of modern software products. I think there's a feedback loop between those two things, especially when it comes to government or giant corporation projects. Lack of accountability causes accidental complexity, which in turn causes a lack of accountability. It starts with a organisation that lacks tech leadership hiring a consultancy, which then treats the project as a "flagship engagement" which means trying to make everything perfect, where perfect is used in the context of the number of future sales-pitches that will cite this one project. As a result, there's a gap between what the organisation needs and what it gets, which adds to the amount of work required and complexity to navigate, whenever changes are required, and the overall complexity snowballs from there. Most of the above is business-as-usual for most very expensive projects. The real danger-zone is when you get to the third iteration, six or seven years down the line, and you're forced to re-hire the first consultancy again because they're the only one with the resources to take it on; but the tech-world has moved on, so they see you as a "modernisation engagement". They simultaneously can't criticise their own bad decisions from several years prior, but at the same time they want the wider-industry to see their "transformative" power, so can't merely iterate on what's already there either. That's how you end up with iOS apps, talking to Ruby-on-Rails APIs (which used to be the primary web-app, before that was replaced with a React frontend), reading and writing from an Oracle database which is also updated with a series of batch jobs dating back to early 2000s Java EE. The "coal face" developers in all these situations have done the best work to their ability, and quite often achieved minor miracles in stability given the underlying complexity. The problem is always a management (or lack-of management) problem.
• speedplane 8y ago
  >It daunts me how much software is getting unreliable, but trying to shame people to hold them accountable is naive. Has it been getting more unreliable? Software is being developed, bugs are getting fixed, new use-cases are emerging faster than anytime before. If it seems like software is getting more reliable, maybe its just that we're relying on it more and more.
  • lmm 8y ago
    I do think software has got less reliable in the sense that unclear random errors, freezes, and data loss are more common. I think this is mostly the result of a (correct) choice to add more value overall by prioritising features over reliability.
    • tonyedgecombe 8y ago
      I'm not sure that is the case, twenty five years ago I'd be lucky if my desktop went a whole day without crashing and needing a reboot, that is quite rare now.
      • TheOtherHobbes 8y ago
        Twenty years ago a banking IT failure would have been considered catastrophic and unacceptable. Now there are serious meltdowns and failures every year. Meanwhile, when was the last time you talked to a customer services rep of any large org without being told "Sorry - our systems are really slow today"?
        • speedplane 8y ago
          "really slow" isnt catastrophic.
        • curuinor 8y ago
          This is really a sign that big non-tech-centered orgs cannot get the best talent nowadays. Lots of banks pay under 2/3 of the real asking price for a great programmer.