Several years ago, I had an interesting experience with a team member we had just hired – let’s call her Ashley – and it taught me a lot about managing software developers.

Up to that point, our small team was made up of people who liked to wear multiple hats and juggled everything from product design to backend development. Ashley was a highly gifted backend developer, and she didn’t care much for anything else — which is great because that’s what we hired her to do.

A web application we were working on at the time had a bunch of actions that could trigger notifications and emails to users. We wanted to give the users the ability to control how often they received these.

Knowing that Ashley didn’t want to do any frontend work, I told her to just build the backend and put together a simple HTML form and then a frontend developer would style it. For some reason, I assumed that she had the same idea about what to build that I did. In my mind, this would only take a few days.

A week later, I get the following message on Slack: “How do you want me to handle the units?”


I was completely confused. We jumped on a call, and she showed me what she had put together. There were a bunch of form fields, and a user could specify exactly how many weeks, days, hours, and minutes there should be between receiving notifications.

In my mind, I had pictured us asking the user how often they’d like to receive notifications and the possible answers being something like:

  • Immediately
  • Once per day
  • Never

There could have been extra options, and that would have been fine. But I never expected to see the level of detail provided. Not only was the backend far more complicated that I had envisioned, there was really no reason to give the user that many choices.

This was completely my fault as a rookie manager, but it also highlights a few principles that I believe we can apply to software projects in a broader sense.

How can we tell if we are overcomplicating something? Here are a few thoughts:

1. You are building something that is “infinitely flexible”

In every situation that I can think of, adding massive flexibility to one aspect of a system causes a serious drawback somewhere else.

For example, suppose we say that we have created a database technology that’s perfect for handling everything from one record all the way up to many billions of records. In all likelihood, the time it takes to set something like that up as well as learn the query language is not worth it if we are just working with “small data”. We don’t actually need that flexibility.

Interfaces can help bring this into focus.

If you are going to have to turn the web browser into a spaceship control panel in order for a user to operate all of the various settings, you might want to slow down a bit and ask if you really need all of that.

Comprehensiveness is the enemy of comprehensibility. – Martin Fowler

To be clear, there are situations that require high levels of flexibility, but in my experience, most situations don’t.

This line of thinking impacts people all the way up the product development chain, not just software developers.

2. You can’t write compelling user stories

First, if you are unfamiliar, a user story is a simple description of a capability that a user would like to have, written from their perspective. Here are a couple of examples:

As an admin of <platform-name>, I’d like to receive notifications immediately so that I can respond to questions as fast as possible.

– or –

As a member of <platform-name>, I’d like to receive a summary of notifications at the end of each day so I can stay in the loop without being bombarded by messages all day.

Thinking back to my story with Ashley, how would you write a user story for someone who wants to receive notifications every 1 hour and 6 minutes? I can’t think of a compelling reason they’d want to do that.

Ultimately, the question behind this question is “Why does the user want to be able to use <thing-we-are-making>?” User stories are a tool to force ourselves to define an answer to that question for each thing we build.

If you can’t come up with compelling user stories, it probably means that you are adding extra things into the product that don’t belong.

3. Your expectation of how long it will take to develop is much longer than that of your team

This point is self explanatory, and it’s why it’s essential to have good inter-team communication.

If everyone else expects something to take 2 days, and you think it’s 2 weeks, something is off. It’s possible that you are actually right, but it’s a good way to immediately see that at a minimum you and your team need to pause and get on the same page.


None of these things necessarily mean that you are definitely overcomplicating things, but they should be red flags. If you catch yourself in any of these situations, pause and ask if the flexibility is really needed, why the user would really want to use this, talk to your team, or all of the above.

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