Understand, Plan, Execute, Review
By: Kenny Dubroff
Tags: Software Development, Learning, Programming, Problem Solving, App Development

My Development Process When I’m Stuck

Understand, Plan, Execute, Review

Problem Solving with UPER

I’ve been making apps for years. Mostly apps for friends and personal use, some with teams of developers, and I’ve worked on plenty of other people’s codebases. One thing is a constant in every one of these experiences — problems.

I sort of developed my own problem-solving framework over the years, and it was hit and miss. I was recently introduced to UPER through Lambda School and it’s changed the game entirely for me.

If you’re like I was, when faced with a problem, you probably do some form of restating the problem in a way that you can understand it, thinking of how you’ll solve it, then jump in and solve it. If this is you, then you know — this never works consistently, and you may feel like you could’ve done it better — or at least differently.

UPER is a problem-solving framework (very similar to Polya’s Four-Step Problem-Solving Process) that‘s been around for a long time. Here’s a brief overview of how it works:

Understand

Take a moment and really understand the problem. What exactly are you trying to accomplish? It’s not time to actively think about solving the problem yet, but if you have ideas, let them come. Write them down if it helps you.

During this phase, I’ll usually rephrase the problem in a way that makes crystal clear sense to me. If there are any questions about the objectives, this is the time to get them answered (hopefully by the person who gave you the problem!)

Problem: I have a ton of employees. My HR team needs to be presented with this data in an organized manner and we have high turnover. Re-Stated: Problem: I have a large data set that needs to be sorted, and records need to be consistently and accurately inserted in the proper positions given a set of rules.

Plan (Avoid Pitfalls)

While thinking about this particular problem, you may have thought of what collection types you’d use for storage (arrays, dictionaries, linked lists, etc…).

If you’re using an OOP style language, you may have started thinking of classes and structs. I immediately thought of implementing a linked list and started thinking of the data structures that would go into that and what their hierarchy might be. If you didn’t think of anything in particular yet, though, that’s fine!

Now’s the time to research. Put your restated problem into a search engine and see what you come up with. Compare it to your own knowledge, do a sanity check, and come up with what you think the best course of action will be.

Make as detailed a plan as you wish. The more detailed, the more it’ll help you avoid pitfalls — but it’ll also obviously take more time and thought that you could spend elsewhere.

Make diagrams and drawings, doodle. Doodling can help you visualize things you’d have to imagine and continue imagining. This can free up resources you can use in the mental challenges to come and give you a handy visual reference.

Execute (Make It Work)

With your restated problem, and carefully plotted plan, nothing can go wrong, right? Ha! Wrong! There’s ultimately always something you didn’t plan for. Something you didn’t consider fully — and that’s fine.

None of this is set in stone! It’s all there to help us with our ultimate goal of solving the problem. It’s always fine and even encouraged to revisit previous steps. There’s no point in solving a problem you didn’t actually understand, or executing a plan that you know won’t work. Take a step back whenever you need to.

That said, the perfect plan never executed doesn’t do anything for anyone, so do it! As Facebook and crew used to say …

“Move fast, and break things!”

Now that you’ve “broken it better”…

Review (Make It Right)

You just made it work! Congratulations! But you know, and I know — it could be better. Maybe in your haste to execute, you used “magic” numbers or strings that’ll be a pain to refactor down the road, but easy to correct now. Maybe you’re using placeholders because you just wanted to get something on the screen to prove that you didn’t just waste all that time!

Whatever the case, even if you think it’s perfect… even if you're satisfied, review it. If you don’t find anything wrong, and you can, have someone else review it too. The best review you can do is handing the product off to an end-user and asking them to do something. See if they know what to do intuitively, see if the process works the way you intend, and gauge their response if they have any. Getting other’s opinions can do nothing but good for a good end product, but reviewing it yourself is vital.

I can’t count the number of silly mistakes I’ve caught during this review process, nor the number of UX improvements I’ve made here. Anyway, during the first review, focus on making things right. Use your best development practices, make sure you’re following your company’s style guide, and do everything you can to make that puppy shine.

Review Again! (Make It Fast)

I know, you already solved it, and you made it right. There’s nothing you could possibly do better, right? Well, maybe you realized for whatever reason a linked list isn’t the fastest way to get this done. Maybe random access will benefit you for whatever reason. Now is the time to make this beautiful creation into a streamlined jet engine.

Dust off your CS books, roll up your sleeves, and really dig in. Efficiency is the name of the game here. If you know how to make it faster, it’s within your budget and timeline, and you have an ounce of energy left, put it in. It may not seem worth it with how many resources modern computers have, but eventually, they reach their limit… and nobody wants to be labeled a resource hog!

Repeat After Me

U.nderstand

P.lan

E.xecute

R.eview

Make it Work, Make it Right, Make it Fast!

Gain Access to Expert View — Subscribe to DDI Intel