Can great products be built without having any solid development processes? I don’t know but I can confidently say that it’s a definitive topic for a thesis. Well, we decided to do away with all the development processes for one of the coolest products that we are building.
You did what!?
Yeah, Unbelievable but true.
It must be burning in flames, isn’t it?
As a matter of fact, to the contrary, we not only got done sooner but it works great.
You kiddin’ me, right? It ain’t even 1st of April today?
Nope. It’s sad that we have been conditioned to believe the processes are a panacea to all our software problems and helps build product the right way. Come to think of it, it is probably true to a large extent for certain kind of software projects but you can still make magic without it. It is always about the people.
So, what was the darn process? Or, whatever you are calling it?
Actually, we decided to build the software in an extremely simple yet agile way. Really, it was darn simple. We call it “V1P” – Version 1.0 Process.
Ideate
Sudesh and I spent lot of time envisioning how the product would look like. We did lots of wireframes/HTML prototypes before even laying the single line of code or thinking about design. Once we were comfortable with our idea, we decided to put the features in an excel file.
Plan
We created an extremely simple spreadsheet with all the features and task and divided them in 2 week iterations.
White boarding
We did an extensive white boarding of the design and how different components/layers would interact with each other. And, that was our design.
Communicate
As we were working very closely(ahem..I meant we sit next to each other), we used to have informal stand ups. Well, technically, we were always sitting down while having these meetings. So, more like sit-down stand ups – Huh! Oh well. We used to discuss for 15 minutes regarding the progress and any impediments.
Build Trust
We never went back and updated our status. Doh! The source code was the barometer of our progress. It’s funny what all can be communicated to each other when you trust your team mates and build on each other’s code.
Deploy
Sudesh deployed the code every other day so that we could see if anything was broken. Yup, no nightly build process for us. Come to think of it, I missed this the most. I think going forward, we would have some sort of Continuous Integration like we do in our other products.
Fix and Move Forward
We used to fix bugs before moving to any new functionality.
Rinse. Lather. Repeat.
Well, that was our process. You would be really surprised that we got done with the alpha version of the product in straight 3 months. It’s a fairly complex product and I’m sure it would have taken more time if we were to follow everything by the book. I think the thing that led to our success was lot of brainstorming early on and having immense level of trust.
It’s a different thing if the product becomes successful or not. Well, it’s coming soon. Wish us luck!
PS – I’m sure you must be really thinking that it is really applicable for products which are being built in a garage by couple of hackers. Well, may be. It’s not something that we follow everyday but has produced great results for us. Also, I don’t intend to follow it in our products of fairly large size which need lot of interactions but something I’m ready to stick with for smaller teams.
