Agile Zone is brought to you in partnership with:

John Sonmez is a Pluralsight author of over 25 courses spanning a wide range of topics from mobile development to IoC containers. He is a frequent guest on podcasts such as DotNetRocks and Hanselminutes. John has created applications for iOS, Android and Windows Phone 7 using native tools, HTML5, and just about every cross platform solution available today. He has a passion for Agile development and is engaged in a personal crusade to make the complex simple. John is a DZone MVB and is not an employee of DZone and has posted 88 posts at DZone. You can read more from them at their website. View Full User Profile

7 Reasons Why You Should Tackle Hard Problems Last

  • submit to reddit
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.

Published at DZone with permission of John Sonmez, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Barry Smith replied on Tue, 2013/03/12 - 4:56am

"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"

Interesting - do you have some peer reviewed article links for that?

Sandeep Malhotra replied on Tue, 2013/03/12 - 10:49am

Wow...John - I couldn't disagree more on this topic (I can see the value of #1 though!).  But what if some of the hard problems are critical enough to be a show stopper down the line (in case they are not resolved by others or our subconscious)?  There is a reason why many developers and architects invest effort and commitment upfront to knock down some of the tough ones in some shape or form of a Proof of Concept.   

John Sonmez replied on Tue, 2013/03/12 - 11:04am in response to: Sandeep Malhotra

I see your point, but I would much rather optimize for success than mitigating failure.

Michael Gomez replied on Tue, 2013/03/12 - 11:32am

Most of your points are valid, but what I have seen is that your 5th point ("You are more committed to solving the hard problem when you risk everything you do so far") causes the hard problem to be solved in terms of the easy problems to date instead of the natural solution.

A non-software example of this is when you're designing a car, if you design all the bolts and mounting points first (easy) then design the engine (hard) you now have to fit the engine to the mounting points, instead of designing the engine with a clean slate and then figuring out how to mount it.

Barry Smith replied on Wed, 2013/03/13 - 8:40am in response to: Michael Gomez

On the other hand, if you were designing a car engine do you really think your main consideration should be "how is this going to fit into the mounting points we designed"?

It sounds better to me to design the complex bits as well as possible first and then let the easy bits conform to them.

Lee Wallen replied on Wed, 2013/03/13 - 4:08pm in response to: Barry Smith

This is only one link, but it fits #4: 

Wednesday, February 13, 2013

Press Release: Carnegie Mellon Brain Imaging Research Shows How Unconscious Processing Improves Decision-Making

Michael Gomez replied on Wed, 2013/03/13 - 4:11pm in response to: Barry Smith

Barry, I can't tell if you're agreeing with me or not :).

But yes, I plan projects out by impact/need.  If the most important part happens to be hard/complex ...well then, I guess we're doing the hard part first!

To me, planning based on hard vs easy is just playing an accounting game.  Are you trying to report minimized risk or boxes checked?  I agree with John that you should schedule around driving success, I just don't think that it is as simple as breaking projects into easy/hard components.

Lund Wolfe replied on Sun, 2013/03/17 - 2:28pm

I agree with letting your subconscious work on the hard problem concurrently and letting the aha moment come later.  You can also take time to share the problem with others who might be able to crack it.  The important thing is to start thinking about it immediately and not bury your head in the sand and stress out consciously or unconsciously about the show stopper problem waiting to happen.

Hard problems can dictate the architecture/design.  Solve them early and you will build the team's confidence or at least alleviate their fears so they can concentrate on their own easier problems or skill training.  If the problem is hard because it is vague, you can't solve it anyway.  You'll have to go back to requirements/analysis or use throwaway prototypes to get the real requirements from the client/users.

If you are going to fail, do everyone a favor and fail fast and move on to something where you can win with a minimum of thrashing and suffering.

If the hard problem is not an important core problem, you may be able to hire a specialist or buy Off The Shelf software to do it for you and just stub that functionality out until it eventually gets implemented.

Jose Fernandez replied on Mon, 2013/03/18 - 11:42pm

I think it depends on your definition of "tackle". If you have no idea how to do something or if something can be done, you can spend a whole lot of time building a framework around something that will never work. Unfortunately I've been there. I try to follow tracer-bullet development where there should be at least one working functional line throughout the application before you start to flesh anything out. The fleshing out of the hard stuff can and should wait, but you should at least know if its possible or even plausible.

Oleksandr Alesinskyy replied on Wed, 2013/03/20 - 8:22am in response to: John Sonmez

OK, it all depends (as usual :) ).

You have to assess the hard problem(s) - and if it is a show-stopper for your solution you should tackle it early enough to see if it is solvable at all. Otherwise all your "successes" with easy problems have a good chances to go down the line.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.