Showing posts with label Information Gathering. Show all posts
Showing posts with label Information Gathering. Show all posts

One thing at a time

Be scientific, not idiotic.

You need to be able to measure your tests, even if the measure is as corse as "it worked" versus "it didn't". To be able to do this, you need to know what changed and what you expect, so you need to change a controlled number of things and you need to expect something.

Make it Fail

This is a technique with two major uses.

Prove the problem and prove you're making a difference.

In reverse order...

Logs

Logs are fucking great.

They are like seeing what's going on in peoples' minds, what they're up to and how all the shit you built it behaving.

But most people don't look at them.

Oh, but some logs are shit. They really are terrible, and cannot be used.

So there are 2 skills you need: excellent log-reading skills, and excellent log-writing skills. We'll cover the reading skills first, because you'll sympathise with the readers of bad logs and better understand how to read good ones.

History

How did we get into this mess?

The history of the system will tell you a lot about the state of it.

There are two types of state change:

  • the data within the system
  • the behaviour of the system

As these 2 interact, they produce a hellish combination of results. Data changes over time and if the behaviour of the system fiddles with that data, you end with a confusing array of behaviour and data.

Error Messages

And what exactly do we learn from this?
A generation has grow up with either the blue screen of death or the whirly beach ball of death. A minority with unix error messages.

Exogenous vs Endogenous

There are two places that information can come from: inside the system and outside of it. These are called Endogenous and Exogenous respectively and should be treated differently.

Code Coverage

I have heard hours of conversations about how some class AllBad.java is the problem, how it needs to be replaced and is badly written just to hear a little later that AllBad.java isn't all bad and wasn't even being called.

You have to know what code - what part of the system - is really being called. Which classes are involved and which methods inside them. At a bigger scale, which web service is involved or is the server that has the problem getting any of the hits?

Breakpoint

Breakpoint debugging is available in some of the more feature-rich IDEs such as those from Borland, Zend and the like. While this is a tool, it's also a technique.

A good breakpoint debugging technique draws on excellent logic tools for dividing the problem space and getting the most information out of a give question using trial and error.