Debugging: Not Testing but Drowning 3

Debugging is where you have a system which is, at last, responding to you. However, it is responding with unexpected errors, or intermittently failing to respond, or merrily telling you that everything is fine while you can see that, in fact, everything is on fire. When debugging, you may be running plenty of data (if you have it) to see what’s weird; digging into system diagrams to work out what could be to blame; opening filesystems and running diagnostics to see not only what’s going on at a more granular level but also whether those system diagrams and docs are currently accurate; looking in libraries and supporting systems and manual for error messages; working with configurators and coders on fixes, waiting for and wrangling those fixes into place, seeing whether the fix has made the problem go away (?made others turn up?); persuading and advocating, listening and learning to gain leverage on getting fixed; talking to people who might use the system about what your prioblem might mean, and whether it’s a real problem.

Where you might turn to a system integrator or a DBA in wrangling, for debugging you’re turning more often to a coder or designer or business user.

You’re certainly designing tests and exploring a system when debugging. However, those tests and that exploration are to address a current risk, rather than to add much of long-term use. You’re holding not two but three models; what you imagine the system should be doing / what the builders found it would do / what it’s actually doing (this is the part which is factual, but unknown).