What's your Modus Operandi for solving a (programming) problem?

Question

While solving any programming problem, what is your modus operandi? How do you fix a problem?
Do you write everything you can about the observable behaviors of the bug or problem?

Take me through the mental checklist of actions you take.

Answer 1

Logic.

Break the problem down, use your own brain and knowledge of each component of the system to determine exactly what is happening and why; then on the basis of this you will discover where the problem isn't, and hence determine where it must be.

Answer 2

Step away from the computer and grab some paper and a pen or pencil if you prefer.

If I'm around the computer then I try to program a solution right then and there and it normally doesn't work right or it's just crap. Pen and paper force me to think a little more.

Answer 3

Every problem I've ever had to solve on a computer has had something to do with solving a task in the real world. Therefore, I've learned to look at how I would accomplish something in the real world and map that to the computer problem.

---

Example:

I need to keep track of my student's grades and come up with a final grade that is an average of all the grades throughout the year?

Well, I'd save the grades in a log (database) and I'd have a page for every student (Field StudentID) and so on...

Answer 4

First, I go to one bicycle shop; or another.

Once I figure nobody invented that particular bicycle,

• Figure out appropriate data structures for the domain and the problem, and then map needed algorithms for dealing with those data structures in ways you need.

• Divide and conquer. Solve subsets of the problem

Answer 5

Pencil, paper and a whiteboard. If you need more organization, use a tool like MindManager.

Answer 6

Andy Hunt's Pragmatic Thinking and Learning has a lot to say on this question.

Answer 7

Related question that may be useful:

Helpful points of view, concepts or ways to think about problems every newbie should know

Answer 8

This algorithm has never failed me:

1. Take Action. Often just sitting there and being terrified or miffed by the problem will not help solve it. Also, often, no amounting of thinking will solve the problem. So you have to get your hands dirty and grapple with the problem head on.

2. Test. Under exactly what conditions, input values or states, does the problem occur? Make a mental model of why these particular conditions might cause the problem. Check similar conditions that don't cause the problem. Test enough so that you have a clear understanding of the problem.

3. Visualise. Put debug code in, dump variable contents, single step code whatever. Do anything that clarifies exactly what is going on where - within the problem conditions.

4. Simplify. Remove or comment code, poke values into variables, run particular functions with certain values. Try your hardest to get to the nub of the problem by cutting away the chaff or stuff that doesn't have a relevance to the problem at hand. Copy code into a separate project and run it, if you have to, to remove dependencies.

5. Accept. A great man said: "whatever remains, however improbable, must be the truth". In other words, after simplifying as much as you can, whatever is left must be the problem, no matter how bizarre it may seem at first.

6. Logic. Double, triple check the logic of the problem. Does it make sense? What would have to be true for it to make sense? Is there something you're missing? Is your understanding of the algorithm wrong? If all else fails, re-engineer the problem away.

As an adjunct to step 3, as a last resort, I often employ the binary search method of finding wayward code. Simply comment half the code and see if the problem disappears. If it does then it must be in that half (and vice versa). Half the remaining code and continue.

Answer 9

Question: How do you eat an elephant?

Answer: One bite at a time.

Answer 10

One technique I like using for really big projects is to get into a room with a whiteboard and a pile of square Post-it Notes.

Write your tasks on the Post-it Notes then start sticking them on the whiteboard.

As you go, you can replace tasks that are too big with multiple notes.

You can shift notes around to change the order that the tasks happen in.

Use different colours to indicate different information; I sometimes use a different colour to indicate stuff that we need to do more research on.

This is a great technique for working with a team. Everybody can see the big picture and can contribute in a highly interactive way.

Answer 11

I always take a problem to a blog first. Stackoverflow would be a good place to start. Why waste your time re-inventing the wheel when someone else may have already solved a similar problem in the past? If anything you will get some good ideas to solve it yourself.

Answer 12

• Google is great for searching for error messages and common problems. Somewhere, someone has usually encountered your problem before and found a solution.

• Pencil and paper. Pseudo Code and workflow diagrams.

• Talk to other developers about it. It really helps when you have to force yourself to simplify the problem for someone else to understand. They may also have another angle. Sometimes it's hard to see the forest through the trees.

• Go for a walk. Take your head out of the problem. Take a step back and try to see the bigger picture of what you want to achieve. Make sure the problem you are 'trying' to solve is the one your 'need' to solve.

• A big whiteboard is great to work on. Use it to write out workflows and relationships. Talk through what is happening with another team member

• Move on. Do something else. Let your subconscious work on the problem. Allow the solution to come to you.

Answer 13

I stop working on it until tomorrow. I usually solve my problem in the shower the next day. I find stepping away from the issue, and allowing my brain to clear, allows a fresh perspective on the issue.

Answer 14

I use the scientific method:

1. Based on the available information about the programming problem I come up with a hypothesis about what the reason could be.

2. Then I design / think up an experiment that will reject or confirm the hypothesis. This could be observing something in a debugger or screen/file output. Or changing the program slightly.

3. If the hypothesis is rejected then repeat 1. The information gathered in 2. may help in coming up with a new hypothesis.

4. If the hypothesis is confirmed then the hypothesis may be refined/become more specific (repeat 1.). Or it may already be clear what the problem is.

