Zero to Production In Rust, Chapter 2

This blog post continues our Zero To Production In Rust read through. Today we are reading chapter 2.

Luca starts by introducing what he calls "Problem-based Learning". I like this approach to teaching a language. It presents us with a problem to solve, and we solve it. I have learned a few languages, and it wasn't until I solved my own problems did I start to "get it". This approach Luca takes is one of the reasons I am excited to work through this book.

Luca points out that the challenge to the "Problem-based Learning" approach, is that it is easy to misjudge the complexity of the problem we're solving. It is easy for a problem to feel too big, or to grow too large if we're not careful enough.

To narrow the focus of the project, Luca introduces a common technique used in the software industry to specify a project, User Stories.

User Stories

A user story has a simple format, and it defines a single feature a product will have. It does this from the perspective of a user of the software. User stories are great at describing functionality in terms of value software provides to a person.

The basic template of a user story is the following:

As a …,
I want to …,
So that …

The first two user stories we will be tackling are the following:

As a blog visitor
I want to subscribe to the newsletter,
So that I can receive email updates when new content is published on the blog.

As the blog author,
I want to send an email to all my subscribers,
So that I can notify them when new content is published.

User stories have a single purpose: define why our software is valuable to someone. A blog visitor wants to know when a blog has new content (the value), to provide that value, we give them a way to subscribe to a blog and receive email updates.

Resist the urge to turn user stories into something they're not. There are better tools for specifying how a user interface should function or how software is architected. You may find that those tools are unnecessary depending on the size of your project. Describing what value your product provides is a necessity in my humble opinion.

User stories are purposefully vague from an implementation standpoint. This is so that we can build up our software in multiple iterations without effecting the user story. There is no mention of which database we are using. There is no mention of what the user interface will look like. There is only want a person needs, and how we will provide for that need.

Work in Iterations

Now that we know how we will provide value to people, we want to provide that value as soon as possible. The sooner we provide value, the sooner we can learn if we have solved their problem. If we take months to implement a user story, it will take a month to learn if we have solved their problem.

Instead of taking a month, we work in small iterations. We design the simplest solution that will satisfy the desires of the people using our software. That said, we also need to design a solution that can evolve. We know that our first step is the first step in many. We will learn what we need and need to adapt. Be like water.

End of Chapter 2

Chapter 2 describes how any product should start. Using user stories, we create a clear definition of the value we're providing to our users. Without a clear definition of value, it is easy for a project to sprawl out of control and waste time and money without providing value.

Next week we will work through chapter 3. Chapter 3 is a large chapter. I will likely split it into two parts. The first part, we will choose a web framework to use, and set up integration tests. In the second part we will implement the subscription endpoint, and work on a persistence layer. Until next time, solidarity forever.