The problem with the garbage in, garbage out expression is the assumption that the logic between the input and the output is any good. The GIGO adage applies to the logic of the code.
It seems to me that people make the assumption that the underlying logic is fine. However, that is a dangerous assumption.
As an end user it is difficult to see if the logic is any good. The end user can make assumptions based on the user interface to see if the logic and code is good. But that is just an assumption.
One sure sign of bad logic in code is that features and functions seem to be in strange location like they were just added on. Older programs often have features buried in funny places.
That is not necessarily a sign of bad design. Maybe the program added new features over time since it was popular and had many users.
Some rules and logic are hard coded, while other code allows you to define the rules. Sometimes these choices give you a lot of flexibility which makes configuration and set up hard. Other times this logic is hard coded. This makes setup easy, but the flexibility is limited.
The key to success in either case is knowing what you need beforehand. Learn the flow chart of data in your organization and map that to the flow in your organization.
