Have you ever played Battleship? It's a game where 2 players put their ships on a grid and start guessing coordinates. If you guess a coordinate where your opponent's ship is located, that counts as a hit. Each ship takes up 3, 4, or 5 coordinates and once you've guessed all the coordinates of a ship, it's sunk. The commercial when I was kid had the kid on the losing side exclaim, "You sunk my battleship!". Good times, good times.
This is part 2 in a series. If you have no idea why I'm talking about board games from the 1980's, start with Part 1.
Battleship taught me most of what I need for troubleshooting. I have a bounded set of possibilities, I only get a certain number of attempts, and there's an uncomfortable period during each attempt when something bad may happen to me. When playing Battleship, you can simply guess at random, or you can employ a directed strategy. The same is true in troubleshooting. If you're all over the place, sometimes you'll get lucky and sometimes you'll miss for what seems to be an eternity.
As you're implementing your search strategy, it possible to become too focused. In the game, for example, it makes little sense to test a coordinate immediately adjacent to your previous guess since the ships are at least 3 units long. Better to space out the testing and then "walk it in" by focusing in the surrounding area once you get a hit. The same is true in troubleshooting. If each test run is simply a close variation on the previous hypothesis, you're in for a long night. If, however, you take a wider approach and test based on variations that are reasonably separated, you have a much better chance of getting a hit, and then you can hyper-focus on the surrounding areas.
I seem to recall that Battleship was never as much fun as I thought it should be. When you think about it, there isn't all that much excitement and it doesn't have much to do with the Navy. Troubleshooting: same story. It's one of those things that you do that has its ups and downs, but overall you kind of wish you had done something else instead.
The point here is that when you're confronted by a troubleshooting problem, don't just fire at random and hope that you get a hit. Approach it with a plan, execute, and as you get some success then focus on that area for all it's worth.
In the Spring of 2008, I decided to become a brownfield development specialist. Greenfield development is when you're starting a project from scratch and get to design everything with only minimal constraints. Brownfield development is the opposite of that: it's when a project is n months into development and most of the constraints have been cast in stone. My guess is that if you were to ask every developer you know whether they'd prefer to work on a greenfield project or a brownfield project that they'd all say greenfield. Heck, I'd bet that a quarter of them would laugh so hard that Red Bull shot out of their nose just at being asked the question. Therein lies one of the secrets of becoming a Big Swinging Developer:
You can make money being good at things that other people hate to do. A lot of money.
When people hate to do something, they don't do it very much. Since they don't do much of it, they never get particularly good at it. This makes it harder for them to do it and the cycle starts all over again. Some common values of "it" for development include: writing tests, documentation, and creating installers. You can safely add brownfield development to the list since a job description of "Support the big ball of mess that runs our business while adding features and fixing bugs" doesn't usually have folks banging down your door. Throw in the fact that you'll have no relevant documentation and few, if any, tests to guide your way and you can picture weeks of pestering your co-workers with questions just to get to the point where you can fix a simple defect.
But what if brownfield was easy for you? What if, rather than pestering your co-workers with basic questions, you could understand what the code was doing and then ask why it was doing things that way rather than asking what it actually does? That's what my secret weapon, Visustin, gives you. You paste in your source code and it'll generate a flowchart for you:
It supports 31 languages including the popular .NET, open source, and SQL variants. I spent last week throwing hundreds of lines of Python into the tool and tracing through an incredibly complex financial trading system to learn how portfolio valuation is calculated. I was able to correctly describe the process to my team lead, including a couple gotchas buried in the code even though I don't know Python. Since I know how the system works, though, I can find the path the code will take and identify where problems are likely to occur while coming up to speed on the language at night.
If you're a developer, I'd highly recommend Visustin. It's great for code reviews, documentation, and for diving into existing systems. Developer or not, look around your industry and find the important things that no one wants to do because there's a real opportunity there. You can become better (or more tolerant) than anyone else simply by identifying the key aspects to the unpleasantness and solving that problem first.
Do you know how to solve a Rubik’s Cube? If not, click the link in the previous sentence and take a quick look.
Ready?
Okay, now look at the picture of the cube on the right. Does it look as messed up as the project you’re working on? And yet both are solvable, and in remarkably similar ways.
Get To A Known Good State The first step is to go from utter chaos to something that looks more familiar. For the cube, some use a 2x2x2 corner, others use a cross. On projects, some developers fill in unit test gaps, others automate the build process.
Have A Logical Progression of States After you get to a known good state, there will be a next step. And a next. And probably several other states before reaching completion. The way in which the cube is scrambled has no effect on the order in which it will be solved, it simply affects the work that must be done to get to each state. Likewise, every project is troubled in it’s own special way — although there are certainly recurring anti-patterns — but you’ll still help move it through the same states.
Know The End State It’s easy to know when you’re done solving the Rubik’s Cube and that’s one of the reasons that solving it using different techniques from different starting points is still a repeatable process. Conversely, many projects fail because the people working on them don’t have a clear definition of what it means to be done.
So take a moment to step back from what appears to be a jumbled mess and decide what state it needs to be in next — regardless of what it takes to get there. Then the next state and the next, all the way up to a clear end state. Once you know how things should look along the way, it’s a lot more clear what you need to do to get there.
