I’m currently working on an ambitious, highly technical project with a team. It involves robots, edge computing, radio control, GPS, and servos. This particular project has inspired me to come up with a new law about the natural trajectory of projects like these.

Here's version one: Projects will only ever increase in complexity unless intentionally and severely simplified along the way.

I'm going to call it Didorosi's Law. I get to call it this because I've lived this experience time and time again like my own shitty little Groundhog Day. Each time I embark on a new project the mission is very simple and pure: Build a little thing, put it out, roll credits, everybody claps.

It's never this easy though. Somehow along the way somebody suggests a new technology they’d like to try, an amazing feature we just need to have, or they want to ham in some enterprise gizmo in the pursuit of legitimacy. Somehow we always come into a project with plenty of tools, materials, time, and know-how -- yet in the middle we usually find ourselves woefully short on all four.

I’ve also learned that individual contributors can rarely reduce complexity. Nobody wants to be against adding neural net machine vision or high-powered lasers to a project. There’s little incentive for a contributor to be a buzzkill and suggest we take a shorter, easier path. Doubly so if they’re a contractor that bills hourly.

The third and probably strongest pillar of the complexity trap is confusing complexity with quality. Something with more features built on a harder technology with more acronyms must be better, right? Almost never. There’s an essential urge over time both with careers and teams to build sequentially “harder” projects by adding complexity and therefore risk in pursuit of something grander. I’ve found this typically gets me less of what I want and way more of what I don’t want.

When I start to hear plans personal or professional running out of control I think of only one thing: The Homer Simpson car that bankrupted his brother’s company.

The only solution is to slice and dice when starting a project, slice along the way, and slice near the end. 

When you start cutting you’ll most certainly feel the familiar itch of your good old friend “Sunk Cost Fallacy” telling you your team put so much work into a particular feature it just must be finished. This is the critical moment. Don’t hold back. It might sting to toss away good code now, but it would’ve felt fifty times worse to miss your ship date entirely later.

You probably think your team will be disappointed if a certain feature or ambition gets put on ice. It’s possible that people will get bummed out seeing their work get parked, but I’ll bet a dozen good donuts that the emotion they’ll elicit will actually be relief.

Everybody knows when there’s ten pounds of shit headed for a five pound bag. Most plucky contributors will smile, nod, and try their damndest to deliver on time. Everybody wants to win and ship on time. Nobody wants to be the nag that’s bringing up that pesky externality called reality.

Instead, do everyone a favor up front, sharpen your machete, and hack away on your plans until you get to only what truly matters -- and don’t stop cutting until you ship.