Focus on Slow Growth and Earn Your Complexity

In one way or another we have all seen this happen. We start working on a new brand new idea and are brainstorming about all the amazing features we are going to implement. Of course, we get very excited, and before we know it we are hacking away at a new Minimal Viable Product (MVP) using the latest technologies and frameworks. We are even saying to ourselves, we are going to do it right this time.

Not soon after, we are presented with a mountain of setbacks. The development velocity has slowed, the application isn't performing and the architecture we thought we had, isn't helping us at all. At this point, we realize we have fallen for the same trap yet again.

Build The Essentials First

Instead of jumping head-first into a new idea, we should remind ourselves to take it slow. A new idea is always fragile and resistance comes easy. We should try to keep the entire system, including code, infrastructure and CI/CD pipelines as simple as possible. This will help you minimize any unwanted friction.

One feasible approach is to develop the essentials before we even worry about the more complex features. According to the 80/20 rule in software development, we want to focus on developing the majority of the features, which is about 80%, with minimum effort. It just so happens that, in most situations, the majority of the users are happy with 80% of the features and only a handful require the remaining, more complex, features. When I say Focus on Slow Growth, this is exactly what I mean. Build what you need now, and build what you might need, later.

"Developers are drawn to complexity like moths to a flame, often with the same result." ~ Neal Ford

Overtime, complexity is inevitable, but it should only be added when once you have a clearly defined use case that requires this additional complexity. Try to keep your system simple for as long as possible, and make sure any new complexity is earned.

How did we apply this for Draftsman.io?

Obviously when building Draftsman.io, we have many great ideas. Some of them easier to implement that others. When we are about to start building a new feature we always ask ourselves "Is this essential for a version-one MVP?". Notice how we say that this is a decision we make for the first version of the software. In the future, once we have a stable release, we will likely reconsider the features we chose to leave out the this version. This gives us the ability to delay implementing a complex feature, and therefore granting us more time to Shape this feature.