[rust] zero2prod Build Log 02 - User Story
What makes this book unusual is that it does not jump straight into code. Chapter two spends some time on the act of "development" itself. My first job was as a production line engineer in a factory. After I moved into software, I was lucky: my first role introduced me to agile development. I ran along with the company's cycles and rarely had the time to ask why we worked that way.
Chapter two gives a short account of the software development process. I read it again after a while in the job, and I understand a little more of it now. So this post does not go into code. I want to spend a little time on this chapter instead.
Learn From Problems
Choose a problem you want to solve.
Let the problem drive the introduction of new concepts and techniques.
In anything you do, you have to find a way to solve a problem. Those problems then teach you something new. I do not know why, but the software industry is more willing than other industries to talk about this and accept it. Nobody builds software without a problem to solve. You want that problem to be:
- Small enough that it does not become too hard to solve
- Complex enough that the parts come together into a complete system
- Interesting, so that you have the motivation to finish it
These points look basic. After a while at work they are also easy to forget, and the last one most of all. Once you treat the job as a routine, you really do lose the feeling that "interesting" is what drives you to finish something.
User Story
People in agile development talk about the user story a lot. The book puts the user story into a fixed shape.
As a …, what role I have
I want to …, what I want to do
So that … what goal I reach
The book builds a notification system for blog posts, so the story becomes:
I am a blog author
I want to send an email to my readers
So that they know that I wrote a new post
The point of this shape is to give the developers one target to focus on. You set out to build a notification system, so why would you wander off and write an article editor instead?
Once you have the first target, you break down the work that it needs. Look closely at this simple story. Study it, and many more questions may appear. Do you support several languages? Is the email body a template, or can the user write it? Does the email support HTML, or plain text only?
You can split the whole story into many small tasks. Next comes the biggest point of the chapter.
With that many tasks, who knows when you finish, and by then nobody may want your product
You can polish every part to perfection and get a flawless system that does not fit the market. Or you can ship the most basic feature, and then improve it step by step in each iteration and add what is missing. That is the spirit of agile. It sounds lovely. As I read on, though, the problem was not really that agile is hard to reach. It was that the author's idea of fast iteration looked very different from mine.
Instead of going deep on one story, we will try to build enough functionality to satisfy, to an extent, the requirements of all of our stories in our first release. We will then go back and improve: add fault-tolerance and retries for email delivery, add a confirmation email for new subscribers, etc.
To reach enough functionality, you must prioritize the tasks with a clear strategy. To make the system fault-tolerant and easy to extend, you need a range of techniques. Agile is not only about speed. The later chapters make that clear. You need a development flow that is smooth enough. At the same time, you keep the system solid with techniques such as tests.
The author writes the integration or unit test first and fills in the production code after. That works because the production code passes through countless tests as it takes shape. That is even more efficient than my old habit: imagine the code out of thin air, then trial and error my way through it with the debugger in the IDE.
The next post starts the actual development. I do not know how far behind schedule I will fall. I plan to update the crate versions from the book to the latest ones. I expect a few snags along the way. I already hit one: the sqlx version that the crate pulled in did not match the version of the CLI tool that I installed. The offline mode build failed, and CI died completely. I hope that I do not give up halfway.
Note: sqlx is one of the many database connection crates in Rust. It can check your SQL syntax at compile time. Sometimes the compiler cannot reach the database to check, and then you turn on offline mode. sqlx ships a CLI tool that generates the files that offline mode needs.