Hacker News new | ask | show | jobs
by mannykannot 2256 days ago
Big balls of mud result from a process that resembles reinforcement learning, in that modifications are made with a goal in mind and with testing to weed out changes that are not satisfactory, but without any correct, detailed theory about how the changes will achieve the goal without breaking anything.
2 comments

Sounds like all of Agile, really. One can characterize Agile as a ball-of-mud maintenance process that scales desirably with the amount of mud.
So, lack of a larger test suite that can detect ripple effects across the overall system, and not just a component?

Or are test suites just a nice fantasy for a real distributed system?

In the situation I am thinking of, the tests that select successful modifications are, almost by definition, integration tests, because with a big ball of mud, you don't know what the proper specification for the components are, and they don't have clear interfaces.

By 'tests' I am including live failures, which are also a feature of mudballs.

A distributed system is always much more difficult to test than a functionally-equivalent localized version. That's not, of course, a reason to give up on testing, but one must be realistic about how much faith one can put in it to make up for an inadequate use of abstraction and separation of concerns.