Test driven approach to build MVP

I have talked a little bit about Test Driven Development in my earlier post though it was more towards while working on a component level. But I have been thinking about how can we apply the same approach on a bigger scale, how about while defining how to add features and build a good enough product.

Let me give you some context first before diving deep into this.  I got an opportunity recently to work on a very interesting project within AWS called Amazon WorkSpaces, which is Amazon way of doing Desktop As a Service. I won't go into details of how awesome this project is (though you should definitely signup for the preview mode to see some of the awesomeness), but I will focus on the approach that we took to deliver the most critical piece of the project in a couple of months.

As usual the timelines are tight as well the competition, but we still have to deliver a good product or what we call the Minimum Viable Product (yeah, we run lean at AWS). Anyways, I was set to work on the piece that act as a gateway for handling the streaming of workspace (the windows EC2 machine) to the WorkSpaces client. This part below is my learning while working on this project.

Now when you think about working on a project, there are various ways to approach it; once you are done with initial design and have a good idea of how it should work overall as a system. 

Approach A is to have a detailed (implementation) design document with all the details about APIs, their structure, how will they fit into the entire system and you then hand it over to your engineers and say: go built it guys! Make sure you follow this document as we have spent good three weeks writing it. And as usual, things change, requirements change and no one ever care to take a look at what is written in that document. The system is built, integration tests are added (when? depends on the design document) but then we realize that things are little different that what we though while writing the document. Believe me, one of my previous team followed the above pattern and as obvious, we were late delivering that project.

Okay, so that is one extreme. Approach B is, jump into the implementation assuming we are agile and change as we go, come up with an implementation, do some form of testing and come up with an end to end approach quickly, see it all work with some manual testing. And then we say, lets not worried about the end to end tests or what they call "integration tests" for now, we will add them later but lets add more functionality based on our learning and 'TODO' list from our last progress. 

The project progresses that way, and then we think about adding all our integration tests, load tests and making the system 'ready for operations'. But then its time to launch and we are sweating as we are done with our functionality but may be we are not ready for the prime time. Why? Well, we have the MVP product in terms of functionality but may be we are not sure if its good enough.

Now coming to the Approach C, the TDD approach at a project level, while building a MVP, why not first write your tests (most importantly your integration tests) first that defines the scope of your product. I know you might think of this as an extreme case of TDD (write the tests first, meh!), but I mean why not think these tests are your technical definition of MVP and as building blocks of your MVP.

Lets pause for a moment, and look back at what a MVP definition is. This blog from Ash Maurya says "The basic idea is to maximize validated learning for the least amount of effort".  And then he adds a great example:

For Timothy Ferris, his MVP for testing new products that don’t yet exist (micro-testing) comprises of a landing page, signup page, and Google Adwords to drive traffic. However, this approach presupposes that:

1. You can create a good landing page
2. You can write good adwords copy
3. Adwords is a viable distribution channel for your product

Now if I understand correctly, it means build a small set of features but these should be "good enough" to maximize your learning from customer feedback. Hmm, interesting! Specially the "good enough" part.

So, how to define something as "good enough"? And most importantly, how to validate that you maintain that "good enough" trait as you go on adding features to build your MVP? And when you feel you are done with your MVP, you have maintained and made a "good enough" product to launch in public.

I think this is where Test driven approach is so valuable. Using TDD, this is how one should go about developing these good enough features:

1. Write a failing test (start with unit tests and then add integration tests) that defines the features you want in your MVP.
2. Implement the feature without caring much about good refactored code. Just make it work and such that the tests are green.
3. Integrate other components using that feature and make it work end to end.
4. Then refactor the code and make it production ready. The tests are still green.

Add a small good enough feature, but validate with tests (unit tests at small component level, and integration tests for end-to-end feature) and mark it as "good enough" before proceeding towards a new one. Keep the bar as "A feature is marked done, only if its good enough to ship to your customers". By working this way, you maintain that confidence all the time in your product, that if your tests are green for a feature its good to go. Its also setting up an awesome, solid operations platform to make sure that any new changes or features added to the system is not breaking your previous release of your MVP.

It all sounds simple and obvious, right? And you might think: "So is that the approach that your team is taking right now?" The answer is "No, not exactly". But we are close, at least we are not taking the Approach A but unfortunately we didn't follow a TDD approach either. We do have a good setup of tests that validates our entire system every minute though were setup a little late in the project but we now understand the importance of these tests. Seeing a green light every minute is the best motivation you can ever get.

I tried some form of TDD approach while working on the WorkSpaces project, but I think I failed to make sure that we had tests (specially integration tests) for every feature we added. But I am still working on it, and there is still a long way to go so I will get another chance to make sure I do it the 'good enough' way!

INKTalk: From failing in engineering to co-founding a million-dollar company

I came across this awesome talk from 25 year old Indian filmmaker, Varun Agarwal talking about his mantra of success - Don't think, just do it. It does resonate with similar ideas from so many other successful entrepreneurs, but I really like the way he has presented his thoughts in this talk.

Enjoy!

Book Read: REWORK

Few days back, I finished reading an awesome book, REWORK by Jason Fried and David Hansson, the founders of 37signals. The book provides a lot of insights, tips and rules on getting things done and how to do them in a right way among various other tips for entrepreneurs for building culture and grow your company. Its a great read not only for entrepreneurs but anyone who deals with everyday tussle of planning, building and shipping things.

