Complexity = Features²

I have developed a simple formula (or, more accurately, a rule-of-thumb) for measuring the impact of an added feature on a software product.

Complexity = Features²

Let me show you how this works in practice — Kickstarter reward style:

1 Feature² = 1cu (Complexity Unit)

A website that shows a single static image.

2 Feature² = 4cu

All the above, plus a third-party email newsletter signup field

3 Features² = 9cu

All the above, but instead of one static image, we’ll throw in a carousel because reasons. Oh, and put that newsletter signup gadget on the 3rd page of the carousel.

4 Features² = 16cu

All the above, but each of those 6 carousel pages should link to a new page with some info. The pages all share a template so it’s easy, right?

5 Features² = 25cu

All the above, plus a Facebook “Like” button on each page. And we want the content that’s shared to look good, so don’t forget to set unique OpenGraph metadata for each page.

6 Features² = 36cu

All the above, plus a blog. Gotta have a blog, man. How will they know if we don’t have a blog? Please use Wordpress because I’m used to it.

7 Features² = 49cu

All the above, plus, why can’t I use Wordpress to edit all the content on the site? It will save you work in the long run.

8 Features² = 64cu

All the above, plus a simple sweepstakes. It’s only open to the people who signed up through our newsletter provider, so there’s not too many possible entries you have to worry about.

9 Features² = 81cu

All the above, plus we’re extending the contest because hardly anyone signed up. We need you to help us promote the sweeps on every page with a cartoon puppy that animates on screen and audibly barks once a day. And we need to send out an HTML email to let people know they can win the prize. And can we let people enter the sweeps more than once, but only once a day? I know we established the rules differently, but you can change them, right?

My definition of feature is fairly loose. It’s a “you’ll know it when you see it” sort of thing. And it’s not always the case, but as you get deeper into a project’s build, newly devised features tend to involve more work than older ones.

Features aren’t inherently bad, of course; we need them to do anything; duh. It’s just, too much of a good thing can be…not so good. Especially when they pop up late in a project’s build or on top of an already complex piece of software.

Where’s the Features² rule-of-thumb come in to play in a real-life project? For me, it helps me explain how any given feature could affect a project’s timeline, budget, crunch-level, etc.. Something with 9 features of increasing difficulty will take me roughly 80 times as much time to put together as something with a single feature.

It should cost roughly 80 times more.

The codebase will be roughly 80 times bigger.

The risk of failure is 80 times greater.

I hope you enjoyed this blog post. It’s not the only one! Please enjoy reading another from the list of selected posts below. You can see all my posts here.

How much does it cost to sell stuff online?

Looking at the current state of consumer ecomm fees.


Introducing a new tool for Responsive Design.

Anxiety Debt

Mental overhead from our digital social lives is getting us down.

Three from Last Week

Company retreats, client projects and babaganouj.

For the Love of the URL

A love letter to the endangered visible URL.

The Internet is a Mirror

Reminding myself that the internet is what you make of it.

This Website

Consider this my "About" page.


Motivation, cold weather, and moving to New York City.


The journey can be so addicting, I might never arrive.