A long time ago, back before Star Wars, Minecraft, Marvel, The Simpsons, The Lord of the Rings, Ninjago, Ghostbusters, Angry Birds, and Jurassic Park all had their hands in the Lego set business, there were just plain-old Legos: primary-colored plastic blocks in a bunch of different sizes, shapes, and colors.

(We do love those new pastel tones, though.)

Workers in the Lego manufacturing plants built lots of different Lego bricks, but they didn't care one bit what you planned to build with those bricks. They built sub-assemblies (all those different bricks) you could use to build whatever you wanted—anything at all—from the bottom up to a lop-sided piece of abstract art.

(Just ignore the fact that it was supposed to be a lobster. It's abstract art now.)

Giving you the pieces saved you the trouble of having to build each Lego brick yourself as you needed it, which is not to say you couldn't have done that. Okay, we couldn't have done that, but you don't have to make a big deal about it.

Building things with Legos is basically bottom-up design: the Legos (which you can call sub-assemblies if you want to) are created first without any thought for how they work together in the end result. When you put together all of the sub-assemblies to create a working Lego lobster-turned-amorphous-blob sculpture for your family of pet Siberian hamsters.

Everyone knows Siberian hamsters love modern art.

As much as we love discussing hamster culture, let's get back to computers. Those memoized results you can make for recursive problems are just like Lego blocks. If you solved a sub-problem and stored its result for later but you don't end up needing that piece, it's no big deal. It just sits in storage. In the dark. Sad and alone. It's fine. Really.

That's where you start in bottom-up programming: building the sub-assemblies. These kinds of builds are great in times when there are a lot of unknowns or the main problem you want to solve isn't very clear yet. With really big problems (like making a fully-functioning computer out of Legos), it's impossible to work at a low level and consider the entire solution in-depth all at once. A bottom-up approach will piece the big picture solution together using solutions from sub-problems (like making a fully-functioning Lego CPU and a working Lego keyboard) with optimal substructures (problems that definitely have an optimal solution).

Just like in top-down programming, bottom-up programming breaks down the problem into isolated pieces. However, the bottom-up starts with the basic pieces and builds them to get a more complex solution. If you want your code to just solve one problem, either approach is fine. If you want higher-quality code that can be re-used for other things, you'll want to use a bottom-up approach.

Plus, dynamic programming and bottom-up programming go together better than Siberian rodents and a membership to the MoMA.