YAGNI (You Aint Gonna Need It) is a reminder to all who write software not to over engineer your designs, keep things simple, and add complexity only when necessary.
Usability, on the other hand, is about improving the users’ experience with the software—additional architectural complexity be damned!
YAGNI vs. usability are two forces that sometimes bump on agile projects.
This post looks at a simple example of how these forces can conflict, and how teams can help find the right balance for their project.
Keeping it simple
My last project was a web based application that showed users at a construction site which roads were closed on any given day.
One of the stories was called display road closures and the first version of the story looked something like this.
With a simple date based search at the top of the screen, the user simply enters the day they are interested in seeing road closures. They hit the search button, and the map refreshes showing which roads are closed, along with the search results at the bottom.
Delighting your customer
During development, my partner came up with a better way to visualize which roads were associated with which permits. Instead of simply displaying road closures in red, why not give each road closure a different color. And while we are at it, why not make the search results selectable—so that when the user clicks on a road closure at the bottom of the page, the associated road on the map becomes more bold and visible to the user?
I thought his idea was great. It required a fair bit of custom JavaScript, which would add some complexity to the UI. When asked how long he thought it would take, he said about an hour. Thirty minutes later it was done and integrated into the code base much to the delight of our customer.
Playing the YAGNI card
Deciding whether or not to implement this feature was a no-brainer. My partner had the necessary JavaScript chops, the cost was minimal, and our customers loved it.
But what if the trade-off wasn’t quite so black and white?
What if we didn’t know JavaScript?
What if the improvement, compelling as it was, was expensive to implement?
What if making the necessary change did require some heavy architectural lifting?
How should teams balance the desire of keeping things architecturally simple, with a desire to delight their customers?
See how you are tracking
Before getting all hot and bothered about whether to invest in an enhancement, or add a new feature, check and see how your project is tracking.
If your team is struggling to deliver stripped down, spartan versions of your customer stories as is, spending additional time on UI improvements is a luxury your project can’t afford.
On the other hand, if the team is on track, and the customer is happy with what they are getting, there may be a little wiggle room to make a few usability enhancements here or there.
And if your team is delivering ahead of schedule, all options are open. Go ahead and try the 13 shades of blue.
Know your project context
Every project is different. And not all have the same requirements around things like usability.
For some projects, a few fields and a submit button are more than enough. For others, nothing less than an aspirational experience will do.
Knowing ahead of time what your project requires, and how your customers feel about stories being ‘good enough’ will tell you whether you need to spend more or less on usability and the experience of the user. Putting working software into your customers’ hands sooner rather than later will serve you well.
Don’t be dogmatic
While YAGNI is certainly a sound architectural principle, like any sound principle it can be taken too far. When YAGNI is repeatedly used as a trump card to prevent improvements to user experience, it can upset team members, and cost the team an opportunity to better serve their customers. Not all usability enhancements need to be expensive, and sometimes the smallest of changes can make the biggest of impacts.
Like most things in life, it comes down to striking the right balance. The only way you’ll find out is if you build something, show your customers, and get some good solid feedback along the way.
Until then, you’re just guessing.
Like this:
Like Loading...
The Agile Warrior 