There are a bunch of amazing advices in this book and hence a must read specially for software engineers. After reading the book, I wanted to take few notes that I can refer later on and so instead of hiding them in Evernote, I thought of blogging it and make it available to everyone.

This is not a comprehensive list and does not reflect the book entirely, so you should definitely read the book. Below are some of the chapters and their summary in my words:

Build half a product and not a half-assed product

In other words, think of adding enough business value to your product iteratively rather than throwing it out with all the bell and whistles that your users might not even need them. Also, this allows you to ship things fast, get the feedback and build upon that feedback. 

The feedback from users is so important that it can influence your own plans and overall vision of the product. So make it short and better, and ship it!

Good enough is fine

Instead of thinking about complex solutions for complex problems, first come up with something simple. As we do during the interviews for a new position, we always tend to tackle the problem with a 'naive' solution and then build on that to come up with a better solution. Most of the times, the simple solution is good enough for even a complex problem and the best part is you can come up with a simple solution and try it out very quickly. If its all good, we have solved the problem without much efforts. And if it does not work, then we can always add on and work on better solutions.

As in Amazon we say, don't get bogged down in analysis-paralysis, think of a simple solution; it is always better.

Long lists don't get done

Never have long lists of things to do, rather break them up into smaller lists based on the context. When we look at longs lists, we get demoralized on the first look itself and it keeps on adding to our guilt of not getting done so many things. If the lists are small, one has a good chance of prioritizing them well and actually get them done.

You need less than you think

Again, as we do and believe at Amazon: Be Frugal. Most of the times, we can ship things and get things done with less resources and use only what we need. How is that possible? Well, if you have less resources to worry about, you will have more time to concentrate on the right and core thing to do and you will actually get it done. 

For example, ask questions like: 

Do you really need ten people or will you get it done with three or two or just one?

Do you really need a big office or can you share your office space for a while?

ASAP is poison

Whenever someone wants to get anything done, its always ASAP. This says nothing about the priority when all the tasks has to be done ASAP. As the authors says, when everything is high priority, nothing is. This just creates artificial stress, which leads to burnout and worse. So this should be reserved only for true emergent situations, for everything else just chill out.

Get things done: My setup

I have been using slightly twisted version of GTD for my everyday tasks as well as for my long term goals for last 8 months, and it has been a great ride. I want to share my overall setup of my GTD system and then the each piece of the setup in more details. In this post, I am going to explain my overall setup of the GTD system.

Before I dig in, let me put my requirements and use-cases so that one can understand why my setup exists:

1. I should be able to follow GTD not strictly but with modifications as per my needs.
2. I should be able to use just one system to track my daily tasks as well tasks for my long term goals.
3. I should be able to use the same system for my home and office tasks, but still be able to separate them so that I don't endup caring about the office-related tasks at home (for the most part).
4. The tasks should be backed-up in cloud as well as on the client side.
5. I should also see my scheduled tasks in my iOS/OSX calendar.
6. All parts of the system are always in sync.
7. Lastly, I don't mind to shell out some limited amount of dollars for the setup.

I know! A long and complex list of use-cases to begin with.

To get things done my way, I have tried a lot of apps and services that claims to do GTD. Most of them were good but either they won't fit into my requirements or they were simply not following any version of GTD! I won't name all the options that I tried as they as a lot of them and also does not serve the purpose of this post which to share my existing and working solution.

After trying out a number of options, I finally stick to these apps/services:

• 2Do (iPhone and Mac app)
• Toodledo (cloud backup/sync)
• iOS/OSX Calendar

And this how I set them up to meet all my above requirements:

My GTD setup

I found 2Do allowed me to modify and use my own version of GTD as the app provides a lot of flexibility and options to tweak the process. I will go deeper into my tweaked GTD process using this app in a future post, but for now I will just post my complete system setup.

2Do does provide a lot of options to sync the tasks using multiple cloud services like DropBox, iCloud and Toodledo. I chose to go with Toodledo, as it fit nicely with 2Do and also allows me to get the tasks to show up in my Calendar apps.

So when I add tasks using 2Do on my iPhone and/or Mac, it gets synced with Toodledo. Then once you add Toodledo as ICS subscription to the Calendar/iCal, you can view all the scheduled tasks in your calendar as well. I use 2Do on my iPhone primarily for tracking my non-office tasks while the one on my Mac for my office tasks even though I keep both in sync and can see, add and edit them on either iPhone and Mac. But in order to separate myself from office work while at home, I have tweaked the system so that I don't worry or even see most of my office tasks on my iPhone.

This setup has worked wonders for me, keeping me up to date of all my tasks no matter where and how I add them.

Let me know in comments if you have used similar setup and have suggestions on how to make it even better.

The perfect software

I came across this awesome blog that shares some of the experiences of the team that writes software for the NASA space shuttle. It presents a great insight into how powerful software can be. As a software developer, we sometime take things (read bugs!) for granted, but if there are lives that depends on the same software, then entire definition of 'bugs' changes.

A must read for every software engineer:

http://www.fastcompany.com/28121/they-write-right-stuff