Some problems are complex, and there is no getting around it. Others can be boiled down into problems that are easier to solve.

In a recent post, I worked through the hypothesis that there are only four ways to reduce software development time. I think this logic can be applied to many different kinds of projects.

One variable we included in our model was complexity. Here we will look at a few ways that we can reduce complexity in software development and other kinds of projects.

1. Limit Your Options

Some problems have a multitude of options for potential variation. Consider the simple sounding task of “designing a webpage”. The immediately obvious variables are:

  • What colors should we use?
  • What should the layout be?
  • Which fonts?
  • Content and imagery?
  • Design style?

If you are a professional web designer and your full-time role is crafting bespoke websites, you will likely be focused on taking the time to carefully choose each of these elements.

On the other hand, if you are building an app MVP (minimum viable product) and aren’t primarily focused on these items, you should find ways to restrict your choices so you don’t waste your time.

For example, whenever I’m building the first version of a new application, I always grab the colorset from Google’s Material Design Framework. There’s enough variety that I can create things that don’t all look the same, but I don’t waste time messing with custom color schemes and hex codes. I can pick a handful of colors from the predefined set, make a color scheme, and have something that looks great. After all, Google already spent time and money to figure out that these colors look good together.

This illustrates the idea of knowing your primary problem.

For the web designer, the design elements are the primary problem. For the app developer, getting the functionality finished for the MVP is the priority while the design is secondary.

Rule of thumb: Optimize for your primary problem and find systems to deal with your secondary problems.

Think 80/20: What frameworks, tools, libraries, and etc. already exist that solve 80% of my secondary problems? We can live without the remaining 20% for now.

2. Simplify the Problem

Often times in software development, there is the perfect solution, and then there is a decent solution. As discussed in a previous post, these solutions can vary widely in complexity.

In many cases the decent solution only takes 10% of the time to build compared to the perfect solution. You just have to decide when the decent solution is good enough.

The hard part is identifying the decent solution in the first place. I’ve met my fair share of engineers who go straight for complexity like a bug to a lamp.

I don’t have a fully-formed rational for this yet, but anecdotally speaking – some of the developers that I’ve met that have basic user experience or design skills tend to have an easier time envisioning quicker, simpler solutions. Perhaps this is why Basecamp’s teams work so well: They have a max team size of three people with each team having one designer and one to two developers.

(This is one way people get the impression of 10X developers. Some people choose solutions to problems that are much easier to build and therefore much faster to build.)

You can’t (and shouldn’t) always do this, but you can do it more often than you’d think.

This also goes back to point number one above. If you’re working on something that isn’t the primary problem you are trying to tackle, it makes sense to choose solutions that are simpler and take less time.

3. Invert Time

One powerful way to speed up development is to swap this question:

Here’s what we want to build. How long will it take?

for this question:

We have six weeks. What can we get done?

This is one of the foundations of iterative development (e.g. Agile). However, I believe that most people still don’t think this way.

Framing estimation like this causes you to come up with solutions to problems that follow the logic presented in points one and two. If I need to solve a problem, and I only give myself two days, I’m putting pressure on myself that forces me to make tradeoffs.

When time is flexible, I’m less likely to cut my ideas to the simplest version.

This point is similar to the idea of gold plating from Agile development. My personal distinction is that gold plating tends to be thought of as adding extra enhancement after requirements are met, and I think many requirements themselves could actually be trimmed or defined more clearly to reduce complexity.

Tim Ferris pushed this idea to the extreme is his book “The 4-Hour Work Week.” The essential hypothesis is – if you had to get everything you’re responsible for in a given week finished, but you only had 4 hours per week to do it, what would you do differently? He pushes you to think through how you could outsource different redundant tasks, etc.

This type of thinking has the effect of forcing you to cut the fluff and really focus on what matters.

Need Help?

We are a full service software engineering firm. We can help you with everything from design to project management to development.

Got a project you’d like to talk about? Get in touch at