Breaking point in System Architecture. The point where you define it is ok for the system to break if you user doesn't meets the expected threshold of intellect.

In plain words, you say "F**K it, if someone is that stupid, let the system go down"

They don't teach this in college.

  • 2
    Hey, sounds like excuses my guy
  • 5
    There’s a bar, every day that bar gets lower and lower for that threshold point, and here we are making the systems so damn idiot proof we may as well automate every process and put them out of a job.
  • 1
    @ihatecomputers Depends on where we set the bar for over-engineering. But, point taken 👍🏻
  • 0
    Why would the system go down because of user interactions? Because it's Windows 3.1 style crap or what?
  • 1
    @Fast-Nop There is an interesting story about this guy whose last name is Null. Solely responsible for bringing down web services and stuffs.

    The edge cases at my context were worse. You just simply can’t have every possible use cases covered. Depending on your customer size and the time to implement, you decide the bar.

    PS : the system is more stable than windows 😂
  • 0
    @DEADC0DE when a guy named null brings down anything, the application is shit and riddled with security bugs anyway because the escaping is not in place.

    This has nothing to do with raising a bar, but with meeting a basic coding level.
  • 0
    @DEADC0DE I'm the best (worst) at over-engineering 😅 It's like everything I code is going to Mars :/
  • 0
    @Fast-Nop This is not at code level. When you do a DFD or Sequence of events, there would come situations where you look at the impact vs effort.

    I don't compromise at code level :)
  • 0
    @ihatecomputers Been there, done that, paid the price!
Add Comment