Simplicity—the art of maximizing the amount of work not done—is essential.

When I first started in development, I tried to plan for every possible situation. I was given the requirements, but always asked “what if?” What happened more often than not was I’d build a feature and then never actually implement it because either the requirements changed or the customer decided they didn’t want the feature.

Now I know, simplicity is more about what you don’t have to implement versus what you do.

To accomplish this, I’ve learned to follow requirements and just implement the features outlined in those requirements. If you try to implement more—something we might need—then you end up doing all this extra work, writing all this extra code, for nothing.

One concept I like to follow is YAGNI: You Ain’t Gonna Need It. That logic is true more often than not. Rather than plan for possible futures, create the simplest solution for the requirements you have now, then if you have a change—because you’re being agile—you can adapt to the change then.

A major benefit of working in small increments is we can adjust to change. If we end of needing the thing you thought you needed before, you can develop the feature in the next sprint. Even if you’re certain a feature, framework, or block of code is going to be necessary in the future, just remember: you ain’t gonna need it.

Trying to identify if your solution isn’t simple is a little bit more tricky. A general rule of thumb is if something sounds complicated, it probably is. A good place to start in maximizing simplicity is to focus on what’s going to bring you the most value to your customers with the least amount of work. You should focus on delivering the minimum viable project, or the least that gets you the most. Avoid building the maximum viable product with all the bells and whistles, because it’s going to take you forever to implement, and once you implement it, the customer is going to want something different

The less time you spend on building features that you’re going to have to potentially throw out, the better.

I’d love to continue the conversation with you in the #agile channel on the TechWell Hub.

Leave a comment

Your email address will not be published. Required fields are marked *