|
|
|
|
|
|
by TheAceOfHearts
3347 days ago
|
|
|
I haven't watched the video yet, so please forgive the possibly premature comment... But this is something that I've found myself thinking about a lot lately. Are the things that we're currently building or maintaining truly that complicated or are we over-engineering things? I've been humbled on more than one occasion where I initially thought an enterprise-y solution was over-engineered, until all the details of the problem were explained to me. What I wish we had was a "man" equivalent to provide every-day examples of how to use the tool "correctly" (although I'm aware there's stuff like "bro" pages), as well as another tool to explain why some tool / option even exists and how they're "expected" (by the creator / maintainers) to be used. As I've gotten into the habit of reading man pages I've become increasingly aware of how many options certain tools provide, but in many cases I really cannot fathom why those options are available or in what kind of situation they might be used. |
|
|
Consider SAP. It's complicated to say the least, but a lot of that complexity comes from both it's generality, it's flexibility, and the quality of the solutions it solves underneath.
Any solution you write in SAP could be written in a much simpler manner using simpler tools, but doing so would and getting your solution to the quality of what you can get in SAP would be hugely expensive and take a lot of time.
In that way we subsidize each other, but in doing so, we often make things much more complicated than they strictly need to be to solve any particular problem.
Now this is a different class from things that are just shitty design. Those exist in abundance, and it's unfortunate, but that's life.