Lean Prototyping: Learning and Doing in Today’s Development World

Dominic Lachowicz |

August 21, 2013

Lean Prototyping

It was my Junior year of College at the University of Pennsylvania. I was in CS350, working with Professor Jonathan Smith on the semester’s final project –implementing a basic web browser in Tcl/Tk, complete with JavaScript support via Rhino. I was about a week into the project when I recognized that I’d have to scrap my design and most of the code. In order to implement tables that reflowed, I’d need to rethink how I designed my layout engine and probably throw away a substantial amount of code. I was talking to Professor Smith, lamenting that I’d need to redo so much work. He just stood there and grinned at me. With a fatherly look about him, he calmly walked to his bookshelf and gave me a copy of Fred BrooksMythical Man Month. He said something to the effect of “welcome to software engineering, kid” in an exceedingly empathetic way. I was to read the book after I re-implemented my web browser.

The project turned out fine and I cracked open Brooks’ book. Ever since, it has been, in my opinion, a must read for any software development manager or project manager. It’s short but the insightful 300 plus pages should probably be required reading for anyone in a leadership position. I probably lend it out to folks more than any other paperback. Back in the early 1960s, Brooks was the project manager for the IBM System/360 computer family and then for OS/360, its massive (for the time) operating system. The experience taught Brooks much, including the many perils of “green field” development. Brooks’ team had run into the same sort of problem that I did, but they did so three decades earlier. Back in those days, something akin to the waterfall development model was en vogue. For months before a developer would write a single line of code, analysts would compile requirements into a tome. After that lengthy process had completed, development’s objective was to turn those specifications into working software or hardware. Time permitting, somebody would test the thing, and if the stars were aligned perfectly, customers would react kindly toward your product. In practice, that seldom happened.

There are many shortcomings of this particular development model. During his tenure at IBM, Brooks came to appreciate that progress is non-linear. It’s often through doing that we come to understand our problem domain better. It’s often through implementing a lousy design that you come to appreciate what a better design ought to look like. It’s through failure that we can learn to do better. This resulted in Brooks’ seminal quip that “[t]he management question, therefore, is not whether to build a pilot system and throw it away. You will do that. […] Hence plan to throw one away; you will, anyhow.” (emphasis mine)

Fifty years later, Brooks’ words still ring true. We haven’t stopped failing. But we’ve adapted our development methodologies, such as the Lean Startup, to take our human shortcomings, variability and unknowns into account. The way to do this is to fail faster.

One of the ways we do this in Lean is via the Minimal Viable Product. A Minimum Viable Product (MVP) is a strategy used for fast and quantitative market testing of a product or product feature. A MVP has just those features that allow the product to be deployed, and no more. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. Sometimes, your MVPs feel like something out of MacGyver – held together with bailing wire and bubble gum. But the point isn’t to build a product. The point is to perform validated learning.

These prototypes are an extremely productive way to explore your problem domain. Employed as a MVP strategy they help a team to collect the maximum amount of validated learning about customers with the least possible effort.

I’m a big believer in building prototypes, learning from them, rototilling them, and rebuilding them into enterprise class software. Recently, we built out a proof of concept (PoC) of a new product that we’re calling “Store & Forward”. SnF adds the ability for merchants to accept credit and debit card transactions while their Internet connection is down. We’re initially implementing this work for a major partner of ours with a goal of eventually making this feature available to all of our VARs. Over a period of three weeks, we used nodejs to stand up a simple system that allowed us to explore the problem space and learn our partner’s Point of Sale system. Nodejs was great for prototyping – it helped us quickly scaffold out the basic structure of our product and implement most of the “happy paths”. This culminated with an impressive product demo with our partner, and it gave them a tangible way for them to ask meaningful follow-up questions and suggest improvements. This is exactly what we wanted (and needed) at this point in the product’s lifecycle.

It’s a week later and we’re planning to throw away our code and build it again. For various reasons, nodejs isn’t the perfect fit for the enterprise version of our software. But that’s not the point. Unlike me from 15 years ago, nobody is sad that we’re throwing this code away. Instead, we’re all happy to have learned so much from the experience, and we have a plan for how to do it better next time. I’m not sure I could have asked for a better outcome.