This directed way of find the problem is much more effective than changing things at random, observe what happens and try to (inappropriately) use statistics.

Answer 15

I'm interpreting this as fixing a bug, not a design problem.

Isolate the problem. Does it always occur? Does it occur only the first time run on a set of new data? Does it occur with specific values, but not with others?

Is the system generating any error message that appear related to the problem? Verify that the error messages are not generated when the problem does not occur.

Has anything been changed recently? Those are likely places to start looking.

Identify the gap between what I know is working (e.g. I can start up the app and attempt to do a query) and what I know is not working (e.g. it gives me an error instead of the expected results). Find an intermediate point in the code where it seems possible to look for a problem (does this contain valid data at this point?). This allows me to isolate the problem on one side or the other of the point I looked.

Read the stack traces. If you have a stack trace, find the first line that mentions in-house code. The problem is not in your libraries. Maybe it will turn out to be, but just forget about that possibly first. The error is in your code. It's not a bug in java, it's not a bug in apache commons HTTP client, it's in code written in your organization.

Think. Come up with something the system could be doing that can cause the symptoms you see. Find a way to validate whether that is what the system is doing.

No possibility the bug is in your code? Google for anything you can think of related. Maybe it is a bug in the library, or poor documentation leading you to use it wrong.

Answer 16

My method, something analytic-sinthetic:

1. Calm down. Take a deep breath. Focus your attention in what you're going to solve. This may include going for a walk, cleaning the whiteboard, getting scratch paper and pencils ordered, some snacks, etc. Avoid stress.

2. High level understanding of the problem. In case it is a bug, when does it happened? in what circumstances? If it is a new task, try to diverge of what results are needed. Recollect data, evidence, get acceptance descriptions, maybe documentation or a talk with someone that knows about the issue.

3. Setup the test playground. Try to feel happy with the tools needed. Use the data collected in the previous step to automate something, hopefully the bug if that's the case, some failing tests otherwise.

4. Start sinthesizing, summarizing what you know, reflecting that on code. Executing once and once more. If you are not happy with the results, return to step two with renewed ideas, diverge more: maybe apply tools (in order of cost) that helped before, i.e. divide and conquer, debug, multithread, dissassemble, profile, static analysis tools, metrics, etc. Get in this loop until you can isolate the problem and pass the over the phone test.

5. Now it's time to fix it but you have all the tools set up. It won't be so much trouble. Start writing code, apply refactoring, enjoy describing your solution in the docs.

6. Get someone to try your solution. She can eventually get you to step 2 but that's ok. Refine your solution and redeploy.

Answer 17

Answer these three questions in this order:

Q1:  What is the desired output?
I don't care if this is a napkin with scribble on it. I want something tangible that shows me what the end result is supposed to look like. If I don't get at least this far then I stop.

Q2:  What is the input?
I find out what data I have coming in. Where this data is coming from from. What formulas I may need. What dependencies there might be on A happening before B. What permissions if any are necessary to get this data. I then ask Question 3.

Q3:  Is there enough input to create the output?
If the answer is No then I go back to Q2 and get more input from whoever can give it to me.

For very large problems I break them down in Phases and apply Q1 Q2 and Q3 to each phase.

Answer 18

1. I think about it. I take anywhere from a couple minutes to a few weeks to mull over the problem and develop a general plan of attack.
2. Hammer out an initial solution. This solution is probably half-baked and one or more aspects may not work.
3. Refine that solution. Keep working on the problem till i have something that solves the problem.
4. (and this may be done at any step in the process) Ask questions on stack overflow to clear up any difficulties i'm having at the moment.

Answer 19

1. write down the problem
2. think very hard
3. write down the answer

Answer 20

One of my ex-colleagues had a unique Modus Operandi. Whenever faced with a hard programming problem (e.g. Knapsack problem or some kind of non-standard optimization problem) he would get stoned on weed, claiming his ability to visualize complex state (such as that of recursive function doing operations on set passed on the stack) was greatly improved. The only difficulty, the next day he could not understand his own code. So eventually I showed him TDD and he has quit smoking...

Answer 21

The following applies to a bug rather than building a project from scratch (but even then it could do both if reworded a bit):

1. Context: What is the problem at hand? What is it preventing, doing wrong, or not doing?

2. Control: What variables (in the wide sense of the word) are involved? Can the problem be reproduced?

3. Hypothesise: With enough data on what is occurring or required, it is possible to hypothesise, that is, to draw a mental image of the problem in question.

4. Evaluate: How much effort, cost, etc, will the correction require? Determine if it's a show stopper or a minor irritant. At this point, it may be too early to tell, but even that is a form of evaluation. This will allow prioritisation.

5. Plan: How will the problem be approached? Does it require specifications? If so, do them first.

6. Execute: A.K.A. The fun part.

7. Test: A.K.A. The not-so-fun-part.

Repeat to satisfaction. Finally:

Feedback: how did it come to be this way? What lead us here? Could this have been prevented, and if so, how?

EDIT:

Really summarised, use the H.T.F.O. solution: Hold The F**k On. As in, stop, analyse, act.

Answer 22

No one has mentioned truth tables! But that's probably because they're usually only mildly helpful ;) (although your mileage may vary) I used one for the first time yesterday in my 8 years of programming.

Diagramming on whiteboards or paper have always been very helpful for me.