At first pass, building a comprehensive application or API library seems straightforward. You want to make sure that every possible scenario is covered for proper data coverage and that the user can do anything (however small) they want within the app.

However, the ramifications of this approach can be larger than you think. This has led us to adopt the acronym YAGNI: You Ain’t Gonna Need It.

Here’s an example of how YAGNI applied to a recent scenario we encountered

We built a platform for a client that allows users of the application to post jobs or find work via job postings. We provided a simple interface they can use to specify a fixed, hourly, or daily job, making it easy to calculate how much the worker will get paid. With a simple calendar control and a couple of taps, a job is created. This, for example, could let a worker know they are working Monday through Thursday handing out flyers.

A discussion around this feature arose. What if the job owner wants to hire the worker for two weeks, but not have them work weekends? What if they just need them for Monday, Wednesday, and Friday, but don’t want to post three separate jobs or make it a “single fee” type of job? An idea was brought up to expand the date selection process to account for these various scenarios. At first pass this sounded like a valuable feature to add to the system.

As we discussed the topic further, some new concerns cropped up. Implementing this feature would introduce new complexity to the job selection interface and the underlying code. Would we use special “job date types,” “exclusion flags,” or even individual date records to specify these special scenarios? This would involve a significant change to the code base and a lot of testing.

And most importantly, would the change be worth it? How many users would actually take advantage of this feature?

So far the answer is one user. There’s a chance it would stay at one user too. The time, technical complexity, and future maintenance of the code base doesn’t warrant the benefit one user will get from making the change. When it came to the choice of whether to intricate a custom date selection model, we decided “you ain’t gonna need it.” Holding off on this update and using the solution in place has been sufficient, but if enough feedback comes from customers indicating this feature is necessary, we can implement it at that time.

When we build solutions at Fresh, we like to use a Minimum Viable Product (MVP) model. This isn’t to say that we try to skimp on features. Rather, we find the essentials for your solution, build it, and get it up and running so you can engage with customers and get feedback. We can immediately start working on the next iteration of essentials to improve your solution once we have a working product. Since we build solutions that are designed to be flexible and use an Agile development workflow to match, we can rapidly grow as needed. This takes YAGNI to heart. 

The next time you start a new project or evaluate features to add, take an additional moment to evaluate the complexity involved and how much impact it will have. There’s a good chance ya ain’t gonna need it.

Interested in reading more about the Minimum Viable Product model and implementing an essential feature set? Check out our white paper, The Strategy of Starting with Less.