Software development is a notoriously slow process, which is why so many people in this industry are obsessed with being quick. They get certified in Agile Methodology and engage in development sprints. They don’t even sit down for their meetings anymore, opting instead to hold daily scrums standing up. Today’s post is all about another speedy sounding saying, rapid prototyping.
Refreshingly, the term has tangible origins and applications. “Rapid prototyping” has been borrowed from the manufacturing world, where it refers to the creation of small-scale models in early-stage product development. Apply this idea to software, and it makes development much more efficient, effective, exciting – and as a special bonus, results in a higher quality product.
It’s also the type of methodology thing that doesn’t require a textbook to learn. You just do it (and do it again and again) and that’s all there is to it.
The Problem: The Sputtering Start to Traditional Development
The old way of developing software is dependable, but not exactly speedy. Put simply: First, you define, then build, then test and finally deploy.
Problem is, this process is front loaded. Step one – defining requirements – might sound simple, but it’s extremely arduous, time consuming and costly coming up with the words to describe a finished application before development even begins. Even more difficult is getting everyone to agree on it. Let’s face it. At this point, people are going back and forth about an idea that lives in their heads. Everyone has a different interpretation of what the end product is actually going to look like.
Further, how much value does that 40-page scope document really hold at the end of the day?
A More Fluid Approach
Rapid prototyping is like embarking on a road trip without knowing the exact address of your destination. You know the general direction and the city to which you’re headed. Why not start the engine?
In software development, this means letting the information architects and interface designers do their thing as soon as you have the basic requirements laid out. Together, they come up with a visual representation (wireframe or mock up) of what an application should look like and a working plan for how it will behave.
It’s really not important how bang-on that first prototype is; what’s important is that it was created quickly, and that it gives stakeholders a starting point that allows them to get on the same page and effectively discuss what needs to change.
From here on in, you loop: You refine requirements and continue updating your prototype while the developers, in concert, code the parts of the application which have been agreed on. It’s beautiful, really.
A More Successful Project
Rapid prototyping makes for a better product in two ways:
It fosters good discussion and enables stakeholders who are new to software development to easily uncover requirements.
Let’s face it: We are all visual learners. Often, clients don’t know what they want or are closed off to an idea until they can actually see it. That’s why requirements documents are challenging for those on the business side. The typical early-stage conversation at Urban Lighthouse goes like this: “I know I said I wanted X, but now that I see it, I want A … and B … and C.”
Also, because the client is able to see an iteration of the product early on, rapid prototyping builds early-stage buy in, which becomes critical in the overall success and adoption of software. Stakeholders feel actively engaged in the build of software.
Rapid prototyping has made a huge impact on project development at Urban Lighthouse. It doesn’t matter what our prototypes look like. They could be wireframes, detailed mock ups created in Photoshop or Travis’ hand-drawn scribbles on his Surface. They all accomplish the same thing: They allow us to move past the trivial discussions that hamper project planning and help us focus on what really needs to be done, while giving us a head start on both front- and back-end development.