Posted by: jsonmez | March 10, 2013

7 Reasons Why You Should Tackle Hard Problems Last

I always hear the advice that we should tackle hard problems first.

It seems like pretty legitimate advice, and many of the reasons for saying so make sense, at least at a surface level.

The reasoning usually revolves around the idea that by tackling the hard problems first you can eliminate your biggest risk early and everything will be smooth sailing from there.

When you really think about the reasoning for solving hard problems first though, most of it is not actually reasoning, but based of off one emotion… fear.

We tend to think it is best to solve hard problems first, because we are thinking about eliminating our fear, not because we are thinking about what approach has the highest chance of success or is the most optimal.

I call this FDD, or Fear Driven Development.

And when I think about it that way, I find myself hard pressed to find a real good reason for tackling hard problems first besides being able to abort early.  Which, in some cases might be good, but I’d rather focus on success.


Here are 7 reasons why it might be a good idea to tackle the hard problems last instead of first.

1. Solving easy problems first gives you momentum

When a large ball starts rolling down a hill, it picks up speed rapidly and that large ball can bust through many barriers that it couldn’t before, simply because of one thing it has after rolling down a hill that it didn’t have before—momentum.

On the converse, trying to push a heavy ball up a hill is pretty hard.  And if there are barriers on the way to the top of the hill, not only do you have to fight gravity, but you have to be able to push extra hard to get through those barriers.


Life is hard enough, why make it harder?

I recently received an email from a developer that was concerned that his team wasn’t gelling and that they didn’t have the expertise in the technology needed to solve the complicated problem ahead of them.

They were going to start the project by trying to integrate this fairly complex technology and he was afraid that it would cause them a large delay before they would be able to get version 1 out.

My advice?

Start with your simple problems; get working software out there as soon as possible.  Not only will the team gel much more easily as they are having success and making real progress, but that momentum will help them when it is time to solve the more difficult problem. 

Even if they have to throw the first version away, when they get to the hard problem, the momentum alone will make them much more likely to reach success in the end.

I could give 100 examples of how solving easy problems to gain momentum can benefit you, but you probably already know intrinsically that this is true.

Long story short, get a running start before taking a big leap.

2. Avoid solving the wrong problem

wrongThere are few things worse than spending weeks or months solving a difficult problem, only to find out in the end that you actually solved the wrong problem.

The big problem with solving the hard problems first is that the hard problems usually require a large amount of context in order to fully understand them.

It is very hard to get the right context for a hard problem when we take it out of its natural order of progression and artificially cut it to the front of the line.

You’d probably like to start a college class by taking the final exam first, so you don’t have to worry about it, but the problem with doing so is that you’ll lack the context and information to understand the questions and to know the answers.

When we try to tackle problems out of order to avoid leaving the hard problems to the end, we end up losing all of the learning and context that would help us to solve the hard problems at the end and we are much much more likely to end up solving the wrong problem, which is a complete waste of time.

3. Someone else may solve the problem for you

Sometimes procrastination is a good thing.

Sometimes, when you purposely push off solving a hard problem till the end, you end up finding that someone else already solved your problem.

editingI was working on a Pluralsight video last week, using Camtasia 8 for editing, and I found that one of the video segments I was tried to load up was crashing the application every time.

I spent a few minutes trying to troubleshoot it, but nothing I was trying was working, so I had to make a decision.

I had 3 choices:

  1. Keep trying to solve this hard problem before moving on.
  2. Go on and do other videos and send off a support request to see if they could handle it.
  3. Make a new project and re-edit all the clips.

Choices 1 and 3 involved tackling a hard problem right then and there.

Choice 2 was to tackle easy problems and see if support could solve my hard problem for me, and if not, I would solve it at the end.

I ended up choosing option 2 and it paid off.  It turned out Camtasia support was able to solve my problem.  By the time I needed the project to complete my course, they had solved my hard problem for me and I didn’t waste any time upfront trying to tackle it myself.

Now it could have worked out differently; I might have had to solve the problem myself at the end, but instead of assuming I would have to and wasting perhaps a day or 2, trying to solve the problem myself, I pushed it off and kept working on easy problems and I gave someone else a chance to solve my hard problem for me.

It doesn’t happen all the time, but many times if we push off the hard problems we face, we find that by the time we get to them, someone else has already solved the problem for us.

4. Your own subconscious mind may solve the problem

When I said someone else might solve the problem for you, that someone else might actually by you—at least your subconscious mind.

Have you ever had the experience of thinking about a problem and not being able to figure it out, but then you wake up the next morning and suddenly have the answer?

It seems that our subconscious mind is more powerful than we are aware of.


In many cases, if we know of the hard problem we need to solve and have thought about it a little bit, our subconscious mind will start working on the solution, even though we are not aware.

Obviously this isn’t going to work all the time, and your subconscious mind isn’t going to write a bunch of code for you, but in many cases there is at least some benefit to throwing the problem off to our internal “worker thread.”

5. You are more committed to solving the hard problem when you risk everything you do so far

One benefit to saving the hard problem for last is that you have some extra motivation in the form of loss aversion.

It has been demonstrated in several experiments that people tend to try to avoid losses versus acquiring gains.

We can use this knowledge to our advantage by doing the easy work first and letting our loss aversion help motivate us to solve the harder problems, because we don’t want to lose all the work we put into a project so far.

By starting with easy problem, we put some “skin in the game.”

If we try to solve the hard problems first, we have nothing to lose, so we are much more likely to give up.

