My talk at The Strange Loop conference this year was recorded and is now available at InfoQ. I talk about why we’re using Datomic, Storm, and Clojure for our backend on the Zolodeck project.
Let me know what you think!
I didn’t realize just how true my previous post about the minimum MVP might end up being. When we first conceived of Zolodeck, we figured we’d build it the Lean Way. In that process, we came up with an MVP – and this included support for LinkedIn, Twitter, email inboxes (GMail, etc), and possibly, Facebook.
Now, however, given our time constraints, it looks like our first (pre) alpha (is that even a real term?) users are going to start with Facebook only! Every time we started planning our initial alpha public release, our burn-down projection would show something horrendously far into the future. So we kept cutting back, and we think we have something now. Something that we’d want to use ourselves.
I’d have never believed myself if I’d told me I’d launch with just Facebook. But in some ways, this narrowed scope is actually better (apart from being doable in a reasonable amount of time). It will give us a slice of functionality to test, all the way through one end to the other. Our other sources of data (email, LinkedIn, Twitter, etc) are extremely valuable, but they can easily be added later. Just having Facebook means that we can focus on the value-add of our app, rather than just having data from all over.
In any case, we’ll see what our users will say
I’ve had some downtime from work recently, and have been working on a side project with a friend. (Isn’t that what vacations are for?) We’re calling it Zolodeck. One of the first things we did is decide that we want this to be driven completely by future users. So this is an experiment in user-driven product design, you might say.
Technically, we’re tracking everything that a user can do. This data gets fed into our data-digester. Yes, that’s the technical term. And out comes Insight. The idea is to use these insights to decide how to evolve the project.
We’re looking at several ways in which we can get the infrastructure to support all this, including building out our own. I know it will be a complete distraction from the goal of the project, so I’m certain we won’t go down that route. We’re still evaluating what we’ll end up with, so stay tuned on that. We do want to document our experiment here, so this notion of “metrics driven product design” should be a recurrent theme on this blog.
BTW, we’ll also add convenient text-boxes that users can use to drop us notes (mostly appreciative suggestions, but also hate-mail if they choose ).
“I remember a quote from one of my Lean Sensei’s that the standard for Visual Factory effectiveness was that a one eyed person could gallop a horse through the plant and at the end be able to tell you what is going on in that plant. It should be that obvious.”
Purposes of A3 could be broadly fit under either of the following three purposes:
- Reporting how you solved a problem
- Outlining a proposal or strategy
- Conveying status on a previously agreed proposal
Click the Image for Full Size
Click the Image for Full Size
Imagine that in our project we have a manual build process that is complex. Sadly, this is not that difficult to imagine. Obviously the manual build process is reducing our ability to release our software often. Close your eye for a minute and think how will you will solve this problem.
When I asked this question to some of my friends, most of them told me they will automate the build process. I bet even you came up with automating build process as a solution. Automating the build process looks like a logical solution. If you give some more thought, you will realize that we are just automating the complexity that is there in the build process. We are not simplifying the build process. Even though we automated our build process it is still complex and it is going to be difficult to change.
So next time before automating a complex process, first simplify that process. If you simplify a complex process, as a added bonus it will be easy to automate.
A group of people are a team when they,
- Have Common Goal
- Have Mutual Commitment
- Synchronize their effects and
- Trust and Respect Each Other
Otherwise they are just a group of people not a team.
“It is the system, not the workers, that creates defects and lowers productivity”
– W. Edwards Deming