MVP - Minimum Viable Product or ?

Usually when I hear mvp people are thinking about Minimum Viable Product but this acronym can represent countless meanings like Most Valuable Person, Music Video Player or Model View Presenter so we should be careful with abbreviations.

Let’s just agree that we will talk about Minimum Viable Product from now on.

When a product or customer comes to me and ask me to do a project, I always think about MVP. Thinking about MVP can bring your project/feature faster to life, which can give you faster feedback from customers for possible improvements. This might also mean that project will start giving revenue faster. It brings you, as a developer more joy, because you are delivering something valuable faster and with less effort. This are some of the reasons why I am questioning every single feature or decision, if it can be simplified or even better, not implemented at all, at least not yet.

There are some downsides to this approach. Sometimes It makes my life harder just because I have to make something to work in first sprint already, which can cause more changes and unnecessary pain in the second one. This is something to think upfront thoroughly to minimize self-induced pain or even longer overall project dev time compared to not doing mvp.

Interview example

Once when I was preparing for interview, I have encountered to the following task:

Create web app where users can post comments.

This statement is so vague so you should always ask in details what is really meant here. Does it need to be some html page where use can enter comments or is it just web api which can be used by other apps? Do we need to authenticate users or can it be anonymous ? What kind of comments are expected, plain text? What is the expected frequency and size of comments? How do we store them? …

What pops into my mind as a real MVP is this. Create rest api for posting short (varchar) comments for one given uid (unique identifier which can represent website or location where comments are linked to) and save them into one file. Because we don’t know how much will it be used yet, lets assume 5 comments per uid per year. We don’t even need to create endpoint to fetch comments, but only to store them! If our stakeholders really need to get comments, we can just open ftp access to the files holding comments for them.

Code

Project code is available for download here github

MVP is not necessarily just prototyping or writing junk code. We should still be practicing TDD. Our code will still be running in production, just with less features.

func main() {
	url := flag.String("url", ":8080", "hostname:port")
	path := flag.String("path", "./db/comments", "folder to save comments")
	flag.Parse()

	ctx, _ := signal.NotifyContext(context.Background(), os.Interrupt)

	fc := services.NewFileCommenter(*path)
	srv := services.NewHttpServer(*url, fc.Input)

	fc.Init()
	srv.Init()

	g, gctx := errgroup.WithContext(ctx)
	g.Go(func() error {
		return fc.Run(gctx)
	})
	g.Go(func() error {
		return srv.Run(gctx)
	})
	if err := g.Wait(); err != nil && err != context.Canceled {
		panic(err)
	}
}

Here you can see we have 2 concurrent routines. One for api server and one for writing to file. This is needed because if every request would open file and write to it we might have some concurrent writes which might produce some gibberish as a result. To avoid this issue, channel is used as a queue for comments which are then written to file one by one.

Now all there it is to do is to deploy app and open ftp port to comments file. If usage of app will exceed expectations, we will know our app has some business value and we can start improving parts which are painful for users or better to say, improve parts which will bring more value to the world.

Metrics

MVP without metrics is useless. Why? If you don’t have metrics, how will you know what to improve or what direction should your product take?

What metrics

If your decision (what to improve or throw away) will not be based on measured metrics, it is good indicator that your metrics are bad.

In our example our metric is lines per file. This metric will give us insight how much our app is used. If we get 5 comments per year, maybe we should not change anything at all, but if we suddenly get 5000 comments per second, probably we should start thinking about high availability, exposing our api to multiple servers and shard our file to multiple locations on different servers.

Another metric data in our app are server errors. They are logged in standard error output.