Enemies of Shipping: Agents of Complexity

Complexity

Building software products is fundamentally about managing complexity. Success means being able to easily change the product (adding, removing and fixing features) with minimal cost. The more complex the code and the product design, the harder and more expensive it becomes to ship.

Given this, you'd think everyone would be doing everything thing they can to keep things simple and to avoid any complexity that they can. Alas no.

Some software developers are drawn to complexity. Rather than avoid it, they will voluntarily and gleefully add complexity to the project.

Why solve a simple, boring problem when you can solve a bigger, more interesting problem - a far more worthy intellectual challenge for our developer?

Why do something well understood, boring and simple when you can turn your project into a research lab or learning exercise for the latest programming fad-technique?

This attitude is disastrous for your project and potentially for your team and entire organisation.

Return of the Architecture Astronauts

The love of complexity often reveals itself as an obsession with architecture, abstractions or even a programming paradigm. Joel Spolsky wrote about this in "Architecture Astronauts" all the way back in 2001. (There was a follow up piece in 2008, "Architecture astronauts take over" - both are highly recommended).

The hallmark of an architecture astronaut is that they don’t solve an actual problem… they solve something that appears to be the template of a lot of problems. Or at least, they try. -- Joel Spolsky, "Architecture Astronauts take over"

The architecture astronauts are real, they are out there and they can wreak havoc on any team that should be more concerned with shipping product.

Because architecture astronauts by definition want to work on grand, all-encompassing things, they can poison a project's entire codebase and destroy productivity for the whole team.

Vigilance

Be vigilant for the influence of architecture astronauts, and make sure your team is able to challenge and discard the ideas they promote.

Be vigilant for people who add needless complexity to your project. Sometimes it is just because someone doesn't know a better, simpler solution. But other times it can be someone acting upon an agenda to do "more interesting work" or to "learn something new" (CV building).

Even more than that, develop and foster a zero tolerance policy for unneeded complexity in your product's code and its design. If you aren't building something trivial, there will be more than enough necessary complexity to deal with.