Over a million developers have joined DZone.

Tiny, Tiny Steps – Experience Report Developing A Feature In Minimal Value-Adding Increments

DZone's Guide to

Tiny, Tiny Steps – Experience Report Developing A Feature In Minimal Value-Adding Increments

· Agile Zone
Free Resource

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

A post for those who want to see what an iterative, MVP-driven development of a feature looks like.

Once upon time, there was a webshop portal with hundreds of partner webshops displayed on the front page. Potential users wanted to find out if their favorite webshops or a particular type of goods were available, existing users wanted to find a shop quickly. Therefore it was decided to implement search. But how to do that?

Alternative 1: The waterfall search

We have immediatelly switched on our engineering brains and started looking at Solr/Lucene and the APIs of the webshops to be able to import their goods catalogues so that our users could find everything from one place. Luckily enough, we havent went far along this path. It would certainly take us weeks while the users would still have been stuck with the same unusable, unsearchable grid of webshops with only few broad categories to help them.

Alternative 2: Minimal viable feature growing iteratively

After the original diversion, I have focused on getting value to the users ASAP. Thus the development was as follows:

  1. Purely client-side search (or rather filtering) in webshop names, a case-insensitive matching of a substring
  2. Addition of a library that can do fuzzy matching so that even misspelled names are found
  3. Addition of keyword search – for each webshop we had tens of keywords such as “shoes” or “sport” so I transferred those to the browser as well and started to search them too. (The display of the results has evolved accordingly. I have also introduced lazy loading of these data not to impact initial load time.)
  4. I’ve moved the search to the server-side to save clients from having to fetch so much data and thus increase load size, especially on mobile devices. This also opened possibilities for searching other sources later on. That is where we stopped for the time being. (Thanks to using ClojureScript at frontend and Clojure at backend, this was mostly copy & paste.)

The good thing was that every few days we could have delivered increased value to the users. And I was also able to test the search on a frined (thank you, Fredrik!) early in the process and improve the UI considerably. (Weak search with good UI/UX may well beat great search with terrible one, it turns out.)

What could have been improved

It wasn’t perfect though:

  • We actually did not deploy the individual iterations to the users for other reasons (but we could!)
  • We had no monitoring in place and thus couldn’t know whether users used it (and thus that it was worthwile to develop it further) and how they used it or failed to use it.
  • I’d have loved to see the impact on our conversion rates and active user base.


I love iterative development, doing the minimal thing possible to push value to users and get real feedback on it ASAP. In this case it turned out that a far simpler solution than originally envisioned, developed in few days, was sufficient. Win win.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.


Published at DZone with permission of Jakub Holý, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}