I’m a big believer in PDD. Why? Because we clearly need another TLA in our lives. Okay, as a good developer seeing an unfamiliar acronym you likely just Googled for PDD and found a set of links on Pervasive Developmental Disorder. That’s not what I’m getting at (though that term sure sounds germane). I want to chat about what I’m calling Prototype Driven Development. So what’s the big idea?
Waterfail
Before we can fully appreciate the joy of PDD, let’s talk about the old school. In yesteryear before people went wild about Agile, nearly everyone used a waterfall model. We documented relentlessly and didn’t write code until the complete picture was hashed out in painful detail on stacks of dead trees. Once it was actually time to code (often months of meetings later) we followed this documentation to the letter. God forbid we wrote a line of code that had to be thrown away.
Shoot, documentation was our only guide since the meetings often drug on so long no one could hold the vision of the entire app in their heads. And if we had to deviate from the plan in any way, it was meeting time all over again. I’m not talking about kind of meeting where you grab a latte’ and have a light chat about options. In waterfall, deviation from requirements was akin to amending the constitution. The thought was “We spent months planning this, so how could we have been wrong?” Hours would be spent simply getting everyone back on the same page about what we were trying to build. Religious fights broke out based primarily on FUD. Without a real app to safely try ideas, any change seemed fraught with peril.
The Agile Awakening
Now imagine the pain of this soul-crushing process finally drives you to investigate the joys of Agile. As an enlightened developer you’re aware of rapid wireframing tools like Balsamiq. It’s an awesome tool and certainly has its place when you’re worried the customer will assume a UI that works means you’re almost done and clearly overpaid. But these days, building a UI that “seems” to work is child’s play. Okay, it should be. If it’s not then you need to get the right people on the bus.
So dump all the pomp and circumstance and simply start coding the simplest thing that can convey your idea. Iterate daily. See what sticks. Show potential customers and watch them squeal with excitement or laugh in your face. Embrace the joy of failing fast and get version 1.0 out the door as soon as possible. Your idea needs air:
Usage is like oxygen for ideas. You can never fully anticipate how an audience is going to react to something you’ve created until it’s out there. That means every moment you’re working on something without it being in the public it’s actually dying, deprived of the oxygen of the real world. – Matt Mullenwig
That’s the big idea in PDD: The prototype is the documentation. Speed of iteration is valued over detailed planning. This approach is recommended in “Inspired: How to Create Products Customers Love” and has been highly successful at eBay.
A Justification
There are many advantages to building a working prototype that's constantly updated over relying on a detailed spec. The prototype speaks a high fidelity language all can appreciate without abstraction. It represents the function, info architecture, interaction and visual design. Documentation remains necessary, but only when the prototype can’t practically convey intent. Think Wikis and Basecamp over Word docs/spreadsheets/MS Project and you get the idea.
With a rich prototype you can actually interact with the proposed app. Everyone sees the target clearly, in the flesh. Remember, documentation is impossible to demo or test. Trying potential ideas is easy and testable – just tweak and grab a stranger. Internal customers quickly see holes in the idea or implementation. PDD honors Boyd’s Law of Iteration:
Speed of iteration beats quality of iteration.
The beauty of PDD is prototypes are easier for all to understand – especially non-techies. Changes to the target are immediately viewable to all stakeholders – not buried in a document or system few will bother continually reading. Stakeholders get to see near immediate results instead of waiting weeks for launch and hoping documents and conversations are translated properly into their vision. Prototypes support hallway usability testing. If you’re not using prototypes, how do you know you’re building the right thing at all? How will the customer respond to your software? You have no idea. Without a prototype, you’re certain to (at least partially) build the wrong thing. With PDD you can tweak the UI/flow accordingly early in the development process when change is cheap. Combined with other agile practices such as 2 week sprints and a scrum board this can be really powerful and lightweight.
So who builds and maintains it? Well any dev can create the prototype. If you can use Visual Studio or Dreamweaver, JavaScript, and CSS you’re good to go. And if you don’t have front end devs who can pull this off, you need to hire some anyway.
Some will argue that PDD is wasteful because prototype code is thrown away. However, ultimately much of the documentation generated from traditional waterfall is thrown away as well, without any of the aforementioned benefits of learning through interaction that are afforded through prototyping. And prototyping avoids the tedious "auditing process" that is required to assure that the reams of documentation are properly and fully translated into the completed product. Since the prototype is the documentation, it’s quickly apparent when requirements are missed.
Final thought: How many times have you been tasked with slapping a project together in a hasty effort to hit a hard demo deadline? Prototypes used for demos reduce the mad rush before trade shows and client presentations by removing the need to be done altogether. A proper prototype should be substitutable for the finished product for demo purposes. This helps avoid generating technical debt caused by a frantic effort to hit a hard deadline. Remember, we don’t have time to be sloppy.