I started a new project this year and part of my responsibilities is gathering requirements and converting them to user stories and acceptance criteria. It’s been a very interesting experience for me and put me a little out of my comfort zone. I’ve been sheltered most of my career, with someone else there to drive out these requirements. It’s actually taught or reinforced a lot of things that I think are very important.
Distilling to Minimum Viable Product
Before this project I was sharing office space at a startup incubator, where people with an idea were given some direction and focused on what they really need to do first as a startup: get customers. One term I heard over and over was Minimum Viable Product. What is the smallest thing of value you can launch with? I’m taking the same approach with an enterprise application: what’s the smallest set of features you need to stop using you’re homegrown excel application. The interesting thing to me is that I’m not just reminding the business owner, but also myself.
Do the simplest thing that works until it doesn’t
What’s the simplest thing you can do to solve the problem but also follows sound software design principles? I’m not saying you should cut corners on your architecture to complete the application quickly, in fact the opposite. No matter how well you can elicit requirements from business owners and no matter how many thought provoking questions you ask, until users start using the application, the users simply won’t know everything they need until they start using the application. By using a modular design that’s has easy to replace functionality you can keep the process simple and change it when you have better information
You Ain’t Gonna Need It. It’s one of my favorite acronyms, but it’s harder to adhere to than you might think. When you’re gathering requirements you often hear about things the business owners want to do in the future. Plus it’s just in our nature to build in everything we can. It takes a great deal of restraint to build an application that is useful in 3 months instead of the perfect solution in 8.
The 80 / 20 Rule
This is probably the most difficult thing for programmers to remember: not everything has to be solved in the application. Today we we’re hashing out the stories dealing with escalation. There were one or two scenarios where the person handling escalation couldn’t solve the problem themselves, but needed either a manager or some other team member to do something. There’s no doubt this could be done within the application, but the reality was that it would just be faster if they asked the person either in person or on the phone or in an email to make the change for them. Since it was only one or two cases out of 15 or 20, it didn’t make sense to have this part of the minimum viable product.
It’s possible that our analysis is wrong and it happens way more often than we think. But at this point we don’t know and trying to build it now would add weeks to initial deployment. There are plenty of cases where it’s just better to handle edge cases outside of the application. The important part is to gather data so that you can either confirm or refute your original hypothesis
A lot of assumptions are made during the initial development of an application. You need to be able to validate those assumptions and one way to do that is to gather as much data about usage as you can. From click throughs to thorough logging, capturing usage data is crucial to find the holes in your initial assumptions.
We’re one of the few professions where it’s okay to build something with imperfect information. We have the ability to improve our designs after people start using it. It’s okay to get a few things wrong as long as you design your system so that you can make changes quickly. Low coupling, design by contract, and high test coverage help you do that. By applying restraint in our design and architecture and incrementally improving applications can lead to really great software