Mathematicians from Mars

Back in 1945, the Hungarian mathematician George Pólya published a book on how to solve mathematical problems. The book became very popular within the next decades and had a great impact on mathematics education. The 4 core principles mentioned there can help you to hone your analytic skills and thus become a better programmer.

Together with many other Hungarian scientists, Pólya emigrated to the US in the early half of the 20th century. Since they all spoke English with a strong accent (made famous by Dracula actor Bela Lugosi), spoke an incomprehensible native language, and came from a small obscure country, they were called "Martians", a name they jocularly adopted. Other famous "Martians" included John von Neumann (his ideas led to the digital computer as we know it) and John G. Kemeny, one of the creators of the BASIC language. Many other of those Martians were also involved in building the atom bomb, which sounds like a cool plot from Mars Attacks!, but for today, let us to stick to problems we cannot solve by listening to Slim Whitman's "Indian Love Call".

Mister Wolf - I solve problems

Pólya's problem solving method consists of 4 principles, which seem to be rather obvious at first glance:

1. Understand the problem
2. Devise a plan
3. Carry out the plan
4. Review/extend

Well, many times when I experienced "problem solving" in companies, the plot was a John-Wayne-stylish "We have a problem. Shoot it and bury the corpse". Sometimes it worked amazingly well. But very often, more problems showed up while you were busy digging and before you knew it you were up burying corpses all night long. That's why there's often a "No deployment on Friday afternoons" sign hanging in IT departments all over the world. Because there are much nicer things to do at your weekends.

In some companies, even mentioning the word "problem" is avoided, because it has a negative connotation. That's a bit suprising, because the origin of the word "problem" is the Greek word "problema", which means "for the solution". Company culture should not be about avoiding problems, but about solving them. But, although Pólya writes about "solving problems", I will refer to problems as "issues" or "tasks", since it's the term used more often in information technology these days.

Understand the problem

The first principle is probably the most underrated of it all, because we tend to go for the easy kill, when we see a problem. But communication is a tricky thing, so make sure you really understand the issue by gathering as much information as possible. In information theory, there are the "5 Ws" to help you: questions aimed to understand the issue at hand:

• Who
• What
• When
• Where
• Why

In agile working environments such as SCRUM, this breaks down into user stories which follow the pattern "As a ROLE I can CAPABILITY, so that RECEIVE BENEFIT".

When talking about an issue, be sure to restate the problem in your own words to the one who brought the topic up, reassuring that you both have a mutual understanding of the situation. Take notes, make a list of necessary steps and possible side-effects. If the matter gets too complex, use pictures and diagrams to visualize it. Tools like MS Visio, LucidChart, Gliffy can help you to visualize and understand existing workflows and environments. But in the end, nothing is as versatile as a good old piece of paper and a pen.

Mathematics is the cheapest science. Unlike physics or chemistry, it does not require any expensive equipment. All one needs for mathematics is a pencil and paper.

Making a plan

Take notes, make a list of necessary steps and possible side-effects.
If you don't know your part around a certain part of the software, ask a colleague who does. Asking isn't equal to showing a lack of knowledge, but to showing interest in your work and improving on what you are doing. Beginners are often amazed to find that big companies often spend as much as 50% of the time implementing a new software on planning.

The more you plan in advance, the less problems you will run into, which means you will save a lot of time and money by avoiding unnecessary bug hunts and by cutting obsolete features. Many start-ups create their software while they go, piling up technical debt which will sooner or later require them to do an expensive and error-prone refactoring of their code. That's when programming gets really annoying, because no-one took the time to write a documentation and many programmers get frustrated with their daily work, since the code doesn't scale, but the demands are piling up. With a decent planning in advance, you can take possible future enhancements of the software into account, plus, by storing the plans in a knowledge repository such as a wiki or an issue tracker, you already have a handy documentation.

If the issue is too big, like "world domination in 5 days", split the issue into several smaller tasks you actually can solve. This even helps you to create a software where specialized modules for certain parts of solutions to minor tasks interact with each other to solve bigger tasks (see single responsibility of a class in software design principles like SOLID). Try to avoid huge, specialized god classes that are good at solving only one problem, but cannot be used to solve other problems or tasks. In addition, small components are great for unit testing, too!

Maybe you or your team members have already written components before you can now re-use for your new task? Try to avoid code duplication wherever possible.

Carry out the plan

This is the easy part, since we already spend a lot of effort understanding the problem and planning. Usually, you will just follow your plan: ticking off checkboxes on your todo list, or working on your Scrum tasks, whatever your workflow is.

Keep giving feedback. Have there been any changes lately? Do we have to adapt the plan? Did any unforeseen problems occur? If it doesn't work at all, discard it and go back to planning. There's no shame in beginning new and learning from errors made.

Review/extend

After your software got deployed, don't just start the next project. Take your time to reflect and look back at what you have done, what worked and what did not, and think about other problems where your solution could be useful. Doing this will enable you to predict what strategy to use to solve similar future tasks. Use your plans from step 2 to create a documentation.

An idea which can be used only once is a trick. If one can use it more than once it becomes a method.

Conclusion

Many problems that arise in the Real World (tm) are so complicated, that they can be overwhelming and frustrating. The "art" of a programmer is to handle that complexity by splitting it up into small chunks and solving them one by one, then assembling the pieces together again, creating the illusion of fluid simplicity. That way, even complicated problems can be tackled, even if there's no solution on StackOverflow yet. Or as Jean Piaget put it: "Intelligence is not what you know, but what you do when you don't know."