6. Hard problems are often easy problems bundled together

vanilla beans and orchid flowerI’ve talked many times about breaking things down and trying to keep things as simple as possible.

And it turns out that many hard problems (not all) are decomposable into many small easy problems.

If you strive to never solve hard problems and to always push them off, you may actually find out that you never have to solve hard problems.

Many times we can chip away at hard problems, by taking bits of them off a little at a time and solving those easier problems.  Eventually, you may find that you’ve reached the tootsie roll center of your hard problem lollipop and it is filled with chocolate candy!

Now, some problems aren’t very easily decomposable, but a good majority of problems are.  Once you develop the skills to chip off bits of hard problems into smaller easy problems, the world looks like a much more conquerable place.

So, saving hard problems for last and breaking off little pieces of them as you go, can be a good strategy to help you to wear down your opponent before you have to face him.

7. Some hard problems are never truly solved

One of the big problems with tackling the hard problems first is that they tend to fill up as much time as you’ll give them.

If I give you an easy problem, like write a function to reverse a string, there isn’t much to think about.  You can solve it a number of different ways and there isn’t a huge difference in the efficiency of the different methods of solving it.  It is pretty unlikely you’ll spend weeks revamping your solution and thinking that it’s not quite right.

But, if I give you a problem like, create an in-memory database, not only is it a hard problem, but it has a huge number of possible solutions and can be optimized from now until the end of time.  You could spend 2 weeks working on that task or 2 years.

The problem is that many hard problems don’t have a good scope to them when they are solved in isolation.

If you design an engine for a car that isn’t built yet, you won’t know when you are done.

But if you design an engine for a car and you know how much it weighs and know what kind of transmission it will use and what kind of fuel efficiency it needs to have, you can have a much clearer understanding of when your engine design is done.

If you save the hard problems for last, the scope of those hard problems will be much more defined, which will keep you from wasting valuable time over solving a problem or, like I mentioned earlier, solving the wrong problem altogether.

If you like this post don’t forget to Follow @jsonmez or subscribe to my RSS feed.



  1. Great article 🙂

  2. Interesting points, but as a former PM, I have to strongly disagree. All of your points are valid, but you’re adding substantial risk to the project. My own experience is that developer overestimate the small stuff (a bug fix require 1 line to fix requires an hour), but underestimate the big stuff – sometimes by factors of 3-10 times. While all the points above are advantageous to the programmer, they allow the programmer to inject unjustifiable risk into the project.

    That being said, if you know the parameters of the “hard problem”, then it i often possible to mitigate that risk (ex. I’m doing something “hard” to me, but I know that a senior programmer on the team is an expert an can advise, if necessary), then my answer changes.

    • Good point. I agree, I’m just of the opinion that estimates are so inaccurate anyway, that it doesn’t matter. If you tackle the hard stuff first or the hard stuff last, the time is still the same, but perhaps it can be less if you save the hard stuff for last.

  3. An extension of point number 2:

    Tackling big problems first means you don’t benefit from the additional knowledge you’d gain by knocking off smaller items first. This is especially true if the problem is hard because it represents a complex part of the problem domain (rather than just being technically challenging). Understanding the business better will lead to more mature thinking on the big issues.

    • Yeah, that is a good point.

  4. The problem is usually that we don’t confine our power to one particular channel and this solely could be the source of many problems ahead. Turning a big problem into a manageable one usually helps, too. Thank you for your different perspective, though. 🙂

  5. FDD – Fear Driven Development )) Good article.

  6. interesting article !!!

  7. Hi, Good article that really makes us think in a different way. A lot of Agile advice tell us to “bring the pain forward”, but this really trends away from the Lean advice of change at the “last responsible moment”.

    Your article really does provide good cause for “last responsible moment” problem solving, at which point we tend to have much more information available to us to solve the challenge. It’s all about leaving your options open until you have to make a choice at that time, and no sooner.

  8. Really interesting post. My only concern is about risk, in the case the hard problem turns out to be a show stopper. Would be sad to discover that late, after tons of invested effort? What are your thoughts about that?

    • I try to optimize for success and not for failure. It is true there is more risk involved, when you do fail, but I am of the mindset that you are much less likely to hit a hard problem that is a show stopper if you have already had successes and invested heavily.

  9. Interesting. I have argued along the same lines but my argument focused on the capability of the team. Many projects are started by assembling a team that has not worked together before. Some of the technology needed might also be new to them. If you see this as an analogy to a football team that you just recruited, would you let this team go up againt the best team in the league or would you try to find easier opponents first?

  10. Some great advice here. I can think of exceptions, of course. Right now, I’m working on a set of mobile apps that depend heavily on intercepting raw notifications. Also, the entire backend is *almost* more important than the UI/UX. Both in that it’s the revenue generator and crucial to the whole model working. And in that I can do UI/UX in my sleep. So I’ve put the hard stuff first in that case.

    I do particularly agree that often someone else will have solved the problem and that context is critical. I usually don’t do this, but am spending a day viewing and working through your Pluralsight course on ServiceStack so I can get a better understanding of how it can help me code my services.

    • Good point. And I agree, there are definitely exceptions. You just have to use common sense and make sure to not let fear drive your decisions.

  11. […] 4. you’re always more focused and productive with limited time 5. start with short tasks. 7 Reasons Why You Should Tackle Hard Problems Last 6. “Done is better than perfect” (*) – iterate 7. separate thinking and execution […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: